q3map2 causing sparklies and potential fix?

(G0-Gerbil) #1

I noticed that I get sparklies in a map from a very simple brush indeed.
It occurred to me that it’s probably a slight math error in the plane->winding calculations.
While I doubt there’s an actual fix directly possible in that particular bit of code, it did occur to me that Ydnar could implement a relatively simple fix.

After a brush is converted into windings, q3map2 could parse all the brush vertices and collapse any very nearby ones, then obviously cleaning up the windings to take the new collapsed vertex list into account.

This could either be done on an individual ‘brush processed’ level (faster but may cause new sparklies from touching brushes) or on a global ‘all vertices level’ (slower but will prevent new sparklies potentially being formed since all geometry is affected the same).

The only real problem I could see is that you then have the potential problem whereby visibile geometry doesn’t quite match collision data (which if I recall comes directly from the plane info, not from the winding info?). I’d have thought though that this visual discrepency would be so darned tiny (as long as you don’t make the ‘snap’ parameter too big of course) that no-one could possibly notice.

Thoughts? :slight_smile:

(ydnar) #2

Post a screenshot.

Brushes are imperfect beasts, especially when you vertex/edge edit them, or clip off odd angles.

y

(The Wanderer) #3

Yeah q3map could do lots of stuff however the fact remains that you corrupted your brush when you vertex tweaked it. That’s why it’s a good idea to go through each of the edited brushes and make sure they don’t have any weird vertices. Most of the time you can tell as you’re moving the vertex if the brush has been corrupted. Especially if the vertex keeps moving while the brush doesn’t, which means you should probably undo. If you see bad vertices, redraw the brush. And make sure you use triangular brushes. Does the trick for me every time.

(G0-Gerbil) #4

Yeah q3map could do lots of stuff however the fact remains that you corrupted your brush when you vertex tweaked it.

Sorry to disappoint, but I didn’t vertex tweak. Ydnar was spot on, but then he did hedge his bets with a couple of guesses :wink:
Hang on for astoundingly interesting screenshot :wink:

Erm oh arse my host is being a pain - can’t upload.

Basically:
Take a normal cube brush.
I clipped the vertical edges to be diagonal (so it’s a ramp up to the top on each side).

And that’s it :slight_smile: I got sparklies along 1 diagonal edge and where 1 of the edges meets the top face.

In fairness, I have to say I’ve not had this particular problem before, but then again part of the fun of sparklies is that they aren’t often predictable (apart from T junctions + patches). It just made me think about fixing sparklies generally, as opposed to fixing this particular instance of a set of sparklies.
Am just wondering about the logistics of what I mentioned to try to remove them.

(TwentySeven) #5

It depends on whats causing the sparklies

traditionally “sparklies” are caused by t-junctions: a vertex sitting on an edge of another triangle, instead of the edge being split into two tris so its vert/vert
the other anomoly that mappers see are “cracks” where there should simply be a triangle filling a hole.
only the second one can generally be fixed by collapsing edges, unless all triangles involved are coplanar.

(G0-Gerbil) #6

Yeah the second case is what I’m thinking of - I’m sure that those of us who know what to look for have all had circumstances where there’s no t-junction but sparklies occur nonetheless from innaccuracies somewhere along the line. Given it’s usually the brushes themselves that cause the problems (working on what can often cause sparklies and what Ydnar has said several times in the past) I’d say it’s creating the windings from the brush planes that is causing these problems.

I was wondering though if it would be hard / undesirable to put an option in q3map2 so that it would attempt to merge very close vertices, thereby eliminating these brush-caused sparklies which there’s actually very little you can do about bar keep trying to rebuild the brushes until luck dictates it goes.

The T-junction one is minimised now thanks to Ydnar’s code and the fact that T-junctions are entirely avoidable by proper building, so that’s kind of taken care of that one :wink:

(phobos) #7

I’m not sure I see where the problem is. I tried creating an example based on your description with only brushes. Here’s the result.

I created a 128 box, then clipped the upper portion to make a bevel on all four sides. Then made another only with two brushes instead of clipping one. I took these screenshots in 16-bit color, so sparklies should show if they’re there.

Clipped on right, two-brush on left:

http://webpages.charter.net/phobos/t_test/t_test_01.jpg

Wireframe of above:

http://webpages.charter.net/phobos/t_test/t_test_02.jpg

Zoomed in on clipped structure with normals on:

http://webpages.charter.net/phobos/t_test/t_test_03.jpg

Here’s the map if you’re interested (vQ3):

http://webpages.charter.net/phobos/t_test/t_test.zip

There’s very little JPEG artifacting in these pics (never mind the horrible 16-bit dithering), and I can’t seen any t-junctions. Maybe there’s something you missed? Might be a better idea than asking ydnar to modify the source :).

(G0-Gerbil) #8

Look thanks but I’ve already said I’m not after help with my specific sparkly :slight_smile:
I’m just proposing a possible (?) solution to some sparklies in general - which given Ydnar’s silence I assume he obviously either thinks won’t work or isn’t worth the effort experimenting with!