Draw calls in source?

[grapen]

Imagine a scene where you have two separate models, each with their own 1k material. Now let's add another model that utilizes both of these materials. Is this favorable over creating a new 1k material for the third model in terms of performance?

Edited February 24, 2017 by grapen

[WD]

There's a whole lot of different console commands for engine telemetry, why not try testing that?

https://developer.valvesoftware.com/wiki/Showbudgethttps://developer.valvesoftware.com/wiki/Showbudget

You'd only save memory for using the same texture.

You're only going to hit the draw call bottle neck when rendering somewhere around over 3k static meshes simultaneously ( and by then its only ever so slightly affecting fps ). It is almost impossible to hit that number in a CSGO like corridor shooter if you consider all the good design practices. So if you'd have that many static meshes would it be better if they'd share some of the textures to save memory? I think so.

 

In the case of just three models it doesn't really matter unless you want to save hdd space.

Edited February 24, 2017 by WD

[grapen]

21 minutes ago, WD said:

There's a whole lot of different console commands for engine telemetry, why not try testing that?

https://developer.valvesoftware.com/wiki/Showbudgethttps://developer.valvesoftware.com/wiki/Showbudget

You'd only save memory for using the same texture.

You're only going to hit the draw call bottle neck when rendering somewhere around over 3k static meshes simultaneously ( and by then its only ever so slightly affecting fps ). It is almost impossible to hit that number in a CSGO like corridor shooter if you consider all the good design practices. So if you'd have that many static meshes would it be better if they'd share some of the textures to save memory? I think so.

 

In the case of just three models it doesn't really matter unless you want to save hdd space.

Excellent link, didn't know this existed. Have some testing to do =)

I ask because of what Cliffe had to say about this picture:

 

"The reason you're seeing those models render is because models of similarity (that share textures) were combined in order to reduce draw calls. We measured the peformance of the map before and after this optimization and it resulted in a 40% average framerate boost. While looking at this it may seem counter intuitive but currently in the engine the number of entities is of far greater importance than the number of polygons you're rendering"

I just found this very interesting and would like to know more about best practices in Source, theoretically.

Edited February 24, 2017 by grapen

[DrywallDreams]

On 2/24/2017 at 9:49 AM, grapen said:

Excellent link, didn't know this existed. Have some testing to do =)

I ask because of what Cliffe had to say about this picture:

 

"The reason you're seeing those models render is because models of similarity (that share textures) were combined in order to reduce draw calls. We measured the peformance of the map before and after this optimization and it resulted in a 40% average framerate boost. While looking at this it may seem counter intuitive but currently in the engine the number of entities is of far greater importance than the number of polygons you're rendering"

I just found this very interesting and would like to know more about best practices in Source, theoretically.

I'm going to guess that it's running into a CPU cache bottleneck with more entities due to the dated entity design of Source (in addition to regular drawcall bottlenecking).  More modern engines keep the positions, meshes, materials, so on, of every entities in their own arrays (as opposed to grouping all of them together into classes or structs) to keep processing arrays fast.

Edited February 25, 2017 by DrywallDreams

[Klems]

It's always better to share textures on multiple meshes, period. You save on map size, on loading time and on GPU memory while in-game.

That screen of nuke probably has to do with the size of these models, not the textures. It's sometimes a good idea to merge all the props of a room into a single, "huge" prop. Lots of small props will make the drawcall bigger, one big prop will make it much smaller. The trend is to do less objects on the CPU and more polygons on the GPU (modern GPU can handle it). The drawback is that the bounding box of the prop is so huge (since it encompass all the objects in the room) it's practically always "visible".

On 24/02/2017 at 4:49 PM, grapen said:

and would like to know more about best practices in Source, theoretically.

May I ask why? Are you making a map with so many props and polygons that you broke the limits of source? Do you experience a significant FPS drop on your map and you don't understand why? Are you just trying to learn? Otherwise it's probably better to avoid optimizing early.