How many assets per game level is too many?
polycounter lvl 8
Hi all -
Just curious on the amount of assets per level where it gets to be too many. I know that’s a question with a hundred answers, but I’m just working on a game with some friends and I’ve created about 200 assets so far ranging from big platforms, large to small rocks (largest asset around 2500 tris). The level is pretty big, it’s a side scroller that changes scenery a lot as you play. I’ve been reusing as many assets as I can and scaling as much as I can, but I’m just curious when it becomes too many assets and is an issue? Is 200-300 a lot per level? A lot of these assets would be used for other levels as well.
Replies
From what I know an environment for an AAA fps game like rainbow six has around 3-4 millions tris without characters.
For platforms games I really don't know.
But I think the tris count is higher now. I mean I can render in real time with GI a landscape with 33 millions tris at around 15-20 fps and I have a gtx 950.
i realized after I posted this it’s really just about the tri count rather than asset count. I was just more considering draw calls I think. Just worried with a higher asset count draw calls would be an issue. But then again I guess it’s more about what’s being rendered on screen at a time.
This is a very rudimentary question, but why if every object is a draw call, is it best to use repeating assets and scale/rotate to create your scene other than it’s less time consuming? For some reason I was under the impression 2 meshes that are the same is 1 draw call (hence drawing the same mesh and just duplicating it) rather than 2 totally different meshes. Is there any advantage of using 2 duplicate meshes opposed to 2 different meshes if they both = 2 draw calls?
Instancing really doesn't get you a whole lot when we're talking about a handful of objects but when you have 500, 1000 or 10k, you start to see the savings.
thanks again for the info. One more question regarding draw calls - If I have a scene with a wood, metal, stone and brick tiling materials applied throughout on various assets, that’s 4 draw calls just for the materials, correct? So now does it matter how many different assets those 4 materials are applied to? If I have one asset that has all 4 of those materials applied to it, does that matter? Is that only just a draw call for the asset itself since the 4 tiling materials are already called into the scene?
If your engine is smart (and the popular engines are), it will group all geometry with the same material and spit it out in a single draw call.
Internally, the engine goes something like:
1) Load material A and its render settings:
2) Gather only the triangles in the scene that use material A;
3) Draw these tris (this is a call to the expensive API drawing function, the draw call).
Steps 1-2-3 are done for every material in the scene. Optimization through batching means making more meshes use the exact same material.
You can theoretically batch a static and animated meshes together (the location of triangles does not affect what material or shader they use, except in the case of vertex shaders like "GPU skinning" that move animation processing from the CPU to the GPU)
For static environment stuff on a sensible engine you can fairly safely consider 1 material to = 1 draw call but
The definition of a material can be a little cloudy.
Usually using the same Shader and textures will give you one material but parameter changes (Eg. Emissive brightness, uv scaling etc.) "can" break batching - as will different use cases such as skinning.
On the other hand if you use texture arrays you can have multiple texture sets applied with a single material thereby allowing you (in principle) to colour in many varied objects in one draw call.
There's also the matter of all the other buffers/views things need to be drawn into but we'll leave that for now..
Say, W = 0.0 uses the first texture on that vertex, W = 3.0 uses the fourth texture and so on.
The downside is that I think texture arrays are incompatible with streaming - or at least there's something not straightforward to overcome there-so you're forced to load the whole array into memory at once
It's definitely something that can give great benefits in the right situations but it's not necessarily suitable for all