Dynamic batching issues - Is there a 300 vertices limit?

Hello there

I’m having trouble with dynamic draw call batching… After hours fiddling with it I concluded what’s breaking it is when I use meshes with more than 300 vertices. I have a scene in which I can switch back and forth between <300 and >300 vertices meshes to reproduce that.

I don’t know if the 300 vertex limit is by design but that’s too low. Maybe it’s intended for a specific situation where you have slow GPU rendering and relatively low poly models (maybe on mobiles?) but for PCs draw calls are much slower than the actual rendering so they should be minimized to a much greater extent. 300 vertices is nothing on PCs and modern consoles… a cube with with its faces extruded twice has more than that.

Any help on this? Is there a way to change that somehow? (maybe in the material settings)

Saving draw-calls by batching meshes together does only save some amount of time that the cpu would use to submit that mashes individually to the gpu.
If you batching to big of a mesh every frame (that what dynamic batching is) you would be using more cpu time to combine them that you would save by batching.
The unity guys did some test and figured out that its worth doing if you are at 900 vertex attributes and below per mesh. (if you using Vertex Position, Normal and UV0 its just the 300 verteces you mentiond).
There is no option to change that limit and as far as i know its not planned to change it.
If you can make the case to unity( via a bugreport) that allowing a bigger mesh to be batched dynamically would be beneficial they might test it again to see if its with a change.

If you have a way to combine meshes more efficient then unity does it every frame that the community would be happy to ear about it.
If you do not need to move the meshes (or only in a bigger group together) after they have been instantiated the StaticBatchingUtility to combine them together (once not every frame)

If you have a lot of the same mesh and just need them often in your scene, look for gpu instancing (One draw command for a lot of the same meshen with only some diffrent parameters)

Use the Profiler to figure out what is your performance bottleneck is.

4 Likes

Thanks for your reply.

I don’t think that number is realistic at all… I’m really curious to know how they came up with it, as it certainly doesn’t seem to be the result of any reasonable real-life measurement. Just look how the other engines like UE4 do that. I’m really struggling to imagine a situation where that number would make much sense except for mobiles.

The profiler already shows a much larger rendering overhead than what I was expecting, I’m porting a prototype from Panda3D and so far I couldn’t reach numbers not even close to it when it comes to rendering, not even with the legacy/fast diffuse shader. There are way too many draw calls, although the GPU takes nothing to actually render, calling it all the time is a huge bottleneck.

I’m having another problem that’s a bit more intriguing though… for some reason, the exact same model in Unity have more vertices when I use the FBX format (compared to OBJ). I’m almost sure it’s a problem in Unity because importing the models back into my 3D package works as expected. That has nothing to do with vertices doubling to have hard normals because the result is absolutely the same and all stats are the same except for the vertex count.

I’m getting really frustrated with Unity so far. I’m having issues with absolutely everything, from Visual Studio integration to procedural terrain generation, only the absolute basics work fine, and even some of them (like mesh importing) are broken. What a difference from Bitsquid/Stingray for example, or even UE4 which I’ve only used for a week but is much better and have full source access.

I’ll keep trying for a little bit more, but so far Unity is the only engine that really made me want to go back to corgi+mathfu+assimp+bullet+sdl+bgfx… Sure it’s good to quickly drop some assets around and get something playable quickly, but anything beyond that has been a pain in the ass. I really hope I’m wrong in this.

Update:
I’ve tried with other FBX models, and this seems to be a hit and miss issue. I couldn’t pinpoint the problem, sometimes FBX and OBJ have the same vertex count, sometimes they don’t, no matter if there are smooth faces or not.
I’m giving up on Unity for the moment. It’s not a bad engine but it’s really far from what I was expecting in terms of fine grained control. I have no desire for example to code a vertex debugger with offsetter to figure what’s wrong, that’s exactly why I’m using an engine like that to begin with.
Besides the frustration with Unity, the determinant factor wasn’t that, I work in an AAA studio and they got interested in my game (a personal side-project), so I’m going to use another engine.
If the model vertex count problem isn’t Unity’s fault I apologize, but overall Unity really needs a lot of work. I didn’t know for example that debug drawing was so slow and I’ve drawn a lot of lines which ended up just freezing Unity, which required a task kill. That shouldn’t happen.
It appears Unity is also lagging behind the competition, I’m talking about things like node-based shader editor, decals and runtime navmesh, take a look on the changelog of the competitors and compare to Unity’s for instance… it’s like night and day.
Anyway, best of luck for you guys.

Sorry to hear your dissatisfaction with your way with unity.
You should see unity as a tool.
If its not the tool for the job you are trying to do , use a tools that is more apposite for your job and way to work.
I wish you best luck and success with your project.