Performance Guideline

[Bud Calypso]

Hey,

I'm working on my first own layout. I'm quiet confident referring to it gameplaywise
(until the first test will crush it..).
But when it comes to the technical part, please treat me like a five-year-old.
I'm looking forward to the design-stage, as this is where my talents tend to.

But it would be useful to have a list/ranking of what is bad for performance.
This is meant in a really general way - a simple guideline of what to avoid or keep to a minimum.

For example: Dynamics > Textures > Faces > Props > func_detail

I am aware of this example not being correct (/making sense). As well as you can't tell that across-the-board.
Because optimizing may relativise any of the objects. But a five-year-old needs to have it simple.


A few more specific questions:

Where is the difference in terms of performance between building a wall like this:

Or this and making all the decorations a func_detail ?
(though no more visleaves: more faces = more textures = bad?)

Does it all come down to what gets rendered for the player in an area or does the
overall size / object-count / triggered events have an impact on performance too?

Do tool-brushes (except no-draw) influence performance?

Is a wider variety of used textures worse or does this only affect file-size?

-> Does file-size affect performance or only diskspace and download time?

Prefer a prop over a brush?


This is a very basic lack of understanding, I am aware. But some guideline to start with and learn the why's while doing,
would help me a big deal.

Thx in advance,
Bud



Insider:
When I was about ten years old I wanted to work on my technical flaw and asked my cousin to give me a book about technics.
..in general. This has been a running gag between us ever since.

 

[Tumby]

http://www.optimization.interlopers.net/

Using non-custom textures doesn't really affect anything. Using custom textures affects download time.
Having more polygons/tris/faces affects FPS.
Having a terrible visleaf structure affects FPS.
----Lack of func_detail or too much func_detail
Translucent materials are worse than ones that are either opaque or use alphatest.
----This also includes fading props that are currently fading.
Models are generaly better in performance than brushwork, but it's more difficult to get the lighting right.
The only tooltextures that affect performance are the ones that are meant to affect it.
----nodraw, areaportal, hint, occluder...
Having too many entities of specific types in the map will crash a server.
Playing too many sounds may cause sound problems. It also may not.
Having too much lightmap data will cause clients to crash.


It's also important to consider how much detailing is actaully needed.

http://www.nodraw.net/2010/08/detail-of-tf2-pt1/
http://www.nodraw.net/2010/08/detail-of-tf2-pt-2/
http://www.nodraw.net/2010/09/detail-of-tf2-pt-3/
http://www.nodraw.net/2010/09/detail-of-tf2-pt-4/
http://www.nodraw.net/2010/09/detail-of-tf2-pt-5/

 

[MoonFox]

personally from my experiences:
having a layout planned out will help the point set up faster, but not the overall detail of the surrounding areas and skybox.
skyboxes should not be tight around the map in all situations, the only exception being the sky is the only thing seen.
When designing walls, colors play an important role, you don't want a deep purple next to a lime green, it just isn't color appealing (that's why I hate the lakers... that purple and yellow) and example I have from an older map: Tan beige, next to stone and white. (wood wall onto a snow covered wall)
Props wise, there is a limit, and if you exceed that limit you will get in game errors, and in editor errors. Dynamic props are the worst offender, if I remember correctly you can only have about 10 dynamic props in function. (dynamic props should only include the doors, but the way to extend the limit is by making frames of doors Prop_detail)
Brushes do not affect performance, often times they improve performance, however once you start face editing and manipulating how things are aligned in regards to LS (Light source) can leave things extremely dark when it should not be, or appear extremely flat.
Props do no affect performance, and from someone who uses multiple tools for map editing, often times in the case of UDK, you have the floor and maybe some walls, but the general majority of design comes from props. Do not mistakes this to wild with props, for the most mart Props do not affect performance, however, once you hit a threshold, the map take a long time to render, and it will crash often. It will be a give and take.
Lastly, and I know you didn't ask for this bit but I'm going to share it anyway. Make sure you can clearly define the borders of the map. It will help you design your map, and allow players to known the limits of the map.

 

[Tumby]

you don't want a deep purple next to a lime green
that's why I hate the lakers... that purple and yellow

You have no idea how colors work. So i will just leave this here:

 

[killohurtz]

personally from my experiences:
having a layout planned out will help the point set up faster, but not the overall detail of the surrounding areas and skybox.
skyboxes should not be tight around the map in all situations, the only exception being the sky is the only thing seen.
When designing walls, colors play an important role, you don't want a deep purple next to a lime green, it just isn't color appealing (that's why I hate the lakers... that purple and yellow) and example I have from an older map: Tan beige, next to stone and white. (wood wall onto a snow covered wall)
Props wise, there is a limit, and if you exceed that limit you will get in game errors, and in editor errors. Dynamic props are the worst offender, if I remember correctly you can only have about 10 dynamic props in function. (dynamic props should only include the doors, but the way to extend the limit is by making frames of doors Prop_detail)
Brushes do not affect performance, often times they improve performance, however once you start face editing and manipulating how things are aligned in regards to LS (Light source) can leave things extremely dark when it should not be, or appear extremely flat.
Props do no affect performance, and from someone who uses multiple tools for map editing, often times in the case of UDK, you have the floor and maybe some walls, but the general majority of design comes from props. Do not mistakes this to wild with props, for the most mart Props do not affect performance, however, once you hit a threshold, the map take a long time to render, and it will crash often. It will be a give and take.
Lastly, and I know you didn't ask for this bit but I'm going to share it anyway. Make sure you can clearly define the borders of the map. It will help you design your map, and allow players to known the limits of the map.

Okay...there are so many things wrong with this post

• Color and texture choices do not affect performance in the slightest, so I'm not sure why you mentioned that.
• You can have a LOT more than ten dynamic props in a map before they start to impact performance.
• Dynamic props are not limited to doors.
• Detail props are those tufts of grass and shrubs you see on displacements. Door frame models should be prop_static, and door frame brushes should be func_detail.
• Brushes DO affect performance. During compile, they indirectly affect performance by shaping the visleaf structure, which in turn affects the number of brush faces being rendered by the client.
• Props also affect performance. In large numbers they are expensive for the client to render due to the number of tris. That's why it's important to use visibility control methods like prop fades to hide props that are out of sight.
• Source != UE. You should not be relying on props to define your map layout. That's what brushes are for.

 

[MoonFox]

Okay...there are so many things wrong with this post

• Color and texture choices do not affect performance in the slightest, so I'm not sure why you mentioned that.
• You can have a LOT more than ten dynamic props in a map before they start to impact performance.
• Dynamic props are not limited to doors.
• Detail props are those tufts of grass and shrubs you see on displacements. Door frame models should be prop_static, and door frame brushes should be func_detail.
• Brushes DO affect performance. During compile, they indirectly affect performance by shaping the visleaf structure, which in turn affects the number of brush faces being rendered by the client.
• Props also affect performance. In large numbers they are expensive for the client to render due to the number of tris. That's why it's important to use visibility control methods like prop fades to hide props that are out of sight.
• Source != UE. You should not be relying on props to define your map layout. That's what brushes are for.

yea... sorry bout that... I guess im still not used to the UDK editor... been using that cause hammer doesn't work for the moment.

 

[MoonFox]

You have no idea how colors work. So i will just leave this here:

I know how colors work. but color does have an effect subconsciously, red is aggression, blue is thought. So having colors that can play off each other are what you need. and the color wheel thing does help newbies.

 

[Bud Calypso]

Thanks for the quick replies.

I changed the overall layout three times now. It turned out naturally like many advices of an older thread here
(which I forgot the title of), discussing how you should start.
The gimmicks were light-based but actually optional given a second thought. So I cut them out.
It's a way more simplified layout now as it is decreased in scale. Because even for this I will need at least two more weeks
of my speed to finish it to.. something.

At this point the layout feels right and set up. So I need to know what to use constructing it.

It's easier to find out the properties of elements, but harder to see them in comparison.
So I do know somewhat about func_detail and too much of anything can't be good,
but to which amount and more importantly: what to prefer in which situation?

Let's say we want to build a cathedral for TF2 (I won't).
Can we build a brushwork glass dome, precise wall decorations, make it func_detail and it's fine with FPS?
Or should we look out for a dome-prop, keep the func_detail decorations to a minimum and try to
achieve a similar look by clever texturing? Can we add swinging bells to that with an ambient_generic,
colored windows and then make this cathedral the center cp?

See, this is an example and I don't want to waste your time with specific questions over and over.
But help me compare these elements to each others as generally as possible.

 

[MoonFox]

Let's say we want to build a cathedral for TF2 (I won't).
Can we build a brushwork glass dome, precise wall decorations, make it func_detail and it's fine with FPS?
Or should we look out for a dome-prop, keep the func_detail decorations to a minimum and try to
achieve a similar look by clever texturing? Can we add swinging bells to that with an ambient_generic,
colored windows and then make this cathedral the center cp

for the specific cathedral model, I would do the roof last instead of first.

 

[tyler]

Examine Degroot Keep. The geometry is similar and would also be highly detailed in real life, but you can easily see what is flat brushwork, what is func_detail, and what is a model.

 

[DonutVikingChap]

This is what makes me really excited for Source 2 since having everything made out of meshes will hopefully mean we won't have to care so much about this stuff.

 

[killohurtz]

You are correct in thinking that intricate wall decorations would be good as func_details. When vbsp runs, it basically tries to fill all of the empty space in your map with convex volumes called visleaves. You can get a visual representation of the visleaves in your map by running only vbsp on the Run Map dialog (and not launching the game afterwards), then clicking Map > Load Portal File.

Good choices for func_details are any brush that does not effectively block a player's vision - things like support beams, thin pillars, trim, door/window frames, and individual stairs. Next, look for brushes with lots of faces (like cylinders) as these will create a ton of cuts and result in messy visleaves. If the cylinder was large enough to block player view, you can stick a square nodraw column inside of it after converting it to func_detail.

 

[tyler]

Also you can look at how Gorge does a dome.

 

[Bud Calypso]

Examine Degroot Keep. The geometry is similar and would also be highly detailed in real life, but you can easily see what is flat brushwork, what is func_detail, and what is a model.

Good idea. I'll try to get some clues..

And suddenly I can remember the name of the thread I quoted.

[TIP] Things To Avoid When Designing Your First TF2 Map
http://forums.tf2maps.net/showthread.php?t=18699

 

[Bud Calypso]

You can get a visual representation of the visleaves in your map by running only vbsp on the Run Map dialog (and not launching the game afterwards), then clicking Map > Load Portal File.

Good choices for func_details are any brush that does not effectively block a player's vision - things like support beams, thin pillars, trim, door/window frames, and individual stairs. Next, look for brushes with lots of faces (like cylinders) as these will create a ton of cuts and result in messy visleaves. If the cylinder was large enough to block player view, you can stick a square nodraw column inside of it after converting it to func_detail.

tyler and worMatty helped me understand visleaves better in my first thread.
I'm not confident with it and I will need to learn using the tools (areaportals, hint) correct and clever, but I think I understood it now to some extend.

But I haven't thought of the no-draw cylinder trick. This will help.
Myself would have argued with two brushes at the same place. I usually try to avoid that..

 

[tyler]

If your cylinder is big enough that sticking a square nodraw brush inside it is helpful, you might be better off just hinting the outside of it and leaving it a world brush instead.

 

[Pocket]

Freestanding nodraws are unlikely to do anything to reduce rendering. A func_occluder might be useful, though, since they forcibly block visibility of any models behind them — like an inverse areaportal — regardless of anything to do with visleaves.

 

[tyler]

Occluders are high level dark magic, though. Used incorrectly they can negatively impact performance.

 

[Pocket]

Sticking one inside a large solid object that needs to block rendering for some reason sounds like a correct use to me. I know there are a handful stretched across actual walls in some maps, and I've never bothered to examine them and figure out why that might be, but the ones covering the shipping crates in Granary makes perfect sense to me: Props don't block or even cut vis, nodraw would have messed with the lighting on the prop itself and probably not actually blocked anything anyway, and you could have most of the enemy team running around behind that crate. Though even that strikes me as a case where if you did have performance issues without the occluders, you'd probably have those same issues anyway if you were seeing things from a less convenient angle.