The r_speeds of my maps rose up around 5k in open terrain. So
I floated around with tris on and saw this:
But in my editor this brush is just a normal 6 sided structural brush.
It looks like itersections to me, but there can’t be intersections. I took a look at the skybox brushes and saw the same phenomenon.
I compiled with this options:
-meta -patchmeta
-vis
-light
What is -merge for?? Everytime i use it the q3map2.5.4 crashes.
when you compile your map q3map2 calculates the map only in polys which are 3 sided, so a square brush at least has to become 2 verts, a 6 sided, maby clipped or deformed brush will need a lot more so what you see is absolutely normal and should be like that, sides that are caulked are not calculated at all so try to caulk wherever possible
oh - just saw that it’s you fiesling, guess you knew that already heh? so just ignore me 
It was always my understanding that a brush like the one in your example is split into that many polygons to prevent t-junctions from occuring. The compiler has to create a vertex on the outside edge of the floor brush at every point where a wall brush vertex lies.
so a square brush at least has to become 2 verts
Yes i know that, but like in the ingame shot there should be only one line from one side to the opposite one. but not this structure.
like i said this brush is only 6-sided with no intersections or deformations.
the bottom is caulked.
Since it appears you have ignored my previous post, I will try once more with a more visual representation. 
there should be only one line from one side to the opposite one.
This method would produce sparklies all along the light blue lines. Thankfully, q3map2 doesn’t do this.
This method is as I described previously, where the floor brush is subdivided so that its verts line up with adjacent verts. This prevents sparklies.
Now i understand. 
Then i have to change my mapping-technics a little bit. Old Q3map1 didn’t do that and i never got sparklies before.
Thanks. :drink:
as i understand it this could be also prevented by having q3map_notjunc on the floor shader. but with possibility of having sparklies then. right ydnar?
i had the same effect like fiesling on a water shader without deformVertexes and q3map_notjunc did help there
I recompiled my map with -notjunc and all went fine. Better r_speeds and no sparklies.
I was under the impression that Charvo’s example above would work with -notjunc since the walls and floor meet at right angles and the brushes involved haven’t been rotated - so it all fits together nice and snug along the join - err that’s my non-technical wording!
Unless you’re completely fastidious about sealing areas and jointing brushes, -notjunc is not really a good solution.
I understand the principle, but I don’t understand how we can prevent it from happening to create less tris.
Yeah how about a solution to prevent this from happening for the not so experienced readers (like me) since notjunc isn’t a good method. My R_speeds went beserk when compiling with 2.5.4.
Oh and Hi all since this is my first post :drink:
UPDATE: Just tried recompiling it with 2.5.5 test3 and all seems in order again
Besides the sparkles are there any other problems with using notjunc. I have some massive splits in certain places that aren’t frequently visited and I don’t care about sparkles there so I need an option like this. If the only bad side effect of -notjunc are the sparkles then fine, if it causes bugs then tell me.
i use -notjunc for quick test compiles where i only want to check geometry or entities. difference in compile time is really stunning: 30 sec. for bsp instead of 7 minutes
i think I’m not understanding this right.
Can notjunc be used in a shader to eliminate the excess splits just for that texture, or is it a compiler argument that applies to the whole map?
I want something that i can apply to specific surfaces in my map to override the default triangle splits.
They aren’t “default triangle splits.” They are additional vertices to fix a T-junction of an edge meeting a vertex which would cause a crack (sparklie) due to the hardware FP imprecision.
The only way to avoid them is to become aware of what causes them and map to avoid them, usually by not putting lots of brush corners adjacent to longer brush edges.
y
some things are easier to avoid than others.
So far neither of my questions have been answered. One being if notjunc cause any bugs (is it a fully supported feature). And the other if notjunc can be aplied as a shader parameter that will work on one surface only and not a compiler directive that applies to the whole map. I did try applying it to the whole map and it works somewhat well. I say somewhat because it didn’t do everything. Some faces it seemed to have ignored.
Anyway sorry for being rude, but sometimes when you ask a question you expect sort of a direct answer instead of the usual design your map better.
First of all, they are not excess splits. They are splits that are only made if your brush construction requires them in the prevention of sparklies. Everyone thinks q3map2 is doing a bad thing here, but it’s not.
As for the shader directive you are looking for, it’s called “q3map_notjunc”.
As for your question on bugs, yes, I consider sparklies to be bugs.
