Jump to content

Source FPS Cost of Cheap and Expensive Assets


will2k

cheapexpensive_web.jpg

A new question?

After successfully solving the eternal mystery of func_detail vs. displacement in my last article (here), I was contacted by the High Council of Source Engine Optimization. Apparently, there seems to be another enigma to be uncovered and a major question to be answered.

What is the fps cost of cheap and expensive assets in Source engine? Is there a significant difference between the two in terms of frame rate? (that’s 2 questions but I’ll let this one slide)

The study

As with the last article, this one is also going to be a short but sweet article; fewer words, more numbers and screenshots. The systematic approach is also going to be very similar: 2 similar test maps where one contains expensive assets while the other has cheap versions of these assets. The assets will be the same and will be located in the same locations in both test maps.

The recent assets added with the new de_nuke update in CSGO will be the perfect candidates for our study as Valve made most of these in cheap and expensive versions. For props, the expensive version is high-poly models while the cheap one is low-poly. For textures, the expensive version gets a normal map (up to 2), specular map, advanced reflections, detail map, and Phong shading in some cases; the cheap version is basically the diffuse map with the occasional detail map.

I will record the localized fps in both versions and compare, then draw conclusions that will hopefully answer the High Council’s question(s).

The testbeds

The first map to test is the one made of cheap assets. It’s basically a simple map consisting of 4 walls and a floor on which are spread several props and textured blocks at predetermined locations. Textures are mostly concrete while props contain crates, cars, pipes, wires, doors, and vents.

test_cheap.jpg

The fps recorded is 330 fps. The expensive version is exactly the same but with props replaced with their high poly versions and textures swapped with their expensive versions.

test_expensive.jpg

The fps is now 286 fps; interesting. All right, let me call the High Council to relay the news.

Hold your horses right there. We are men of Science and you know that…yes, yes, I know, one map is not enough to draw conclusions.

I’m going to take this map and quadruple it, in area and in content, and test again (Nobel prize here I come). The new map will have 4 times the amount of props and textured brushes (the same ones of the initial map cloned into the new areas) as well as having its total area increased fourfold. We start with the cheap version that we will refer to as test map (4x).

test_cheap4.jpg

The fps decreased to 279 (from the 330 in the simple cheap map) due to the extra content that the engine has to render. Our main point of concern would still be to compare this version against the expensive one.
You know the drill by now; we will also create the (4x) expensive version.

test_expensive4.jpg

The fps is 229. The decrease in (4x) version is more or less in line with the one in the simple version. Let’s recap in a table for easier viewing.

test_assets_fps.jpg

As you can see, the fps dropped 44 fps in the simple version and 50 fps in the 4x version, between the cheap and expensive maps respectively.

We can draw 2 conclusions from the above table:

There is a significant drop between the cheap and expensive version (44/50fps), and there is also a substantial drop within the same version (51/57fps) when you add much more content that is all visible in the PVS.

These results can shed some light on the latest update of de_nuke where the overall fps is lower than the rest of the stock maps in CSGO. The high amount of props/details that can be seen/rendered from one location coupled with the expensive assets in the playable area contribute to further decrease in the overall fps in that map (in addition to the open skybox/layout). I have tackled a revised optimization system for de_nuke in a topic of mine last month that can be read here (https://www.mapcore.org/topic/19909-de_nuke-a-revised-optimization-system/)

As a bonus, I’ll throw in the compile times of the above maps so you can witness the effect of cheap vs. expensive, and the additional content in (4x) versions, on the compile time, especially on vrad since it will mostly be affected by the extra faces in the high poly models and the additional vmt switches in the expensive materials.

test_assets_compile.jpg

You can clearly see that vrad times increased considerably between the cheap and the expensive versions, as well as within the same version when we quadrupled the area/content.

Now if you’ll excuse me, I still have a phone call to make; the grand council woman cannot wait any longer.

The final cost

Expensive assets bring visual eye candy to the map in hand which is a necessity in today’s ever-growing and continuously pushed graphics boundaries. Relying on low poly models and cheap textures won’t fare well on the visual fidelity front. However, expensive assets come at a cost of taxing the rendering engine and decreasing the overall fps in the map.

These expensive assets are a requisite if you want your map to shine (pun intended) but one has to be careful not to overuse them. Use them wisely in the playable area and resort to cheap versions when decorating the non-playable areas of the map or any place that the player cannot see up close to discern the difference.

 


  Report Article


User Feedback

Recommended Comments

Nice article! It would be great if you could profile and investigate how frame renders with a certain assets so you could actually tell that this model is X poly, has a pretty heavy material that has screen space reflection and performance depends on the object size on screen, material drawcalls, if it's grabbing heavy textures etc. Microsoft have PIX tool, I bet there's one for PC too. There was a Crytek profiling tool but I can't find it :( That data would be suuuper useful.

Share this comment


Link to comment
Share on other sites
14 hours ago, Shibou said:

Again a very use- and helpful article. Thank you.

Thank you :). Glad you liked these articles and found them helpful.

13 hours ago, seir said:

Nice article! It would be great if you could profile and investigate how frame renders with a certain assets so you could actually tell that this model is X poly, has a pretty heavy material that has screen space reflection and performance depends on the object size on screen, material drawcalls, if it's grabbing heavy textures etc. Microsoft have PIX tool, I bet there's one for PC too. There was a Crytek profiling tool but I can't find it :( That data would be suuuper useful.

Thanks seir :)

The points you mentioned are a bit advanced and could be the topic of a future article that goes further deep in the study; bear in mind I'm no programmer but it will be interesting and useful as you mentioned. Will keep this in mind for future articles that I plan to write :)

As for PIX, AFAIK it is now deprecated and it is currently part of the windows SDK, more precisely the Microsoft Visual Studio called Visual Studio Graphics Debugger. I will see if there are other alternatives for the PC as you mentioned the Crytek one, so there's bound to be others :)

Thanks again for the insights.

3 hours ago, Vaya said:

Great work as always :D

Thanks for the uplifting comment and the continuous support :D

Share this comment


Link to comment
Share on other sites

Thanks for writting this article, i believe it's an interesting subject and what you did clearly shows that more detailed models do clearly impact performances.

But i'm also a bit disappointed, you could have pushed this a lot further. There are only 2 sets of data with only 2 points for each one, which is really not enough in my opinion. For example, it just can't answer in what way the performances are decreasing with the polycount increasing. And it would have been much more interesting to see the results on a graphic instead of showing a delta, something like this for example :

Sans titre.png

You could have made a sort of "test sample" model, that you could have compiled in 10 versions for example (from 500 to 50 000 tris for example, i'm not even sure you can compile that, but you get the idea!). And you can then make 11 tests and get 11 points : without the model and with 1 version of the model every single time.

Then you could have used that model many times, and see if there is some instancing that makes the use of the same model many times cheaper in the same rendering.

Everytime you can note the polycount in each renderings and get much more results. You could also have combined them, for example imagine if you can make a conclusion like this (which is just an example, it's totally wrong) :

Quote

In any rendering on CSGO, you can have in the same time a maximum of :

  • ~10 "star models", using 8 000 to 10 000 triangles
  • ~100 normal models, using 800 - 1000 triangles
  • ~1000 cheap models, using less than 400 triangles

And you'll meet Valve's standards in terms of framerate on your map at any time

Ok that would be hard to trust, because lots of other stuff could skew results (depending of what shaders you used for example, as you said in your article), but that would be extremely useful for Artists and Level Designers !

 

It's just an idea, maybe it's not reliable but that would be nice.

Share this comment


Link to comment
Share on other sites

Thanks everyone for the comments and the active discussion

@Pampers: Source should be already relegated to the "classics" category instead of still being in the "active engines" category; it's long overdue in 2016 :)

I'm no modeler or 3D artist, but out of curiosity, doesn't source use LOD? or did you mean it's an inefficient system in Source?

@ laminutederire: I'll list some of the props used in the test maps along with their triangle count to give you an idea (both high and low poly versions)

  • nuke_sedan02        4608
  • nuke_sedan02_low    1990

 

  • nuke_roof_ac02        1712
  • nuke_roof_ac02_low    621

 

  • metal_crate_001_128x112x256        5555
  • metal_crate_001_128x112x256_low        2623

 

  • metal_door_002        1032
  • metal_door_002_low    582

 

  • metal_pipe_001d_corner_large        832
  • metal_pipe_001d_corner_large_low    224

@ leplubodeslapin : Salut Sylvain. There will always be room for in-depth follow-up articles ;)

The main purpose of this short article was to showcase that there is a significant effect on fps when "over-using" expensive assets especially after the new de_nuke update.

 

Share this comment


Link to comment
Share on other sites
2 hours ago, will2k said:

doesn't source use LOD? or did you mean it's an inefficient system in Source?

It did, but it doesn't work on CSGO anymore (maybe because of gameplay balance issues, dunno)

 

2 hours ago, will2k said:

@ leplubodeslapin : Salut Sylvain. There will always be room for in-depth follow-up articles ;)

The main purpose of this short article was to showcase that there is a significant effect on fps when "over-using" expensive assets especially after the new de_nuke update.

Okay then it's doing its job :) it was still interesting to read

Share this comment


Link to comment
Share on other sites
4 hours ago, leplubodeslapin said:

It did, but it doesn't work on CSGO anymore (maybe because of gameplay balance issues, dunno)

Thanks for the info :)

I don't think a prop transition from high to low poly in-game would make such a big difference on gameplay (overall shape, color, size, collisions...are basically the same). Maybe it was something to do with the new modified engine in CSGO? or they got lazy and didn't implement it back in the new Source :D.

As Pampers mentioned, having LOD would help a lot with frame rate especially on the new de_nuke. One could set a prop to fall back to low poly at 512-1024 units from player depending on size then implement props fade distance at 1600 units (just an example) for the ultimate fps saver.

Share this comment


Link to comment
Share on other sites

Yeah, unfortunately LOD's don't work anymore in csgo. I asked Magnar a while ago about this, but I don't think I got a reply back on that.

Jumping off what Felipe said, MS frame time is a much more realistic measurement of performance in the scene, because it tends to scale much more linearly with various hardware versus straight up counting your current framerate. MS time also gives you a much more realistic representation of what is eating the most fps, or frame time overall. This is why fps is a bit misleading, you can still have a high fps but totally have something that's eating a ton of frame-time, that while doesn't really show on your hardware, is going to tank someone on lower end hardware.

Share this comment


Link to comment
Share on other sites


Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×