FixTjuncs

Valve Software - vbsp.exe (Dec 11 2006)
2 threads
Loading Act1_Mission1_C3800A.vmf
fixing up env_cubemap materials on brush sides...
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (0)
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (1)
Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 10476 detail faces...done (2)
Merging details...done (1)
FixTjuncs...
Too many t-junctions to fix up!

This map has compiled
perfectly during it's development, it only started doing this, as if
I'm reaching some sort of limit. But what is this limit? I may be
missing something.....Cheers, in advance, for any help.

You have hit a limit. "too many t-junctions" occurs when you have too many [color=limegreen]func_details intersecting with non-detail geometry. vbsp during the compile process goes through and cleans up any intersecting geometry in order to prevent possible cracks in the level. [/color]

You need to either get rid of or simplify your [color=limegreen]func_detail geometry, or move any func_details out from intersecting with non-detail geometry. Or you can make some into models. But yes, this error will prevent you from compiling your map, so it's something you definitely want to look into.[/color]

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Actually Riven.... Sorry to steal your thunder...but its at ANY world geometry intersections.

T-Junctions (Or waterindicies as they are also called) are the extra calculations done at any intersecting brush geometry. Its basically filling the "gaps" between them. I don't know if you've ever noticed, but in hammer if you look at your 3D screen and look at where the walls meet the floor you can see it, you'll be able to see into the "void" of space where the brushes intersect. In game instead of seeing black, your going to get the hall of mirrors effect at points where the floor polygon will meet up with a wall polygon. These are the "cracks" that the compiler is fixing up.

Right now your starting to get these errors because you ARE reaching the t-junc limit. I'm assuming if the compiler detects you have too many its going to terminate the calculations after several iterations because I know sections of the compiler work in order (n!) time - or O(n²) or O(n³) or some really large exponential equation (exponential, so you wont see that much of an increase at 100 per say, but once you hop to 101 is going to take 10 times as long) and take literally forever.

You have a few options:

Turn complicated geometry into models - this is your best solution hands down, there isn't really any other way thats going to have a major impact on it.

Make all your geometry intersect like this:


This will cut down on unseen geometry, but its only going to have a very minor impact on it.

Rivens 1st suggestion, while kinda a good idea, isn't going to do much because if your still going to have that underside geometry thats going to cause more indices's to have the compiler to calculate.

For now you'll be able to compile your map, and keep on compiling it, but eventually your maps are going to start having these cracks show up more and more in them.

Edit also other link.

---

Posting And You

takes step back

EEK! Well, it looks like you've done more homework on this than I have. I'll retract my answer. I know that ANY intersection of geometry (besides models) will make more of a workload for the compiler to "clean up", but I thought that "t-junctions" specifically referred to detail geometry within non-detail geometry and that it was a different step (that I made up in my head) where Hammer sought out world within world geometry and cleaned it up separately. And so if that limit was exceeded it would give you a different error (not the "t-junctions" error); but you're telling me it's all the same step?

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

Firstly no need to take a step back. Essentially you gave the correct answer.

I was merely sending you in a correct direction. Essentially func_detail and world geometry are exactly the same. To sum the BSP compile process up:

-Create World geometry (essentially your basic world brushes, excluding func_details)
-During the above process it splits faces as to satisfy a BSP tree structure.
-Make vis leafs based off of world geometry
-Add func_detail geometry and "move" it to the world.
-Parse brush entities in.
-Parse models in (prop_statics only at this point)
-Parse point entities in. (any other props)
...
-Fix t-juncs
...

So by the time you reach t-junc all detail and world geometry is considered the same.

I can quote soruces, but here is some "proof" (read: other SDK forums_

somewhereElse said:
These are indices that are stored to represent various tessellations that vbsp does. When they were first created they were only used to subdivide water meshes (that's why they are often referred to as water indices). In HL2, they are only used to fix cracks in the world. Normally each face is fan-tessellated, so no indices are stored, but with several t-junctions on the face's edges this is often not possible and a separate tessellation is generated and stored.

t-junctions are edges with more than two collinear verts. This happens when dissimilar geometry meets sharing an edge, vbsp automatically adds all verts along the edge to each polygon sharing the edge to avoid cracks. vbsp has a -notjunc option that will skip this process, but that will leave you with cracks in your level. You probably want the t-junctions fixed. Cracks usually look like sparkling edges (bright pixels in the skybox showing through).

Got it from here

SO they are closely tied together.

And to correct my use of terms, its not intersections, but rather the common indices's that two brushes share. Simply put: its going to occur when you have too many brushes in your level regardless of brush/func_detail amounts.

Essentially I can see making things func_detal could help. BUT the effect would be minor. Not only that if you have too many func_details your going to get the MAX_MAP_ENTITIES error, (which is a compiler 'miss code' rather than an engine limitation).

Essentially you were right Riven, the only difference is moving brushes to func_detail isn't going to impact it that much because it'll still have the same number of indices's to fix up.

---

Posting And You

Now that's what I call an answer! :cool: I think I learned more here than drschelter . Thanks for the clarification omegaslayer!

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

<span style="font-weight: bold;">No, I definitely learned the most here...fantastic posts, thanks for your time and effort!!
</span>

I think it's more of an issue that the sloppy methods cannot actually be cleaned up by the compiler. Considering how BSP trees work. (Which is to say, poorly)

---

Blame it on Microsoft, God does.