Explain T-junction to me.

[Hipshot]

Hmm, seems to have forgotten what that really is, the impact and that. I remember that Y explained alot to me/us about that when there were discussions around my tvy map. What I don't know is, what is good and what is bad, more general over more game, not just Q3.

Any documents on this or someone that can share what they know?

[Silicone_Milk]

Here's what I came to gather from about a year - 2 years ago. I could be completely talking out of my ass here but I'm pretty positive this is right...

T-junctions are when one or more brush edges come into contact with an edge of another brush in such a way as to form a kind of split or a T

Say we have an edge like this -------------
then we make two brushes like
| | |
| | |

and we line them up against the horizontal edge
| | |
| | |
------------

if you look at the middle line (shared edge between the two vertical brushes) and see how it comes into contact with the horizontal edge in a 90 degree angle to form a upside down T, you have a T-junction

This can cause minor issues like sparklies ingame. It's generally just bad form to do if you can help it =)

Hope this helps AND if I happen to be wrong, feel free to correct me somebody hehe =P

here's a Screenshot =)

[Black_Dog]

The compiler will usually split things at t-junctions in order to prevent problems, so brushwork t-functions shouldn't be a problem unless you compile with -notjunc or something.

However, since face splitting can't be done for patches you need to contruct things such that patches don't cause t-junctions.

[Silicone_Milk]

ah thank you. I didn't know that. Ill keep that in mind =)

So.. hypothetically I could make every brush in such a way as the enitre map is a bunch of T-junctions in the editor and the actual editor will divide them up to prevent problems? And... this would I mean I shouldn't worry about arranging my brushes properly to prevent these t-juntions UNLESS
the auto-dividing creates problems itself that should be avoided if possible?

[obsidian]

You shouldn't rely on the compiler splitting, depending on the situation, it may or may not automatically split the brushes for you. With Silicone_Milk's example, yes it will split, but there are other instances that will not.

[Foo]

Also bear in mind that the automatic splitting doesn't care one jot about doing it in an efficient manner. It will usually create a lot more triangles than if you manually arranged the joints.

Hang on, I'll up a demonstration.

EDIT: Here. In the example below (an actual piece of floor work in my next beta) if you didn't take the time to remove all the T-junctions, you would end up with a very high number of triangles.

The way I've arranged the pieces there creates no extra splits. I think it uses the fewest brushes as well, but I dunno for sure

[pjw]

I dunno for sure

You are correct.

Another thing to keep in mind about doing it yourself vs. relying on the compiler is that it's simply good practice to build stuff in an efficient manner.

(Although, as has been pointed out, the only time you're usually going to get an actual visual problem is when you have T-junctions between brushes and patches. Generally, IMO, the Q4 editor is even more forgiving/efficient than the basic Q3 compiler was, and will often merge stuff that you don't even want it to merge...e.g. raising your lightcount numbers.)

[Shallow]

I think it's entirely possible to go too far with cutting brushes at weird angles to optimise the number of triangles you're getting, in fact mapping that way is probably a big part of the reason that I could never face finishing this Wolfenstein: Enemy Territory map.

The map was very large and had a lot of fairly dense urban areas with complex brushwork, so I was pretty anal about cutting stuff to triangulate nicely to keep the triangle counts down. The downside to this is that when you need to change something, you're faced with a mass of rhombic and triangular prisms, and it's no longer as simple as it would have been if the brushes had been left as cuboids. In fact it's about as much work as building it in the first place was in some cases.

Basically, I wouldn't recommend beating yourself up by getting into over-zealous optimisation until you're nearly finished and you're really, really damned sure that the layout is done. That's as far as Q3 goes anyway, in the D3 engine the compiler does seem to handle cutting squarish brushes efficiently much better, and indeed replaces triangulation the mapper has created with it's own best guess in a lot of cases.

[Foo]

Yes, I would definitely agree on this.

For the final build of the level, it's a good thing to strive for perfection... but on all the pre-release versions I would go so far as to disregard it completely.

[wviperw]

For Q4 I've been exceedingly lazy in much of my placing of brushwork... and it's felt so good. The triangulation of the level geometry seems quite good and for the most part it seems to handle being a bit sloppy. It even handles culling unseen faces which, I have to say, is a wonderful thing. No more making sure all brushes are cut and caulked perfectly.

I'm all about good algorithms that take over the mundane jobs of a mapper. Leaves me to focus on more imortant things, like finding time to map in the first place. :P

[pjw]

The downside to this is that when you need to change something, you're faced with a mass of rhombic and triangular prisms, and it's no longer as simple as it would have been if the brushes had been left as cuboids. In fact it's about as much work as building it in the first place was in some cases.

This is a very good point; especially when you're working on something that something that's part of a group/team project, as opposed to something that's entirely your own.

When working with others, you're going to make people long for your death if you cut something up in funky complex ways, and someone has to work on it after that...

Certainly leave this sort of optimization for late in the development cycle, and then (as wvw pointed out) it's not always going to be necessary.

There's a spectrum of "good, clean, efficient design" which, on one end, means simply not having things all screwed up, having everything neatly on-grid, etc., and on the other end means going to great lengths to optimize as much as humanly possible (e.g. optimal brushwork cuts).

Where you operate within that spectrum depends on your own degree of analness, the development phase of the project, and the needs of other team members.