"Too many T-junctions to fix up" error crashing compiler

[Vamp]

I've been having this problem off and on and I can't seem to wrap my head around it. First of all, sorry for creating a new thread for this but hopefully if this gets solved it will help others who encounter the same problem. Believe me I've done my research and have read a lot more into this than I ever thought I would, but I still have some questions unanswered and it all centers around this error:

[QUOTE]Too many T-junctions to fix up![/QUOTE]

Now I've found a few forum posts that have solved this problem for me, but each time I add more to my map I have to go back and fix the problem again.

[URL]http://forums.tf2maps.net/archive/index.php/t-10265.html[/URL]
[URL]http://forums.steampowered.com/forums/showthread.php?t=2696666[/URL]
[URL]http://www.moddb.com/forum/thread/t-junction-overload[/URL]

The above links explain that t-junctions are where func_detail'd brushes meet world geometry, and the engine has to fix up these junctions during the compile. Also, the t-junctions error can come up when waterindices goes above 100% (which I'm still a little unclear about).

[QUOTE]In other words, waterindices are NOT t-junctions, but they're the value you need to keep your eye on to avoid the error. You can keep track of it in the post-compile report. Go over 100% and your map won't compile.[/QUOTE]

The MODDB link describes raising the lightmap scale on everything which seemed to work and I was able to compile, but I still had an error saying VRAD was near 100%, and it was usually about 98 or 99%.

[QUOTE]VRAD: waterindices 64842/65536 129684/131072 (98.9%) VERY FULL![/QUOTE]

As of right now I am still receiving the t-junctions error because my map is unfinished, and every time I try to add something else I need to up the lightmap scale or func_detail everything.

Now in terms of func_detail, I am placing literally everything I can in my map as func_detail to help optimization because of my map's size. My map is just 6 skybox textured walls at nearly maximum allowed size with a displacement grass ground, based off of gm_freespace_13 which is where most of my inspiration comes from. Here are two images of freespace to illustrate how func_detail was managed:
[URL="http://www.mediafire.com/view/zg9j0yrpmtep642/2013-06-26_00002.jpg"][IMG]http://www.mediafire.com/convkey/8302/zg9j0yrpmtep6424g.jpg[/IMG][/URL] [URL="http://www.mediafire.com/view/kc83m66y56cr88f/2013-06-26_00003.jpg"][IMG]http://www.mediafire.com/convkey/8319/kc83m66y56cr88f4g.jpg[/IMG][/URL]
I just used r_drawfuncdetail 0 to get the second image without the func_detail geometry. As you can see, nearly everything in freespace is detail geometry, and I have tried to do the same in my map as well. Where I get confused is that the t-junction error comes from detail geometry touching world brushes, yet in my map I have no world brushes to touch. As far as I know, displacements are not world geometry, and actually render more efficiently than a flat brush ground. When adding brushes to func_detail, are all the brushes in the entire map added to just [I]one[/I] single func_detail, or is it ok to separate into many? I've done some testing and it seems that either way doesn't make a difference when it comes to waterindicies or t-junctions. I have come close though to the allowed limit (65565 indices, max 65536) and some times even 65538, but as the MODDB thread reads it doesn't seem to have a pattern to it. Now I might be able to sacrifice a little bit more in terms of lightmap scale (most of my geometry is around 32 now, some 64, some 128, and in places with no shadows I used 512) but my problem comes from the fact that I'm not yet finished with my map.

Now on to props and propper. My map is going on workshop, and I'd like to keep the file size down as much as possible. Wouldn't changing a lot of my brushes into props be almost counter-productive since I would have to pack the props into the map? Also, I wouldn't have many places in which propper would be useful, since hardly any of my geometry repeats besides maybe doorframes or a couple of buildings that I would think are too big to propper.

This is the current working version of my map:
[URL="http://www.mediafire.com/view/mog8fh9qs0ej9q1/2013-06-26_00005.jpg"][IMG]http://www.mediafire.com/convkey/cfa5/mog8fh9qs0ej9q14g.jpg[/IMG][/URL]

I'd say the map is 80% done and I'd like to get it out on workshop for everyone to enjoy, but this is just a huge roadblock right now so if anyone has any suggestions please let me know.

[B]EDIT:[/B]

I've managed to bring waterindices down relatively low by simplifying brush work which removes the amount of touching faces. The most significant drop in waterindices seems to come from fixing brushes that literally intersect and go through other brushes, and it seems to be more beneficial to clip brushes so that they don't intersect even if that means those brushes have vertices that are no longer on the grid (keep in mind a good 95% of my brushes are func_detail, otherwise I would be more worried about these unconventional clips).

My progress in reducing waterindices and some notes on what I changed, hopefully they will make some sense (compile time on fast is the first number):

2:59 compile gm_openair_a15
VRAD: waterindices         65247/65536      130494/131072   (99.6%) VERY FULL! (with func_detail construct building)

3:56 compile gm_openair_a15_1
VRAD: waterindices         63897/65536      127794/131072   (97.5%) VERY FULL! (without func_detail construct building)

3:51 compile gm_openair_a15_2
VRAD: waterindices         64857/65536      129714/131072   (99.0%) VERY FULL! (only func_detail on part of construct building)

4:03 compile gm_openair_a15_1
VRAD: waterindices         63723/65536      127446/131072   (97.2%) VERY FULL! (no func_detail on construct building, other fixes)

4:12 compile gm_openair_a15_3
VRAD: waterindices         62418/65536      124836/131072   (95.2%) VERY FULL! (both construct buildings non-func_detail)

3:58 compile gm_openair_a15_4
VRAD: waterindices         62961/65536      125922/131072   (96.1%) VERY FULL! (hints/skips to construct building, hangar from func_brush to func_detail) - I hate func_brush

4:06 compile gm_openair_a15_5
VRAD: waterindices         62934/65536      125868/131072   (96.0%) VERY FULL! (fixed up a few things in build area)

4:09 compile gm_openair_a16
VRAD: waterindices         62718/65536      125436/131072   (95.7%) VERY FULL! (added other half of tunnel from world geometry to func_detail)

4:04 compile gm_openair_a16
VRAD: waterindices         61440/65536      122880/131072   (93.8%) VERY FULL! (lowered number of beams on ceiling of parking garage)

4:09 compile gm_openair_a16
VRAD: waterindices         61374/65536      122748/131072   (93.6%) VERY FULL! (added beams back to func_detail)

[Firegod522]

It could be, because you are only suppose to be func_detailing stuff that doesn't block visibility. So those walls that you have around the city, those block visibility, so they should be brushes. The buildings also block visibility and should be brushes also.The roads do not need to be. Another example is the shed you have should be brushes, not func_details.

t-junctions occur from func_details touching world brushes, because vbsp still needs to cut up the faces for rendering. but it welds the verts so you don't get any seams in the world.

[editline]26th June 2013[/editline]

So it looks like i should have read the whole OP. in your version of the map, you need to be sure that you don't literally func_detail everything. Making everything thing func_detail makes it so you draw everything. whoever made the gm_freespace_13, didn't do a proper job optimizing it.

[|Arblarg|]

After getting a copy of the vmf, I think you would be very well off to go back and simplify your brush work. I believe you're just hitting the absolute upper limits of things based on quantity alone. As one example - A before and after I did on just the back of one house. Nearly a 75% reduction in the amount of brushes.
[img]https://dl.dropboxusercontent.com/u/7633313/before.png[/img]
[img]https://dl.dropboxusercontent.com/u/7633313/after.png[/img]

Also be on the lookout for where things overlap, there are so many places where you could benefit from just some simple vertex editing or rethinking how you can make 2 brushes into one.
[img]https://dl.dropboxusercontent.com/u/7633313/overlaps.png[/img]
[img]https://dl.dropboxusercontent.com/u/7633313/redundancy.png[/img]

[Grenade Man]

A shitty solution would be, I guess, to bring back all your brushes to world and run vvis with -fast.

It would produce the same effect as everything being func_detail and the error would be avoided.

This is, at best, a quick fix while you work on the map. You should definitely do what arblarg said and optimize your brushwork.

[Vamp]

[QUOTE=Grenade Man;41208842]A shitty solution would be, I guess, to bring back all your brushes to world and run vvis with -fast.

It would produce the same effect as everything being func_detail and the error would be avoided.

This is, at best, a quick fix while you work on the map. You should definitely do what arblarg said and optimize your brushwork.[/QUOTE]

That wall was subdivided because the texture on the inside of each room was different, and then I changed them to the same without fixing the wall. I'm just hoping I can find enough places like this to optimize brushwork because I still have a lot more to add to the map. Thanks for the suggestions

[Sgt.Sickness]

Waterindicies (t-juntions) are the biggest pain in the ass on large maps. There's a few things I do to avoid them. One is mitering my corners at 45 degree angles on my brushes where they meet at 90 degree angles. This cuts down on them slightly. Another this is to make things that you func_detail into propper models. This is where you will see the biggest reduction in tjunct's/waterindicies. Good candidates are brush based windows, support beams etc. I will usually make all the windows in an entire building as one model. Be careful making door frames models though as prop_doors tend to get stuck on them and refuse to close. Any round brushes I tend to make subdivided displacements as replacements. I also turn tons of stuff into displacements. Roadways are good candidates. Also as said before optimize your brushwork to use as few brushes as possible.

If you want to force your map to work you can add -notjunc to the vbsp command line. This will unfortunately leave white lines everywhere. T-juncts are like the plaster of hammer they blend the cracks of brushes into smooth walls.

Contrary to what some people say t-juncts / waterindicies do not form just where func_detail meets world brushes. They form on all brushes. You get more on func_details but you still get them with world brushes.

[FreakOnALeash]

[QUOTE=Firegod522;41206060]Whoever made the gm_freespace_13, didn't do a proper job optimizing it.[/QUOTE]

That was me. And i see no problem in func detail'ing all the stuff on the outside. I've done the optimizing via the propper use of hints and a occluder wall around the city. The brushwall around the city is only fake inside is a nodraw brush (worldbrush) When you're inside the city everything outside will not be rendered because of the vis. Same outside. Nothing in the city will be drawn.

I also func_detailed everything on the outside to chop down compile time and map size.
Also there is no difference if the buildigs and roads are worldbrushes. The rest of the map gets drawn anyways.

World Brushing in small and closed map is essential. But not in lage, open gmod maps when there are only large chunks of vis and only a few builings in the open.

Just my opinion on Open Maps. Of cource the is no sense in func_detailing [B]everything[/B].

Also sorry for digging up this old thread.