leplubodeslapin reacted to Sjonsson in Optimizing An Open Map in Source Engine
Today I have read this article, Man Vs. Engine and the other writings of yours referred in this article and I have to tell you it's nothing but fantastic piece(s) of work, both cohesive and inclusive. Whenever I see guys like you giving away so much to a community, no matter if it resides at GameBanana, Mapcore or somewhere else, I get this happy feeling and inspiration to do the same some day.
I'd like you to know that next week I will start up an 8 weeks long HL2 campaign project with my level design class consisting of 14 students and a lot of your work will be mandatory reads.
Thank you so much for this, helps out immensely!
leplubodeslapin reacted to will2k in Source FPS Cost of Cheap and Expensive Assets
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.
leplubodeslapin got a reaction from Thrik in Source FPS Cost of Cheap and Expensive Assets
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 :
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) :
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.