Jump to content
will2k

de_nuke - A revised optimization system

Recommended Posts

could you by any chance add de_nuke_will2k map to the post? 

My current map has a lot of open areas like in nuke and I'm not sure how to optimize it. It would be helpful to see how it's done as well as you do! :)

Share this post


Link to post
Share on other sites

Nice test! Though i don't really know why you did run vvis on fast for testing the quality of optimization. This doesn't really make sense imho. I feel like you should compile with other compile settings for more accurate results despite of the long compile times.

Hey buddy

What you suggest will be unneeded, useless, and a total waste of time; too much confusion in the comments posted in this thread, and these are common misconceptions that will probably need me to write an article by itself.

I’m going to let you in on a little secret (and the viewers too); let’s call it “optimization 601 – masters degree level class” ;)

If your map is tightly and well optimized (and I mean REALLY, REALLY well), then there is not much of a difference between full vis and fast vis. The gap in fps will be non-existing at all, you will get the same fps. If by any chance the fps will differ, then this difference will be extremely marginal.

That’s not to say that everyone should use fast vis; If you are a beginner or intermediate level in Source optimization, then never use fast vis because chances are your map in not fully optimized and the fps will take a dip with fast vis (the PVS and the content rendered will be exaggerated).

However, if you are an expert in optimization and very intimate with visleaves and PVS, then fast vis is as good as full vis when it comes to testing your optimization system. Please check my 2 detailed and in-depth articles on (visleaves) Demystifying Source Engine Visleaves and (PVS) Source Engine PVS - A Closer Look

The PVS in the fast vis version will be slightly looser than the one in the full vis edition and I emphasize on slightly; we are talking here about some 4-5 additional visleaves at best, and when you took extra care to optimize your map and kept your visleaves in check, then these extra visleaves in the PVS won’t affect your fps in any considerable way. Most of the times, the fps will be the exact same between fast and full or slightly lower in some rare cases (single digit difference at best).

I personally do not need vvis while building my optimization systems. Vbsp creating the visleaves properly is more than enough; I can calculate the visibility myself and predict the PVS on the fly by using mat_leafvis, mat_wireframe and r_lockpvs, in addition to the portal file in Hammer. A full vis or fast vis will be the same for me once my optimization system is airtight.

Now if this new found knowledge shook the optimization grounds beneath your feet :), then allow me to ease your mind with some solid screenshots and figures to showcase and verify what I just explained.

I will use my CSGO map cs_calm to demonstrate this effect, and we will need 3 versions of it: the workshop version (March 2015) that is basically a final compile (full vis, full rad), a test version compiled with fast vis and fast rad, and a second test version compiled with fast vis but with full, final rad. These versions are exactly identical, the only difference being the compile parameters.

sd67a73cemxsd49zg.jpg

In this first screenshot, on the left is the full compile version while on the right is the fast compile. The fps are the same in both versions.

Let’s check the wireframe shot to get an idea on the PVS and what’s being rendered.

etlmjcb5915vpi5zg.jpg

You can see that the content rendered is the same. The only small difference in the PVS is the area behind the ladder (center of screenshot) where an additional 5 small visleaves are rendered in the fast version. Since my map is fully optimized and these additional visleaves have proper “hallway-end” areaportals, corner hints, no draw, as well as an aggressive props fade distance, the content to be rendered inside them is greatly reduced to just a couple of textured walls that have no impact on the fps.

Here is another screenshot between the full version and the second test map with fast vis but this time with full, final rad.

ilrlpilrrpt59mtzg.jpg

Again, the fps is the same (no surprise here if you understood the concept). The wireframe shot follows.


5z0ao7fwj401191zg.jpg

Again the PVS and content rendered is basically the same with the additional 5 visleaves for the fast vis; the fps is still the same.

As I said before, when your map is tightly optimized (as in “will2k’s seal of approval” optimization :D), then it doesn’t matter between full or fast vis, you will get pretty much the same fps results and can compare freely. If your map is not 100% optimized, then DO NOT use fast vis at all.

My study on Nuke is 100% valid even if I did it with fast vis; now you can see why.

Hope the above cleared things up for you and for people viewing this thread :)

I might be tempted to write an new article about the above.

Cheers

Note: For all the folks that are confused and have so many misconceptions about vvis, optimization, etc, please read my technical papers and articles about Source optimization in chronological order as they appear in my signature below.

(For the guys confused about hints and fast vis in the posts above, vvis has nothing to do with implementing your optimization setup, that's vbsp's job - vvis simply calculates the visibility between your leaves and creates the PVS. vbsp is the one responsible for translating your hints, areaportals, nodraw, func_detail etc into visleaves cuts during the compile). Again, read my papers and all this is explained in great details :).

 

 

 

Share this post


Link to post
Share on other sites

That was a way longer answer than i expected! Thank for explaining! I always thought vvis on fast is so bad, that it's almost like not even calculating the visibility at all. I definitely need to learn more about Source optimization. Gonna read your papers next week! :) 

Share this post


Link to post
Share on other sites

 

Note: For all the folks that are confused and have so many misconceptions about vvis, optimization, etc, please read my technical papers and articles about Source optimization in chronological order as they appear in my signature below.

(For the guys confused about hints and fast vis in the posts above, vvis has nothing to do with implementing your optimization setup, that's vbsp's job - vvis simply calculates the visibility between your leaves and creates the PVS. vbsp is the one responsible for translating your hints, areaportals, nodraw, func_detail etc into visleaves cuts during the compile). Again, read my papers and all this is explained in great details :).

I'm not sure how it's possible that I have missed your papers! I have been searching for something to read about source level designing. These are great! thanks!

Share this post


Link to post
Share on other sites

That was a way longer answer than i expected! Thank for explaining! I always thought vvis on fast is so bad, that it's almost like not even calculating the visibility at all. I definitely need to learn more about Source optimization. Gonna read your papers next week! :) 

A good question requires a good and long explanation answer :D

I'm not sure how it's possible that I have missed your papers! I have been searching for something to read about source level designing. These are great! thanks!

Thanks :)

The 10 papers that are in my signature are related to Source optimization; on my website, you'll find more than 20 papers/articles related to different aspects of level design/gaming in general that I have been writing since March 2012.

Share this post


Link to post
Share on other sites

I published my latest article titled Source FPS Cost of Cheap and Expensive Assets.

It should shed some more light on the effect of expensive assets on Source optimization and highlight the effect on frame rate drop that was evident in the new de_nuke (high amount of expensive props/textures in the playable area).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...