T-junctions kicking my butt.

[Ze Inspector]

Hey guys, another question for you, as my hunt to optimize my map has popped out another issue.
I went through my map the other day and checked through a ton of brushes looking for places to convert things safely to func_details. and I found a lot of them. I was thrilled actually because it explained the 24 hour vvis I ended up doing a few days before. (that was no good. :P) However, upon compiling the map I noticed I had this message nestled in toward the end of the bsp write log.

FixTjuncs...
Too many t-junctions to fix up! ... (I don't have the actual numbers here, wish I did.)

I took this to interlopers and found that this had to do with the junction of func-details to world geometry. And it recommended that I reduce the # of func_details in the map thus removing these junctions. It also recommended creating prefabs and importing them as prop_static, but I don't have the software to do that. But I happily went in and started to try and pull unnecessary details because it looked like I wasn't that much over the limit.

HOWEVER!
After I replaced a multi brush func_detail with a simple solid I noticed my indices went up!

FixTjuncs...
Too many t-junctions to fix up! (3311 prims, max 32768 :: 65571 indices, max 65536)

Deleted a set of func_detail brushes.
got...

FixTjuncs...
Too many t-junctions to fix up! (3313 prims, max 32768 :: 65541 indices, max 65536)

Thought I was on the right path,
Moved a pair of func detail brushes to world.
got...

FixTjuncs...
Too many t-junctions to fix up! (3313 prims, max 32768 :: 65547 indices, max 65536)

>.<
Deleted a set of func_detail brushes.
got...

FixTjuncs...
Too many t-junctions to fix up! (3314 prims, max 32768 :: 65550 indices, max 65536)

*>.<*
Deleted another func_detail brush
got...

FixTjuncs...
Too many t-junctions to fix up! (3314 prims, max 32768 :: 65544 indices, max 65536)

Ok. good, now lets try and
Move a set of func_details to world.
got...

FixTjuncs...
Too many t-junctions to fix up! (3314 prims, max 32768 :: 65544 indices, max 65536)

So, what the hell, to put it bluntly. It doesn't really seem to be responding very accurately to the minor changes I've been making. I really want to know whats going on. I don't want to keep destroying all the details in the map, and it looked like I was so close to functional originally. Anyone have any experience with this stuff?

[Paria]

i've not encountered the problem before but this was the best explanation on it i could find

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).

in simple terms- is your brushwork clean - free from intersecting world brushes and on grid ? and just how detailed is your map in terms of geometry?

[Ze Inspector]

My brushwork is very clean. I'm very careful about not overlapping world geometry or details. There might be a few cases in this map, but not many. As for complexity. It's fairly complex. I try to keep most of my world walls to 90 degree angles but my details tend to fill those in a lot, with more interesting angles and such. there's a beta of my map here. ctf_secretlab_b1 (http://forums.tf2maps.net/downloads.php?do=file&id=211). if you are curious.

[Vilepickle]

It doesn't matter if they overlap, it happens when detail meets world brushes. I went over this limit on Castle as well. The only solutions are making brushwork into models, or reducing the amount of func_detail touching world brushes

[phatal]

It doesn't matter if they overlap, it happens when detail meets world brushes. I went over this limit on Castle as well. The only solutions are making brushwork into models, or reducing the amount of func_detail touching world brushes

I asked this question before, but don't recall a response. When you say touching do you mean edge to edge or overlapping?

[MrAlBobo]

just by reading his post id say edge to edge...also...im fairly sure someone said it was edge to edge in another topic...

[Vilepickle]

Yes, "touching" as in edge-to-edge. Since that's what a T-junction is.

[Ze Inspector]

In experimenting with this further I found that I could lower the number by pulling these away from other geometry it would reduce the numbers. Though the calculations still seem a little off.

Does anyone know of software I could use to convert things to models? There are a couple of fairly complex clusters of func_details that I imagine are the largest culprits and would benefit from being props. I have Blender but it doesn't seem to do it. Any shareware or freeware that will work? I'm not looking for anything fancy.

[Shmitz]

Blender works quite well for creating props, though I'm not sure it has any specific plugins that would allow you to import map files with brushes to directly convert something. XSI may have something for that, and it's free.

[VelvetFistIronGlove]

Does anyone know of software I could use to convert things to models? There are a couple of fairly complex clusters of func_details that I imagine are the largest culprits and would benefit from being props. I have Blender but it doesn't seem to do it. Any shareware or freeware that will work? I'm not looking for anything fancy.

One place to start:

http://developer.valvesoftware.com/wiki/Converting_brush_structures_in_your_map_into_a_pro p_static_with_XSI_Mod_Tool

It's not trivial to do, though.

[Ze Inspector]

Thanks for the tips guys, I downloaded XSI just now and I'm going through the basic tutorials now. You're definitely right Velvet, this isn't a trivial tool, but getting some working knowledge will help out a lot for future project, and I'll figure it out.

Always good to get another tool for the belt. ^^

[Puddy]

Bump. I saw on another site that func_brushes helped, but was that information accurate? I have this problem on my map.

[Sgt Frag]

I wouldn't rely on func_brushes to solve the issue.

They have options for being moveabe/non-physical and whatnot. Using a few here and there probably isn't bad but using alot of them could probably lead to too much computation and possible lag (don't quote me on that).

But I think they also have issues like stickies not sticking to them.

I used a few in one of my arena maps for small details like rubble on the floor and trim pieces on the wall so I could make them non-physical. That way I didn't have to player clip them and they don't break up vis-leafs. It also kept it balanced for both teams as one side isn't tripping on rubble while the other side is (even though that's a very small gameplay issue).

However I only used like 6 of them in the whole map.

[XFunc_CaRteR]

I am moving lots of func_details to world - func_details that touch world geometry - and it is not making a shred of difference to the number of water vertices that I have.

Any other techniques?

[A Boojum Snark]

Make stuff displacements or models, offset things one unit, there are a handful of ways. However this might help you understand how exactly they are created so you can better tweak things... http://dl.dropbox.com/u/98931/MappingResources/waterindicies.png
(heh, it seems the place it was hosted FINALLY went down, glad I saved that picture)

[FaTony]

props....

[XFunc_CaRteR]

props....

But they don't take nice shadows the way bsp does.

[honeymustard]

I might be wrong here but pl_badwater uses func_lod for certain things (usually roof supports and stair edging) which might help. I'm not sure if this is the same thing though.

[Rexy]

But they don't take nice shadows the way bsp does.

I disagree. And you hurt prop_static's feelings.

[grazr]

As honeymustard has noticed, brush entities such as func_lod, don't cause or recieve this issue. Stair cases are the usual cause for this issue due to the many steps that touch the edges of the trim. turning trims and trusses within buildings to entities such as func_lod or func_brush can cut down on t-junctions.

func_details still cause this issue as they are only fake entities.

(good save Booj)

[stevethepocket]

Did you convert every individual brush to a func_detail instead of by groups? The last person who reported t-junction issues had done this. We never got to test the theory that doing it Valve's way would fix the problem since he had already gone ahead and made models out of most of them.