How many assets per game level is too many?

jordank95

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. 

Andreicus

Depends on the tris count. 
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.

oglu

If your engine does stream the data there is no asset limit for a level. Only whats on screen.

jordank95

@oglu @Andreicus

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. 

Eric Chadwick

Only way to know for sure is to profile it, and keep doing so while you polish.

Mark Dygert

Each object is a draw call. If you make a house out of 500 tiled assets that's at least 500 draw calls. If you collapse that down to a single mesh, that's one draw call. Obviously there are other things to consider when combining objects so you might want to combine each floor so you can hide all of the things you don't see (other floors, roof ect...) but in general you want as few objects as possible.

jordank95

Thanks @Mark Dygert

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?

Mark Dygert

This is where instancing starts to factor into things. By making instanced copies of the object, the copies are counted as one object inside quite a few sections of the rendering pipeline. It gets used for things like grass, trees, rocks and sometimes buildings. batching all of the grass into a single render pass is not exactly the same as rendering a single clump of grass, all of those verts do add up, so does the transparency sorting so it's not exactly equal to rendering a single object but it does keep the engine from having to process each object individually.

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.

jordank95

@Mark Dygert

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?

RN

There's a draw call per material.  
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)

poopipe

To expand on what RN says - its not entirely 1:1 in practice. 

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.. 

RN

poopipe said:

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.

@poopipe that is very cool. The OpenGL docs say that you would use the values of the W texture coordinates (as in, UVW) per vertex to control what texture from the array to use.
Say, W = 0.0 uses the first texture on that vertex, W = 3.0 uses the fourth texture and so on.

poopipe

Seems like a sensible enough place to store the info... I've no idea what happens at the hardware level but in the context I'm used to seeing them implemented it's a compile time switch.

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 

marks

A good rule of thumb that I often use is : "If you have to ask, it's too many".

Alex_J

Anecdote from game I am working on now -- no difference to frame rate if it's 200k tris on screen or 4 million.

I'm no expert at all in the technical stuff. I just push buttons and see what happens. But I had a programmer run profiler and that helps me identify what areas to focus on.

Yesterday with a forest scene in Unity I was barely getting 30 fps. After running profiler I adjust shadow distances, LOD distances, and the way some things are spawning so there isn't as much alpha overdraw, and now it's 90fps +. And it looks the same (or even better).

So all that is to say, there is a lot more than just the triangle count. It is best to forget about all of that and just make the game look right first, then go in selectively and optimize where needed. Chances are you can get away with a lot more than you expect. And if you shoehorn yourself not only might you waste potential but you also waste time trying to conform to incorrect speculations.