Pages: [1]
  Print  
Author Topic: Basic and effective visual guide to trimming and mittering  (Read 5193 times)
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3656


Trickster God.


« on: December 24, 2013, 03:27:54 pm »

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".
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Suicizer
Member
Member
*

Cakes 2
Posts: 400


WWW
« Reply #1 on: December 24, 2013, 03:56:10 pm »

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

I'm good at everything but can't do anything...
sago007
Posts a lot
*

Cakes 61
Posts: 1645


Open Arena Developer


WWW
« Reply #2 on: December 25, 2013, 01:33:07 pm »

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

There are nothing offending in my posts.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3656


Trickster God.


« Reply #3 on: December 25, 2013, 03:58:03 pm »

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
Logged


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Suicizer
Member
Member
*

Cakes 2
Posts: 400


WWW
« Reply #4 on: December 26, 2013, 06:04:54 am »

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.
« Last Edit: December 26, 2013, 06:19:32 am by Suicizer » Logged

I'm good at everything but can't do anything...
sago007
Posts a lot
*

Cakes 61
Posts: 1645


Open Arena Developer


WWW
« Reply #5 on: December 26, 2013, 09:05:01 am »

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

There are nothing offending in my posts.
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3656


Trickster God.


« Reply #6 on: December 31, 2013, 10:15:31 am »

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


"Level Designers are 1 part architect, 1 part artist, 1 part game designer, and 1 part beta tester!" Cliff Bleszinski
Want to contribute? Read this.
Pages: [1]
  Print  
 
Jump to: