how should i optimize my map?

Optimizing your map will not speed up compile, only FPS in game. Your compile time naturally goes up as you add more brushes and entities.

You can self-test your map faster by setting some of the compile settings to fast.

If they aren't familiar with how func_detail works, it will drastically speed up their compile times.

Read this. Absorb it. Read it again.

VRAD takes up the most time if you're doing things right, so just setting that to fast (everything else should be set normally) should speed it up a decent amount but give you crappier lighting — non-antialiased edges on shadows, that sort of thing. If your map is still in early alpha and pretty much just a layout with a bunch of floating invisible lights, it won't really hurt anything to compile it that way. Just be aware that eventually, you'll have to put up with longer compile times.

well, i haven't gotten to the 'end-game optimization' yet (hint brushes, areaportals, occluders, etc). i'm not yet doing 'proper' compiles yet (still busy making the actual layout).

but while mapping the actual world, should i just give every face that never gets seen in-game the Nodraw texture? or will that not necessarily help performance or compile-times?
(edit: i guess i already found my answer on Nodraw on the site Crash linked)
or could Skip be better for performance?

also, do/can toolsbrushes lower FPS in-game..?
because i noticed that plenty of (invisible) toolbrushes actually cut visleaves, which made me think that there will be calculation going on while they're being rendered?

sorry for the questions, quite new to mapping : (
i'm just trying to do it right from the start, so that i won't run into nasty-long compile times later on, or otherwise crappy performance in-game..
(edit: as optimization.interlopers.net states: "preventing is easier than fixing up later")

Bucake said:

well, i haven't gotten to the 'end-game optimization' yet (hint brushes, areaportals, occluders, etc). i'm not yet doing 'proper' compiles yet (still busy making the actual layout).

but while mapping the actual world, should i just give every face that never gets seen in-game the Nodraw texture? or will that not necessarily help performance or compile-times?
(edit: i guess i already found my answer on Nodraw on the site Crash linked)
or could Skip be better for performance?

also, do/can toolsbrushes lower FPS in-game..?
because i noticed that plenty of (invisible) toolbrushes actually cut visleaves, which made me think that there will be calculation going on while they're being rendered?

sorry for the questions, quite new to mapping : (
i'm just trying to do it right from the start, so that i won't run into nasty-long compile times later on, or otherwise crappy performance in-game..
(edit: as optimization.interlopers.net states: "preventing is easier than fixing up later")

Click to expand...

Keep using nodraw, skip should only be used in combiation with hint or nothing else.

And why are you using invisible texture? if you want to stop player to enter a certain area, use the player clip texture, so grenades and rockets can still fly through it. Player clip also won't cut visleaves

https://developer.valvesoftware.com/wiki/Tool_textures

that link contains a fairly detailed table of all the tool textures in source sdk, including basic usage guides and the materials properties when assigned to a world brush, including whether they cut vis leaves etc.

Hope that helps a bit

it sounds weird at first, but when mapping try and divide your map up into little chunks (or as Frozen describes, little slices of a cake).

You only want your players to be able to see certain chunks at a time, else your whole map is gonna have terrible FPS.

This is the biggest optimization issue with my map Tanker, it's a very wide open map which I didn't consider initially. Frozen suggested I think about it but I kind of dismissed his suggestion assuming things would be fine.

Now it's in beta, the compile takes 20+ minutes because of how open the map is. It has great optimization (maybe not the best), but the open-ness meant that it was very hard for me to divide the map up into pieces and even harder for me to optimize my resulting compile time.

tl;dr? Optimize early, make your map out of little sections instead of one huge area.

ps: fast compile times are more a convenience on your (the developer) part, but player experience (performance) is more often than not more important. I guess the "unless" part here is if your vvis is taking well over an hour in which case very closely study how to optimize your vis compile times. Try to stay away from func_viscluster unless it's absolutely necessary. If you don't know what you're doing with visclusters it's very easy to actually ruin your map's vis.

Also, overoptimizing with func_detail might result in worse performance. A huge outdoor area can become 4 leafs instead of 20, but each leaf just became 5x heavier. With alot in it that can actualy make it less good.

A trick to use when you get large areas is to seal them off with areaportals. They can drasticly improve the way the large area gets rendered and they can ignore the 'its 1 big leaf' part'. They cost a little more than just normal visleafs. but with large outdoor areas in many cases the extra cost get countered by having to render than 50% of what otherwise would be rendered. As it only renders the area you can see between the portal.
(its also used for windows inside spawnrooms that can watch into the map like for example stage 1 on thundermountain at the red spawn, or stage 3 on pipeline. there they effectively only allow rendering through 1 side of the portal unless very close)