CSGO Map Compiling/Beginner Questions

I use 16 for my initial layouts, and 8 for typical walls that lie within game space. I actually never get into anything lower unless I'm doing detail.

I wouldn't worry too much about texture snapping atm. I "zero" mine out all the time which is "0.25" This is standard for hl2. Now since csgo's "HR" for de_train; the default is "0.125"

Use dev textures to get scales correct.

@laminutederire I don't think you understood my problem? vis is compiling too fast, not too slow. It's suspiciously fast and ingame it seems like it did 'a bad job'. I didn't change much about the map at all. Don't want to sound too aggressive, it sounds like you misunderstood my issue tho!

@FireWarp I haven't changed my skybox at all unfortunately. I've even gone ahead and changed it now (brought the ceiling down as far as possible) just to see and it doens't change anything.

So right now I optimized my map to have pretty much exactly 3k portals and vis takes a blazing 4 minutes only. Way too fast surely? On full settings with the slowest preset in Expert mode? No errors in the compile log (should I post that, would anybody look at it?) and map is optimized with func_details and nodraw but no hints/skips yet.

If anybody has any additional ideas or anything please let me know. This is kinda ruining my map when it used to be just fine optimization-wise, very frustrating because, again, I didn't really change much except add some func_details.

In general, your walls should be 128 units high but that's a 'baseline' if you will. When actually greyboxing I wouldn't obsess over that kinda stuff too much. Put the brushes down the way they feel right, then adjust later for the texture that you choose. That's the way I do it anyways.

Quote from Michael Greenwood

Sorry, I dont understand what "zeroing" a texture means. I get that textures at 0.25 make a 512x512 texture apply to a 128x128unit area, but what does that mean for my map making? Areas should be built with 128x128 blocks?

If you type "0" in to the scale it autos to .25. Just quicker than typing it out

Quote from NihiL

@laminutederire I don't think you understood my problem? vis is compiling too fast, not too slow. It's suspiciously fast and ingame it seems like it did 'a bad job'. I didn't change much about the map at all. Don't want to sound too aggressive, it sounds like you misunderstood my issue tho!

I understood, I said that because sometimes a non-optimal optimization make the compiler to be weird and it leads to compiling too fast because it overlooks things, which it thinks they are too complicated, and optimizing can help him figure it out and it can deal with it

That's too bad :(. My only guess would be that hammer is somehow overwriting your custom compilation parameters. To check if that's true, compile vis on fast and compare it with normal settings. What fast compile does is that it actually checks whether or not the visleafs created by vbsp are correct and that's pretty much iit. Whilst on normal setting vvis performs portal flow correctly, making source cull parts of your map during gameplay. All of this means that fast vvis does pretty much NOTHING. Compiling without vvis shouldn't make any difference

Quote from laminutederire

I understood, I said that because sometimes a non-optimal optimization make the compiler to be weird and it leads to compiling too fast because it overlooks things, which it thinks they are too complicated, and optimizing can help him figure it out and it can deal with it

Quote from FireWarp

That's too bad :(. My only guess would be that hammer is somehow overwriting your custom compilation parameters. To check if that's true, compile vis on fast and compare it with normal settings. What fast compile does is that it actually checks whether or not the visleafs created by vbsp are correct and that's pretty much iit. Whilst on normal setting vvis performs portal flow correctly, making source cull parts of your map during gameplay. All of this means that fast vvis does pretty much NOTHING. Compiling without vvis shouldn't make any difference

Thanks for the answers! @laminutederire: okay and with optimization you mean hint/skip brushes at this point, right? Because everything else that I'm aware of (nodraw and func_details) I've already done to the map, as I said. @FireWarp: Nah, fast vvis actually is done within less than a second for my map so it's not like Hammer is doing an actual fast vvis when it should do a full vvis. It's somehow not doing the full vvis right apparently...

NihiL yes hints are a good start, have you checked out Skybex vmf's? They are helpful to know where to place hints. I hope this will help. At least when I had this trouble it was because portals were overlooked because the compiler didn't understand what was going on there, so... finger crossed, hope it helps you

Quote from NihiL

[Blocked Image: http://i.imgur.com/8CzzizN.png]

That's an example of a flickering decal. Any further ideas?

@laminutederire: I'm aware of how important optimization is, I was asking my question because I used to get good in-game performance with VIS that took long, as expected, and now for no apparent reason it goes by much quicker during compilation (like 10x faster but not instant like actual FAST VIS) and I get way worse in-game performance (ie. FPS). And that's what puzzles me as I didn't do much except add a couple more func_details.

You can make an overlay stop flicking in Hammer by adding $decal 1 to it's .vmf. Lot's of valve decals do not have this parameter in them, but reasons not known to me. If you want to make a Valve decal stop flicking, you could copy and paste the decal's .vmf from the vpk, adding $decal 1. See the valve developer community wiki for more.

Quote from NihiL

@laminutederire I don't think you understood my problem? vis is compiling too fast, not too slow. It's suspiciously fast and ingame it seems like it did 'a bad job'. I didn't change much about the map at all. Don't want to sound too aggressive, it sounds like you misunderstood my issue tho!

You can test to see which parts of your map are being rendered in-game, and thus check to see if vbsp and vvis are doing their jobs properly. With the map loaded, kick bots (in console type bot_kick, then press enter), set infinite warmup (mp_warmup_pausetimer 1) or long warmup (mp_warmuptime A BIG NUMBER), then type mat_leafvis 3, show the potentially visible set (PVS) from your location. Each of these blue rectangles represents a visleaf in your map. As you move around the map, you should notice that the visleafs which are being rendered (ie, the blue rectangles you can see) change. If there are blue rectangles being rendered on the other side of the map, then you've either not run vvis properly, or not optimised properly.

My go-to compile parameters for vvis (or $vis_exe) are "-game $gamedir $path\$file". You should check to see if there is anything wrong in your Run Map [Advanced] window. You should also make sure that the checkbox is ticked next to the $vis_exe entry on the left of the window.

Optimising a source map is worth far more than a comment on a forum. There is so, so much you could do. This article is in my opinion, fantastic, and should come bundled with the SDK, and I half think users should be forced to read it before giving them access to Hammer. But, if you're still in early stages, you probably don't need HINT or SKIP brushes, especially if you don't have many props out.

Without seeing the map (and thus taking this with a grain of salt), I'm going to say that you haven't made enough of your world brushes into func_detail. A very large number of the brushes in your map should be made into func_detail.

• Stairs? Func_detail, all of it.
• A wall with a window you can see through? Make the window AND the wall func_detail.
• Plywood leaning against the wall? Func_detail.
• Brushwork window or doorframe you made? Func_detail.
• The piece of brushwork glass you put in the window model? Func_detail.
• Mirage->Palace style pillars? Func_detail.
• Anything made of brushwork which isn't a solid wall, floor or ceiling? Func_detail.

Basically, if you look at a map, and see something which isn't a model, and you think it's world geometry:

[Blocked Image: http://i.imgur.com/8bkxFVr.png]

Quote from NihiL

So right now I optimized my map to have pretty much exactly 3k portals and vis takes a blazing 4 minutes only. Way too fast surely? On full settings with the slowest preset in Expert mode? No errors in the compile log (should I post that, would anybody look at it?) and map is optimized with func_details and nodraw but no hints/skips yet.

Personally, I think it's INSANITY that your vvis compile takes 4 minutes, and that you think that's blazing.

• de_typhoon takes 1 minute 57 seconds to do vvis. This was for the release version, in a map with a large number of inset windows, doors, and an open skybox. I am unhappy with this compiile time.
• ar_skate takes 0 seconds, according to the compile log. After Typhoon, I learnt the importance of func_detail. Almost the entire map is func_detail.
• de_neutron takes 9 seconds, sometimes 8 if I don't have other programs open. de_neutron is a full defuse map, with some indoor and some outdoor areas.

Despite what I've just typed out, I'm not trying to say what is wrong and what is right for compile time. It may be that you have a worse processor than me. But if my vvis compile time was anywhere near 4 minutes, I'd be shitting bricks.

Func_detail is hugely important for optimisation. World geometry (ie, brushes which aren't made into entities) 'cut' the world with the help of vbsp, into 3D polygons, or visleaves. Vvis then checks every pair of visleaves, and checks which visleaves can see each other. Every time you add a visleaf to the set, vvis must now compare that visleaf with EVERY other existing visleaf.

Let's say I have a stupidly simple map made of brushwork, and vbps decides that I only have 5 visleaves.

[Blocked Image: http://i.imgur.com/3iC7Jtq.png]

Vvis will calculate whether each visleaf can see each other visleaf as follows:

• CAN 1 SEE 2 YES
• CAN 1 SEE 3 YES
• CAN 1 SEE 4 NO
• CAN 1 SEE 5 NO
• CAN 2 SEE 3 YES
• CAN 2 SEE 4 YES
• CAN 2 SEE 5 YES
• CAN 3 SEE 4 YES
• CAN 3 SEE 5 YES
• CAN 4 SEE 5 NO

It performs 10 calculations total. Now, let's imagine I build another wall, as follows.

[Blocked Image: http://i.imgur.com/CfQhWkQ.png]

There are now 6 visleaves. So now, vvis comes along and does it's thing. IN ADDITION TO THE 10 CALCULATIONS ABOVE, it must also calculate visiblity for the 6th visleaf, so

• CAN 1 SEE 6 NO
• CAN 2 SEE 6 NO
• CAN 3 SEE 6 NO
• CAN 4 SEE 6 NO
• CAN 5 SEE 6 YES

So, vvis has now made 15 calculations total, up from 10, by simpling adding one more visleaf. Note that we made 5 more calculations; the same number of visleafs we started with. So, if you have x number of visleafs, making y number of visibility calculations (where y is usually much greater than x), having x+1 visleaves will mean you need to do x+y calculations.

Given this, it should be clear that to save CPU cycles, .bsp file size, and time, you want to reduce the number of visleaves wherever possible. As an example, I'll show you the effect that simple stairs have on the number of visleaves in a map. Shown below is one way of doing stairs as func_detail in a greybox map I am working on. To show the visleafs in Hammer, go to Map > Load Portal File > Yes.

[Blocked Image: http://i.imgur.com/lOFqQNN.png]

Here, I've made the stairs func_detail. The blue lines show where vbsp has cut the world. You can see that the walls, the balcony and the landing of the stairs are cutting the world, but the stairs are not. Here are the brushes I've assigned to be func_detail, to make it clearer.

[Blocked Image: http://i.imgur.com/iCmvL4n.png]

Now, I've done the unimaginable, and I've moved these brushes back to the world with ctrl+w. The result is this:

[Blocked Image: http://i.imgur.com/il5W6IM.png]

As you can see, I've added an almost uncountable number of visleaves to the set, which is going to geometrically increase my vvis compile time. In short: func_detail everything little, and everything you can easily see around. Do not func_detail walls which you don't want to render the other side of.

Wow, this turned into a massive post. Sorry about that. If there are any mistakes, let me know and I'll edit this comment appropriately.

Thanks @Single for typing that out. I wasn't aware of that decal material property, good to know what the cause of this is!

About the vvis issue: thanks for making such a long post! I was unfortunately already aware of the way bsp/vis works and how func_details are used haha so that was, while very nicely written and hopefully helpful to others, not exactly news to me I have already func_detailed absolutely everything that isn't 'big' and blocks line of sight, every stair, arch, small trim/outline brush etc.

So let's stop talking about the compile time then, as you say correctly, it's CPU-dependant, I'm on an i5-4690k and 3k numportals take me 3 min as I said, but that's alright I guess. I just thought that vvis was supposed to take longer, talking about a full large defusal map that's fully detailed and 'done' here.

I did run around my level with mat_wireframe 1 after watching the tophatwaffle guide to map optimization and noticed that there are a lot of areas where vvis failed completely and the ENTIRE map is being rendered. Example:

[Blocked Image: http://i.imgur.com/EZsyNki.jpg]

There's LOTS of issues in other places of the map where vvis got it completely wrong - and yes, those houses left and right are world brushes. I don't know why I can see through all these world brushes according to vvis. So either I find a way to get vvis to work correctly again or I use one hell of a lot of hint brushes to make sure it's all cut up correctly... Sigh!

Thanks again for your very detailed answer, Single!

@NihiL displacements don't block vis either, and consequently need to be supported by something like a nodraw brush underneath them. This could be the root of your problem where the visleaf you are in can see other visleaves under the ground.

If it was an issue of height you would probably have this more over your map, but seeing as you are standing in a depression made of a displacement it's worth looking at if you haven't already.

Loading the portal file into hammer is really useful for debugging this sort of thing as you can visualise which leaves are attached to what. It's a bit manual, but it's helped me in the past. There's also a cvar you can use in game, but it escapes me currently. I think it's r_showpvs with values 1-3 or along those lines.

r_lockpvs as Squad mentions below.

Quote from jackophant

There's also a cvar you can use in game, but it escapes me currently. I think it's r_showpvs with values 1-3 or along those lines.

It's r_lockpvs. Really helpful command. It locks the PVS (aka what the engine is rendering from your current position), so you can noclip around the map and get a better understanding of what exactly is rendered from that position. Trying to figure that out with just mat_wireframe can be quite challenging when your map is getting more detailed.

Quote from Single

[Blocked Image: http://i.imgur.com/lOFqQNN.png]

Here, I've made the stairs func_detail. The blue lines show where vbsp has cut the world. You can see that the walls, the balcony and the landing of the stairs are cutting the world, but the stairs are not. Here are the brushes I've assigned to be func_detail, to make it clearer.

Just wondering why you didn't func_detail the actual balcony and the solids underneath the stairs. If it was just to show where the brushes are cutting the world, then that is fine off course, but I think it should be made clear that ideally they should be func_detailed as well

That being said, nice post overall!

@jackophant I have a 'swimming pool' or skeleton of nodraws under my displacements already unfortunately! Nice thinking, though!

r_lockpvs sounds great, I will try and see what's happening exactly!

Thanks guys, it looks like my only way out at the moment is using hint/skip...

Quote from 3Dnj

You have to put VVIS on fast for a better optimization. When it's on fast, the partals are drawn but there is no visibility calculation between them. If you want to reduce the VVIS compilation time, you need to reduce the number of portal. 3500 seems a bit too many to me.

For the decals, are you sure you are using decal ? this happen when you use textrure that are not made to be a decal.

Someone retake this to me because I made a huge mistake, probably because I was tired or something. At the end you HAVE to use vvis on full for a better opti because in fast visibility calculation is not at it's best.

But use FAST to test your leaves as in fast and full, leaf building is the same quality as far as I know.