[TUTORIAL] Quick and Dirty optimisation

Discussion in 'Tutorials & Resources' started by Tapp, Jun 26, 2010.

1. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
Optimisation
We all have to face it. We all fear it. And very few of us understand it. But I've decided to throw together a tutorial which brought my map's fps up from 30 to 45. This tutorial is by no means a complete guide to optimisation, but it's certainly better than nothing.

I’m going to assume here that you already understand what should and shouldn’t be a func_detail. For the purposes of this tutorial, I have func_detailed anything that you cannot hide behind. I’ve removed 2 ramps near the bottom of that picture because you can’t really hide behind them, but I’ve kept all the walkways because they can block rendering when looking up or down. I’m also going to assume that you are still in the blocking stage, and don’t have too many tricky details to work around.
Hints
Hints are one of the most difficult, yet most efficient, forms of optimisation. This is because you need to understand how optimisation functions in order to use them. This is the model I’m basing this tutorial on:

This works fine, except when Vis screws up, and messes with the visleafs, as per the right. This is prevented by adding hints that run perpendicular to the wall, resulting in the good scenario. If you have a large wall, simply duplicate it, stretch it in both directions perpendicular to its face, and turn it into a hint brush.

Of course, keep in mind that each brush can only have 2 faces textured with hint, the rest need to be textured with skip. For this scenario you need to use 2 brushes, and remember to texture the ends and bottom with skip. When putting this into practise, it’s inefficient to do this for every single brush, which is why I make a grid out of hint brushes. Keep in mind that the grid method will not work for all maps. It works best for mine because my map is built on a nice 128x128 grid, so the faces all line up. Just try to run the faces textured with hint across the ends of as many world brushes as possible, perpendicular to the largest face.
For example, here's a typical world brush, with this method of optimisation

Keep in mind that hint brushes only need to run until they intersect with a world brush

And of course, you always need to run planar hints over the levels of your map.

You can use hints in both directions, as long as they run perpendicular to at least one large face. It's find if hints intersect.

Here I've started nodrawing the skip faces, so that it's easier to understand the more complex examples. In reality you should keep them as skip, and not use hints 1 unit thick.

When a structure has multiple levels, make sure to run the hint brushes above the next floor, if they're on the outside.

Here's an abstract version of a switch-back. Note how the hints don't run on the inside, because then they wouldn't be perpendicular to the large faces.

With large blocks, hints can run in both directions

Here's a typical house

Using hints for the doors and windows looks painful, but is beneficial. The goal is not the connection through the doorway, but blocking the connection through the surrounding walls.

Of course, areaportals are not to be skipped on.

However, in this situation, there would be an areaportal leak. Either add a huge areaportal in the top (undesirable)

Or simply cover the roof

Finally, this is an example of a situation in which one should use occluders:

• Thanks x 1
Last edited: Jun 27, 2010
2. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
As a general rule, the more z-fighting you have, the better.

At this point I’d like to plug doors. Yes, I’m advertising doors. The automatic doors in tf2 are excellent for ambushes, are very popular among demomen, detect invisible spies, are the only plausible way of blocking bullets but not players, and most importantly, work wonders for optimisation. If you were smart enough to use these doors, duplicate all the door brushes, move them to the side, texture them areaportal, make them into func_areaportals, remove their names and tie them to the door they were created from, before moving them back in place. Be sure, however, to seal the surrounding area.

In this case, I would run into an areaportal leak. If you can fly from one side of an areaportal to the other, without going through another areaportal, then you have a problem. Simply add some always open areaportals to seal the area, and you’ll be fine.

Occluders are a very tricky thing. They dynamically hide models behind them, making them extremely valuable when there’s a large object in an open space. However, occluders are also quite costly. Where areaportals need to test what visleafs can be rendered through them, occluders need to trace to every model. Use occluders only where they are necessary, and are efficient. The aforementioned large object in an open space scenario is the best time to use them, but make sure that it’s a high traffic area. I’ve only got 4 occluders, and I’m not even sure if it’s worth keeping them.

One should also keep in mind that occluders with complex geometry will destroy your frame rate. Had I fit the two occluders in the centre perfectly onto the geometry, it would have done far more harm than good, even if the entire team was on the point simultaneously. Use them only in high-traffic areas, as player models are your biggest optimisation concern.

• Thanks x 1
Last edited: Jun 27, 2010
3. PasserbyL2: Junior Member

Messages:
99
Positive Ratings:
15
isnt that kinda overkill extending the vis compile time by that much and causing the game to have to calculate the culling of a ton of areaportals at ounce isn't really going to help fps too much.

I believe optimization takes a more subtle hand i usually areportal off rooms that are expensive. and do i lot of walk-throughs of my map with mat_wireframe on to find problem areas and optimize those areas that way i can get the fps back up in areas that tned to make it drop and still keep a good compile time. and for other parts of the map if they work with a good fps dont fix it cause it aint broken..

• Thanks x 1
Last edited: Jun 26, 2010

Messages:
4,769
Positive Ratings:
5,550
I winced the whole way through... I'm not sure if it's proper to explain optimization on such a horrendous shell to begin with that should never be constructed for gameplay reasons, let alone optimization thoughts.

• Thanks x 2
5. aaFreyjaIt hurt itself in it's confusion!

Messages:
2,918
Positive Ratings:
5,326
Brought your map FROM 45 DOWN to 30?

• Thanks x 1
6. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
I'm not sure exactly what the problem with this tutorial is. It produces some of the most efficient visleaf setups, and while not exactly perfect for compile time, shouldn't be used for each and every compile. And what do you mean by 'a horrendous shell'? The amount of processing required to change visleafs is nothing compared to how much rendering this saves. If your problem is how it looks in hammer, then what does that affect the final map? If your problem is the compile time, what difference does compile time make to the final product. The only problem this method has is file size, which is a difference of a few megabytes.

Messages:
4,769
Positive Ratings:
5,550
My point is, the structure you have created is a huge swiss cheese mess of ramps and doorways. Such a thing would never be created in a real scenario, and using it to show optimization in this... extreme manner may be more confusing than helpful.

• Thanks x 3
8. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
Ok, I'll change it to some smaller and more easily understandable examples.

Last edited: Jun 26, 2010

Messages:
778
Positive Ratings:
803
Tapp, if you want you can use my map as an example one, it needs some optimization and I don't think it'll be to overbearing. =) Just throwing that offer out there.

10. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
Sure, that sounds good. I'll use your map as an example, rather than my swiss cheese.

11. aaRavidgeGrand Vizier

Messages:
1,544
Positive Ratings:
2,522
I'm sorry, but this isn't any good I just felt I needed to be honest.

The map you're using for helping people understand is impossible to optimize in the first place. Secondly the hint method you use is not just "quick and dirty", I would like to add "ridiculous and bad" to that. It doesn't show just how powerful hints are.
Using func_viscluster to cover up the horrible hint job is just not the way to go about it.
Areaportals and occluders are among the easiest ways to optimize and yet you kinda skim over them.
You don't mention prop fading anywhere in the guide, which also is very easy and quick way to greatly increase fps of a detailed map.

Personally, I would not suggest this guide to a person who is new to optimization, in it's current format atleast.
I hope you can improve it.

12. aaStickZer0💙💙💃💙💙

Messages:
664
Positive Ratings:
668
You hinted the map to this extent...

and then used func_visclusters?

That's a total fail right there :/
If you wanted to optimise this, just func_detail all the odd brushes that aren't blocking visibility in any way, and then add occluders. I doubt areaportals would help there

13. aagrazrOld Man Mutant Ninja Turtle

Messages:
5,437
Positive Ratings:
3,780
If you're going to cover optimisation and compile times you really need to cover func_detail's more comprehensively. You should also explain the corrolation between visleaf formations and compile time and why face render counts should be culled at all. You kinda beat around the bush here and never really touch on the point with any focus. Plus the methods of optimisation were executed in ways that wouldn't have been realistic/appropriate. You should really offer some realistic examples so people can better understand the scenario they are dealing with.

Your example doesn't really demonstrate any of the important factors in a legible way, not to mention you've picked a subject that has been explained 100 times on pretty much any source related website. You need to include something the other tutorials havn't to justify your time on it and why people should read yours over the other 100 hint/visleaf related tutorials else where; func_viscluster was one way to go but it looks like you don't fully understand them either.

Also, to have made your tutorial more in depth you should have explained how sight lines work and provided in game examples of your results to prove that what you are talking about works. If you had done that then i think you'd have probably also realised how poor of an example your current scenario was in demonstrating the important points.

edit: Plus it just looks hastily posted, some of your images weren't cropped properly, such as the last 2 in your first post.

edit2: Also your occluder image is exactly how not to execute occluders; you only texture the face that is supposed to cull objects behind it. You need to nodraw the sides (and the back if it's not beneficial to have the occluder brush work both ways).

You need to plan and prepare your article more carefully, plus when dealing with such an intricute subject even ask for help and read all the tutorials you can yourself, because you clearly got some ideas mixed up.

• Thanks x 2
Last edited: Jun 27, 2010
14. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
Thank you grazr, you're the only person so far who has had some reasonable criticism. Looking over your post, I realise that I've missed a few things in the tutorial. The tutorial was hastily posted, due to time constraints and general rushing. I've taken down the parts on func_visclusters and will focus the tutorial more on what I haven't seen in other optimisation tutorials. Thank you for the information on occluders, too, as that's something I didn't know until now. Hopefully I can fix up this tutorial.

15. aaAcumenAnnoyer

Messages:
704
Positive Ratings:
626
just because people are honest, you don't have to be sour or bitter
grazr sure is not the only one with justified criticism.
i think you just expected more acceptance and praise on your tutorial take of a topic that has been discussed quite often and been covered with much insight already.
i mean, they can't say "hey good job" if there's some fundamental understanding issues yourself. i doubt there's a way of putting this "nice and friendly".
i think you can accept the fact, that there's quite some things to learn...well, or you can't.

i'm myself are no mapper by any means, but i'm always interested in reading through mapping related tutorials and i have to say that i've read through a lot of optimization tutorials and yours just looks a tad messy and "displays" (at least to me) that you haven't got the total optimization grip by yourself. as others have stated the example is not very reality-like and the pictures just come with no explanation of why you did certain things, yet it looks totally confusing.

i know that sounds brutal and unfair, but that's just how i see it, i'm afraid.
it's really cool that you wanted to contribute to the wonderful resources in here, but maybe the topic just wasn't meant to be fitting. it's quite complex and nothing that should be done "quick and dirty" anyways.
in all honesty i don't think you should even try to "fix" this tutorial. it would be just wayyy too much work imo. proper research, proper pictures and examples. and in the end i'm quite sure you wouldn't tell people anything that they couldn't have read in another optimization guide already. i'm sorry - i really am :/
if you really want to contribute with a tutorial why not pick something less complex that would really help people out. i'm sure there's other topics to write about !

16. aagrazrOld Man Mutant Ninja Turtle

Messages:
5,437
Positive Ratings:
3,780
Occluders work in real time and can have a significant impact on performance as a result, the larger the occluders surface area the more of a strain on resources they are, this is why we nodraw the sides. Because they wont be useful but still take up space in our resource budgets. But i guess you can take the initiative and read further into them.

I would recommend making your images no more than 600 pixels wide as this is the maximum width for images in a forum post before they are automatically re-sized. This can be a pain when there are as many images as there are in your posts as they cause the page to jump around a lot while the images get cached. This then also allows you to better format your images on the page.

You should also format your page into subject areas/chapters. This way people can navigate to areas that are most useful to them. Also, it provides breaks in an otherwise cumbersome article, just like a sentence in a paragraph. People can see a sub-topic's conclusion and assimilate the information before moving on. Rather than trying to take in the entire article at once.

If you're having difficulty setting up your own example scenarios, to help explain the details, simply use real scenarios from Valve maps.

Last edited: Jun 27, 2010
17. TappL10: Glamorous Member

Messages:
776
Positive Ratings:
215
All I'm hoping to do with this tutorial is show new mappers one of the easier ways to use hint brushes: by running them perpendicular to large faces. So far I haven't seen that in other tutorials, and really, I might as well just stick with that sentence. Instead I'm going to look over †Blade†'s map, to show the best real-world examples of that simple technique. And while yes, I am being a bit sour over some of the comments, a few of them are redundant.
Good points: