Hammer- Can I learn anything from this part of the compile log?

[Vaya]

 

Does anyone use this part of the log to optimize more? not sure what the percentage after the visible clusters is too?

Audibility...Is this something to watch out for in regards to CSGO level design? 

[DrywallDreams]

I imagine you could use hint brushes to optimize better than VVIS, you're probably best off looking at the portal file in Hammer.

[Vaya]

yeah was hoping for maybe more loose metrics to work with but ah well ?

[clankill3r]

The info doesn't say much without relating it to the actual map.
There could be a map where this info is ok and there could be a map where the same thing is wrong. I think it's much better to walk around in the specific wireframe modes to see what is loaded from what position.

[will2k]

Hammer- Can I learn anything from this part of the compile log?

Yes you can; hope this answered your question 

Joking aside, you can extract useful info from various parts of the compile log including vvis. Should you use this part as your primary guide for optimization - no. Should you use it as a complementary info - yes.

The first number you should be looking at is portalclusters which is simply the number of visleaves in your map. There is no right or wrong in this number and it is relative to the map size and complexity. If your map is small to medium then this number should not go over 1000 as a rule of thumb. Large, complex maps can see this number go to 2000-3000. In this regard, if you have a small, relatively simple map and you see the portalclusters skyrocketing to 4000, you should think immediately of an un-optimized map with regards to visleaves, and the number 1 suspect being the lack of func_detail in the map.

Sometimes a proper optimization system can greatly increase this number; as long as the map is solid on the frame rate side, there is nothing to panic about. I previously worked on a highly complex map where I had to devise a really large and sophisticated optimization system of hints and areaportals. The result was around 3500 portalclusters, however the fps in-game was a solid 220+ across the map which justifies the increase in the visleaves number.

2nd number to look at is portalflow in seconds. vvis shouldn't take long for most maps and should finish in a matter of seconds. In the case of the map I mentioned above, vvis took around 20-25 minutes because of the sheer complexity of the visleaves but as said before, it was totally justified with the fps gains in-game (sometimes you have to sacrifice vvis time for in-game fps gain). If this portalflow is taking too much for a small, simple map, then you guessed it...the map is un-optimized where vvis is spending too much time calculating visibility for additional useless visleaves.

3rd number to look at is average clusters visible which is basically the average PVS of each visleaf in the map. Contrary to total visleaves number which could vary with map size, this number is better kept low to ensure fluid frame rate. In your example log, this number is 135 which signifies that, on average, a visleaf in your map can see 135 adjacent visleaves (the PVS or potentially visible set which the engine has to render all its content when you are standing in the visleaf). You can see that, the higher the number the bigger the PVS; a bigger PVS means that the engine will have to render more content-->more overhead-->decrease in fps. For large maps that are well optimized, this number could go up (I've gotten around 750 in the large map that I previously mentioned) but most maps should be around 300-400 if properly optimized (general guideline from my experience). The primary tool for controlling this number is hint brushes to shape the visleaves as you please for a better visibility control.

To conclude, the compile log is more of an additional guideline rather than your primary tool for optimization (shameless plug: you can check my papers and articles on optimization and optimization testing). Oh, and by the way, the numbers in your compile log are totally fine; no need to worry

Long post, I know ; maybe I should turn and expand it into an optimization article.

Hope this helps

[Vaya]

Thank you for this! Exactly what I was looking for...

Yeah I was planning on using these as rough guides that the optimisation was still heading in the right direction rather than working solely off of them.

[Squad]

...

I was waiting for you to drop by and enlight us all

[clankill3r]

Maybe the video helps:

There is a lot more that can be done. It might be nice to "lock" your map and save the current compile log and only focus on optimizing so you can compare later.
I must say optimizing can be a lot of work...

 

[will2k]

Thank you for this! Exactly what I was looking for...

Yeah I was planning on using these as rough guides that the optimisation was still heading in the right direction rather than working solely off of them.

Anytime mate

If you need any help during the optimization phase of your map, hit me up.

I was waiting for you to drop by and enlight us all