What's the relation between waterindices, func_details, and T-Junctions?

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
I am almost ready to go alpha with my CTF map but when I copied the Blu side and set up the Red and made the map whole and ran the map, I got the "Too many T-Junctions to fix!" error.

After reading various posts across the Internet, I gather that it is caused by too many func_details touching world brushes. According to an old thread on this site, moving them a single unit away from world brushes should help alot. And that waterindices were an indication somehow of how many T-junctions there will be and if you hit 100%, the map won't compile.

So I rolled back to my Blu map and started spacing my func_details but my waterindices were still at 67% which means it'll be 134% when I copy and paste the Red side I assume.

I've read that overlapping brushes or brushes off the grid may cause high waterindices, so I ran the map with no func_details to see where I was at and they were at 2.5% or 1600 waterindices. What I've read about this seemed conflicting. Do overlapping brushes or brushes off the grid cause this?

I stuck back in my first floor stairs and the waterindices jumped up to 27.8% or 18, 216 waterindices. There's five sets of stairs of them, but they only touch world brushes at their four-units-tall ends and two off them were hitting air because I had the platform they were attached to turned off.

All in all, I am almost completely in the dark over this. I can't figure out what to do because I can't figure out the relation between waterindices, func_details, and T-junctions. I understand that the geometry gets cut up or something during compile and that the func_details exacerbate this but these huge number fluctuations just don't make sense.

Can anyone shed light on this?
 

tyler

aa
Sep 11, 2013
5,102
4,621
You must have an insane amount of... something. This is an error typical of maps in late stages of development.
 
Apr 13, 2009
728
309
I've run a bunch of tests and the only logical conclusion is it's pretty random and vrad hates your guts.
 
Last edited:

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
That appears to be the jist of it. I narrowed it down today though and it seems to hate my stairs specifically with a burning passion. With stairs and no other func_details it's 41% and with all func_details and no stairs it's at 14%.

I think what happened is that since my stairs are based on ones from the decompiled Turbine map, something got carried over and mutated horribly. That and I got a little carried away with tiny brushes on rebuilding the stairs. I had taken a set of thin stairs in Turbine, took the frames and moved them underneath and made a bunch of tiny wedges along the rails as support.
 

Jeremy

L11: Posh Member
Oct 24, 2010
829
299
You should base your stairs off of stairs props. Use them as reference, insert brushes using the same dimensions as each step, and remove the prop when you're done.

I find the ones from Barnblitz work best as they are very straight-forward and quite large.
 
Apr 13, 2009
728
309
If you have a lot of identical stairs (especially good on mirrored maps) it might be worth learning to use propper. prop_statics are more or lesf functionally identical to func_details, cheaper to render and they won't count towards your watrindicees limit.
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
I looked at propper but according to the Valve wiki it doesn't work with the new MP update. I even considered breaking down and learning to model. But I think I found a solution. I think the stairs got so mutated because I was using the brushes copied directly from Turbine and I hacked them all to pieces a jillion different ways. So I rebuilt my stairs from the ground up using a third of the brushes by making my steps into displacements. So far in the separate tiny test map I built them in, they work like a charm. Now I have to see how they work in the main map.
 
Apr 13, 2009
728
309
I looked at propper but according to the Valve wiki it doesn't work with the new MP update.

Supposedly it works using an older version of the engine (2007, the original orange box engine) configured for TF2 textures, but I have yet to try personally.

Displacements for steps ? that sounds kinda costly but it might work. I think you could make displacements out of the ramp 'edges' of your staircase and have the steps made out of func_details, that way the steps wouldn't touch any world brushes, and unlike func_brushes, displacements are static and stickies will stick to them so that's another good idea. I should start using this in my own maps. :p
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
waterindices ~ t-junctions. When a face edge meets another (at a perpindicular) it tesselates said face, when a face can't be split into a fan shape via triangles it gets cut multiple times. I'm gonna steal Boojum's image url here: http://dl.dropbox.com/u/98931/MappingResources/waterindicies.png

Using alternatives to func_detail such as func_lod, func_brush, func_illusionary, models or displacements will reduce the occurance of t-junctions.

t-junctions are most common on stairs and/or trusses on wals (a single staircase can have anywhere upwards of 150 t-junctions (with triple the water indicies)). Converting the trim to an alternative entity will reduce 90% of the t-junctions; and subsequently water indices too.

You must have an insane amount of... something. This is an error typical of maps in late stages of development.

It's incredibly easy to hit this limit since it was reduced in a recent engine update. If you have a lot of steps you can hit it in alpha no problem.
 
Last edited:
Apr 13, 2009
728
309
So it's the fan-shape of the tesselation that creates the wild variations in waterindices for no apparent reason (moving a brush a few units while keeping it in contact with the same other brushes, for example) ?
Good to know...
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
I just got this error:
Brush 320793: ParseDispInfoChunk: nummapdispinfo > MAX_MAP_DISPINFO
Side 3
Texture: CONCRETE/COMPUTERWALL008

Does this sound like I have too many displacements or is just one of them screwed up? I have 1302 displacements now. I can't find any info on what the limit is.

Using alternatives to func_detail such as func_lod, func_brush, func_illusionary, models or displacements will reduce the occurance of t-junctions.

I like the idea of func_lod. It seems like it treats brushes like models and gives them a fade distance. So do they make brushes invisible to vvis like func_detail? Why isn't func_lod the "goto" entity instead of func_detail? It sounds like it's superior to func_detail or does it have draw backs too?
 

Ravidge

Grand Vizier
aa
May 14, 2008
1,544
2,818
it means you have too much displacement information for the engine to handle. Deleting some will obviously reduce the data amount, but so does reducing displacement power too.

All brush entities are "invisible"to vvis, I might be forgetting some special case, but generally a brushent won't cut vis.

func_lod is more expensive to render as it is an actual entity, and anything that is mid-fade so to speak is even more expensive.
func_detail is a very special entity that only exists in hammer; once vvis is done all func_detail are considered as world brushes as far as the compiling process goes, and in game they literally are world brushes, they are not entities anymore.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
func_detail is only a fake entity, this is why this problem exists in the first place.

func_lod is the "goto" entity for this kind of thing, but hardly anyone bothers researching the existing Valve maps to find this kind of thing out for themselves. Stair trims, wall trusses and other detail geoemtry are frequently found to be func_lod, Valve have almost certainly used it specifically to avoid t-junctions as they use them for stair trims throughout maps like badwater, badlands and goldrush.

Just be careful because as far as i'm aware func_lod (certainly func_brush) cause stickies to bounce.

As for func_lod being expensive, my understanding was that there were/are 2 different types of entities, passive, that are computed during the compile (func_lod, func_illusionary etc), and dynamic, that are active during gameplay (func_brush etc)... and that func_lod is passive and costs little resource wise whilst an entity like func_brush is not. But i could be wrong.

Some brush entities just don't seem to count towards the entity limit (including point entities like prop_static's and light's).
 
Last edited:

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
Thanks for the help. :) I left one set as displacements, made the rest as func_detail and their supports underneath are now func_lod since stickies are less likely to hit them. I got the waterindices down from 67% to 22%.

I have 12 degenerate faces now for some reason but the map runs fine so I'm not going to worry about that for now.
 

WhosAsking

L1: Registered
Apr 26, 2012
4
0
Some entities get "baked" into the map itself and therefore don't appear as entities persay.

prop_static (Static Props) are described as such because these are stationary props that get baked into the map's geometry. That's why accurate lighting can be computed off them and why they can't move or disappear. Any other kind of prop (prop_dynamic, prop_physics, etc.) is an entity and can be manipulated because of this.

Most lights are generally only of use to VRAD, the lighting compiler. lights and light_spots are computed by VRAD during compile time and the results "baked" into the map as light maps. Once compiled, unnamed lights don't exist anymore. Named lights, however, have a placeholder entity in place so that they can react to the TurnOn and TurnOff events, switching light maps accordingly. But to keep things sane, VRAD sets a limit to the amount of switchable lighting you can have on a given face. Now bear in mind that this has no bearing on any kind of dynamic lighting, but not all Source games can use dynamic lighting (basically, only games from Episode 2 onwards will support them, TF2 predates this and doesn't support dynamic lights), and they have their own rules.

func_lod is basically a non-interactive func_brush that can fade in the distance. Stickies will not stick to them, so they're not recommended for combat surfaces, and since they can be named they will count towards the entity and model total.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Ignoring the fact this seems like a needless necro bump...

...and since they can be named they will count towards the entity and model total.

The entity will only count towards the limit if it is named. Just like a light will not be dynamic unless it is named.

Just to clear up any misinformation.
 

henke37

aa
Sep 23, 2011
2,075
515
Named or given a flicker pattern.
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
Now bear in mind that this has no bearing on any kind of dynamic lighting, but not all Source games can use dynamic lighting (basically, only games from Episode 2 onwards will support them, TF2 predates this and doesn't support dynamic lights), and they have their own rules.

Yeah... that's not true. They had lights turning on and off dynamically at least as early as Episode One (the underground tunnels), and I'm sure there are cases of it in Half-Life 2 that I just don't remember. Plus TF2 was on the Episode Two engine to begin with.