Basic and effective visual guide to trimming and mittering

[Neon_Knight]

This seems to be one of the most overlooked topics, so until I finished the optimization tutorial, I wanted to leave this simple picture about polygon reduction, otherwise known as "mittering", and trimming. Polycount matters when talking about performance.



A good hint is to activate the "clipper always use caulk texture" in *Radiant. At least GTKR 1.6 and NetR has such an option, as well as "always use caulk for new brushes".

[Suicizer]

Isn't Quake Engine or it's compiler doing this automaticly (as like merging surfaces together whenever possible)?

[sago007]

Isn't Quake Engine or it's compiler doing this automaticly (as like merging surfaces together whenever possible)?

Unfortunately no. idTech 4+ does much of this automatically but not id tech 3. I did annoy me for some time because it sounds like a trivial task that the compiler should do for me. Modern engines can do this at runtime.

The compiler will perform one optimization. Surfaces will be auto caulked if they are completly covered by the void. Structural brushes are part of the void. Surfaces only covered by a detail-brush or patch will not be auto caulked.

I cannot work in caulk-mode. I need the textures.

[Neon_Knight]

I'd say that it's a good thing that IdTech3 doesn't do that automatically. You know, it helps the mappers to develop good practices. Here's an article about over-relying on the easiness of use of the IdTech4 tools.

http://www.leveldk.co.uk/q4tut2.htm

[Suicizer]

I'd say that it's a good thing that IdTech3 doesn't do that automatically. You know, it helps the mappers to develop good practices. Here's an article about over-relying on the easiness of use of the IdTech4 tools.

http://www.leveldk.co.uk/q4tut2.htm

Well, it creates quite a bump for newcomers to the editor as they surely get flamed about the brushwork their first maps. All editors have such trouble (even in Cube Engine 2, where newcomers even manage  to create complete floors of clip or noclip doors which are closed without even wondering the realism or technical aspect about it).
But back to the radiants which work for OA, it's definetly not user-friendly.

[sago007]

I did read dONKEY's article on the subject. And while he has found a rather bad example where the compiler hides the errors in the map.
I do not think the compiler should hide real errors like overlapping brushes but I do think it should handle optimization.

Maybe it is because I often think in code where manual optimization tends to make the code harder to maintain and harder to change in the future. If I want to add a new corridor in a map then it is bad that I destroy all the optimizations that have been made in the progress because I change some brushwork.

For me good brush work is design that makes it possible easy to change the map years later without trouble. dONKEY's example fails at this too.

From an economic perspective it is about exploiting comparative advantages. If the map designer spends a lot of time optimizing for little gain it is not worth it. The time could have been spent on making the game play better.

[Neon_Knight]

Well, that's perhaps why they suggest to plan the maps with optimizations in mind before doing the mapping itself.