optimization of this map

Okay thats basically what the map looks like from the top. It's a wide open area (which wasnt possible with HL1 engine) so I had to give it a try on source.

The ground (blue/yellow) and the mountains (brown) are just displacements. The green areas are buildings.

So my ideas how to improve the map stability are:

• use NODRAW on the floor under the displacements and on unseen brushes
• use func_detail for most of the parts of the houses
• remove empty skybox space (somehow)
• use somehow HINT, AREAPORTAL and FADE-Properties to block the view

How would you add/adjust the latter? Im a total noob @ these new functions

If you have time you should decompile this map and have a look at how he has done his optimization. I haven't done it myself but I ran around the map in noclip mode and it was nicely optimized every time you went behind a cliff and such.

Anyway..

Essentially, the quantity of polygons that are onscreen at once will determine your general frame rate, plus effects stuff like dynamic lighting, reflections and whatnot. So what you want to do is have the least amount of polygons onscreen as possible while not harming or sacrificing the detail that you want in the map.

So you want to:

• Not render the polygons that can't be seen by the player. You can do this by having an efficient map layout (strategically placed mountains/cliffs so you can hide the stuff behind them) and using things like hint brushes, areaportals and whatnot.

• Compile with full vis so the game already knows what can be seen from where and dosen't have to work that stuff out on the fly, frees up some cpu power.

• If you have heavy global fog in the map you can set a draw distance so that things beyond that distance won't be rendered. Very effective technique used in lots of older games.

• Set individual draw distances for smaller insignificant models, it's in the settings somewhere.

• Nodraw every surface that can't be seen by the player.

• Use displacements with a bigger grid size so there is less polygons.

• Increase the scale of textures (without harming the look of the map) to reduce polygons, a bsp surface is cut wherever the texture tiles.

• Don't put too much detail in the map, as long as the detail is consistent throughout the map, it dosen't really matter how detailed the map is.

• Disable shadows or collision detection on models where either is not necessary.

• Increase the light map scale of surfaces. The smaller the lightmap scale the more the brush is cut thus more polygons. You'll find that many surfaces in a map don't need the default 16 lightmap scale. The bigger the scale, the better performance wise.

• Entities do not block vis, so don't make large brushes that could potentially be hiding lots of stuff an entity.

• Don't tie brushes that are far away from eachother to one entity. If you tie multiple brushes to an entity, if one brush can be seen, they are all rendered.

• Make smaller brushes no part of the maps hull func_detail. Non entity brushes that touch eachother cut eachother up and create more polygons.

But yeah, that's just a few things that came into my mind. The best thing you can do is have an efficient map layout so that not too many things can be seen at once and you can use with ease things like area portals. Because no amount of optimization is going to make a huge open area with lots of detail run smoothly without sacrificing the visual quality of that area.

Hope that helps, I'm sure you already knew most/all of what I said anyway.

---

Aaron's Stuff

what game is this for?

Aaron's pointed out a lot of options but one thing I can't tell from your sketch is the grid orientation. Is this an actual vmf yet? If so, post a top-down screenshot, and a couple of 3d views, with absolutely all details and brush entities turned off in visgroups. The only thing that should be checked off is 'world solids'.

Okay what Ive done so far is 1) func_detail to complicated and small brushes (awesome result comparing compiling time); 2) put NODRAWs on all unseen polygons; 3) enlarged the light boxes on the big area textures; 4) I placed gigantic NODRAW-blocks inside the mountains - they do block vis dont they ^^ I also might add some to the floor which is sometimes blocking the sight too.

my problem is I dont know how to put HINTs and AREAPORTALs in a way they are useful. Could you gimme a hint?

Well, in a big open area like that, areaportals may not be the best solution. But certainly hint brushes are capable of divising the area up properly. The thing about areaportals is that they must seal off spaces from one another. That is, you should not be able to draw a line from one face of the areaportal to the backface of the same areaportal without going through another areaportal. That means the spaces they cut up can leak if a crack is left open even if the overall map is sealed properly. So, when you're dealing with a big open area like this, all you can do is add strategical hint brushes. -The only place to add areaportals would be at the doors and windows of each of your buildings, so that you guarantee that the engine will never render what's inside them until the player gets close enough.

Of course, there are all the other techniques outlined on that optimization page, but in this case, I don;t think areaportals are going to be able to help you properly.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

yeah I thought so, but the question was more about HINTs anyway. How would you place them looking at the map overview.

aaron_da_killa said:
If you have time you should decompile this map and have a look at how he has done his optimization.

wow this map looks extremely awesome. My map looks shitty in comparison

Well, you could place hint brushes in just-above-player-height through the entire map. Depending on the height difference, the upper left small details might not be visible to the center area.

I wouldn't worry as much about the large displacement areas, though. Just make sure that eventual buildings aren't open towards the center of the map, so the inside doesn't usually have to be drawn (or use func_areaportalwindow brushes to close off windows or doors).

For very large areas, setting LOD fade-out distances for smaller props might make sense.

Also you might want to sacrifice some openness to performance by changing the layout a bit. Do the upper right and lower left parts have a line of sight to each other? Maybe you can block it off with some high mountains?

Generally, I wouldn't worry that much... The (comparable?) Sandtraps chapter in HL2 isn't optimized that carefully either, except for a few huge func_occluders around rock formations. Displacement landscapes are allowed to be big in the Source engine. I would rather worry about indoor areas like buildings/caves. There you can use areaportals heavily.

Also resist using expensive reflective or refractive water shaders. Those are what's killing performance in 90% of all cases.

reaper47 said:
Well, you could place hint brushes in just-above-player-height through the entire map. Depending on the height difference, the upper left small details might not be visible to the center area.

Also you might want to sacrifice some openness to performance by changing the layout a bit. Do the upper right and lower left parts have a line of sight to each other? Maybe you can block it off with some high mountains?

I'm not quite sure how to set HINT brushes. Here's a sideview of how the map looks like with the passable mountain. where and how would you set the HINT brushes and why (Ive read tutorials about HINT brushes, but somehow I just dont get it)

About the line of sight: on the overview from above it looks like a line of sight, but actually the terrain blocks your sight. Displacements dont block vis though and Im not sure even if I placed brushes inside (which I did) if it has any effect as theres still no brush in the sky so VIS probably sees about it.

During vbsp compile, every part of your map is split into convex 3D areas between every world brush.

vvis later checks which of these areas is visible to each other.

Each brush side with a HINT texture artificially splits up these areas, creating new ones. If any tiny bit of area A is theoretically visible to another area B (even if the player never gets to a position where he can see it), it will be drawn in-game while in area A. That's why, if you turn on "mat_wireframe 1", you can often see geometry that is actually hidden behind a wall.

Smart HINT brush placement (it takes some practice) can help vbsp to split up your map intelligently and make sure that major areas are never visible to each other.

Here's what your map could look like using the areas automatically created by vbsp. I assume that you place normal world brushes using the NODRAW texture beneath the displacements (displacements themselves don't block visibility). Because vis areas tend to be very high on maps with large, open skies, these high areas can see each other, so even if the player is running around at the bottom, the area behind a mountain might be drawn! By placing a HINT brush above eye-height (most importantly, beneath mountain-height), you can correct this:

big thanks for the helpful answer! I understand the 2d picture I think, but how does that work on a 3d map? can you make it mono-directional or will there be a problem on the third dimension? There wont be a brush blocking the sight and the mountain is not completely from left to right as you can see on the overview.

wah.. I have a real mapper's burnout syndrom here. I made so many cool details that I feel I cant make any more right now you know that? it feels like theres so much work still left on the map that it seems like eternal mapping.

btw is there a good environment design tutorial for source? I think Ill have to pimp my landscape -lol-

I can only recommend this (very extensive) optimization tutorial: http://rvanhoorn.ruhosting.nl/optimization.php?chapter=intro

There are a million tutorials on displacement editing (fewer on making displacements look good...), I can't really pick either of them. Just search this site or google.

reaper47 said:
I can only recommend this (very extensive) optimization tutorial: http://rvanhoorn.ruhosting.nl/optimization.php?chapter=intro

I had read all of this already before posting the thread

Don't feel bad, I don't get Hint Brushes either. I dont get the hint.. hahahaha

reaper47 said:
There are a million tutorials on displacement editing (fewer on making displacements look good...), I can't really pick either of them. Just search this site or google.

I wasnt actually looking for a displacement tutorial. Im good at making displacements, because it's similar to another design program Ive been using. I was more, like, looking for a way to improve the look of environments with details (maybe I will take a look at the single player missions again)

What exactly don't you 'get' about hint brushes? That optimization guide is probably the best explanation of it on the net there is. If you want to see how vis will see your map without the details that don't block it, simply turn off all your displacements, func_details, and props off under the auto tab of the visgroup box. so that you should only see hint brushes and world brushes. From there, you can begin to assess how the level will cut up your map. Remember, Hammer automatically cuts up your level based on every 1024th grid line your map covers, whether there is a hint brush there or not. (These lines are denoted in red in the hammer 2D views).

I could try and help answer any specific questions you might have over chat, if that's what might help you the best. My Steam account link is listed on my SnarkPit profile.

As far as trying to make your environments detailed, then you're in the same boat as everyone else. Just look at the maps that inspire you. Think of the Valve maps as a sort of standard to be met. I imagine you've played Episode 2 eh? -Plenty of big outdoor environments.

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

"Muhnay" said:
Don't feel bad, I don't get Hint Brushes either. I dont get the hint.. hahahaha

. I've never used a hint brush before so I may be wrong, but I'll give a shot at explaining what a hint brush does.

Assuming you understand the importance of wanting to only render what the player can see rather than what the engine can see...

Your map is divided up into sections by vis (one of the processes that run when you compile a map) called leafs. As you walk through your map in game, only leafs that the engine can see are rendered. Leafs that the engine can see from a specific spot is either determined by vis or is determined dynamically in game. Remember, leafs are chunks of the map, including models, brushes, npcs, displacements, crates etc etc.

Now, vis the program that determines these leafs isn't perfect, the leafs it creates (the way it splits up your map) aren't 100% efficient. A level designer can quite often create better leafs or split existing leafs into two so that the map runs better performance wise. This can be done by using hint brushes.

A hint brush is a brush (rectangular prism/cube) with one side textured with the hint texture, and the other sides I can't remember what they are textured in, probably the nodraw texture The side with the hint texture is the important one, it represents where the cut of an existing leaf is made. A hint brush has to seal off the area, so in a corridor, it must be the height and width of the corridor, touching all sides of the corridor.

To sum up:

1. The map is split up in leafs.
2. Only leafs that can be seen by the engine are rendered.
3. The leaf layout in the map can be improved by the level designer using hint brushes.

"Riven" said:
Remember, Hammer automatically cuts up your level based on every 1024th grid line your map covers

Heh, didn't know that.

---

Aaron's Stuff

If you only want one side of a brush as a HINT, texture all the other sides with the SKIP texture (which will be completely ignored by the compiler, you can also use SKIP brushes to group lots of smaller entities for easier alignment).

To my knowledge, leafs aren't created by vvis but vbsp already, vvis just calculates visibility between them (but that's a minor technicality).

If you have any more doubts about how they are created, this might be the article to end it all: http://qxx.planetquake.gamespy.com/bsp/

My problem is 'on which side do I have to put the HINT texture (and why)' and as there is no corridor what will happen on the sides - will it work?

here see the picture

Kampy said:
My problem is 'on which side do I have to put the HINT texture (and why)' and as there is no corridor what will happen on the sides - will it work?

here see the picture

It could.

Just think of the two areas. Is there any spot within them from which you could see a part of the other? If no, it will work, if yes, it's pretty useless. It should work if the nodraw brush is higher than the hint brushes.

Im now trying to do this with no success yet, but the mat_wireframe 1 function is absolutely brillant. on which side do I have to put the HINT texture?

You apply the hint texture to the side you want it to line up with your cut plane. With a question like that though, it doesn't sound like you comprehended what that optimization article had to say about hint brushes. If I were you, I'd re-read the hint chapter

---

Blog: www.playingarchitecture.net
LinkedIn: Eric Lancon
Twitter:@Riven202

ah I think I finally understood how to use the HINTs (BIG THANKS TO ALL OF YOU! ). Guess I was a bit confused lol. I think I configured it correctly, but theres another reason for it not to work. its so strange like since I put the models in the map it wont update somehow I still cant figure out why

alright! tested it. it works a bit. half of it can be seen somehow. I dont know why. if anyone wants to assist me write me a message