After spending an hour in max and exporting a cube with different subdivisions to obtain different numbers of vertices, I came to the conclusion that batching does not occur if the mesh has more than 158 vertices (the number of vertices displayed in the Unity Editor, max reports 128 vertices).
The documentation states that dynamic batching will not occur if a mesh has more than 300 vertices:
Unity can automatically batch moving objects into the same draw call if they share the same material. Batching dynamic objects has certain overhead per vertex, so batching is applied only to meshes containing less than 300 vertices.
Is the documentation wrong, and the real number 158?
The iPhone development team have asked if you can submit a bug report for this (it may turn out to be something else but they would like to be sure). If you can attach the project or at least the object that is showing the problem then it would be most helpful.
The wording of docs is not entirely correct (to avoid reader’s panic ;-))
The batching threshold is 300 pos/normal/uv vertices
If your shader use say uv2 or tangent - the threshold will be lower.
If your shader use less (say only pos) than threshold will be higher
Not exactly. For now you have budget of 3*300 vertex channels (pos/uv/color etc)
But be warned though - batching is internal thing - we may change anything ;-)) [and i hope we’ll do]
Yupp fully understand that it might change and I don’t mind that
faster is always better
My question was more to allow me to interpret outcomes from profiling and instrumenting better and I think it would be very helpfull if such informations were part of the documentation instead of threads or the answers system.
Hey, don’t kill the messenger
We are very hesitant to add this info to docs by a lot of reasons, but i can see your point. Anyway, i have nothing to do with docs, but with making stuff faster, sure ;-). The threshold was selected so the batching itself is faster then adding one more draw call. As i said in some other thread 8) apple did a great job with speeding up their drivers that’s why the threshold was unchanged from Unity iphone 1.7, while we optimized batching pretty heavily on our end. I think we’ll get back to it and tune, sure
I’ve no reason to shoot any messengers, its viable knowledge for the time it holds
Lots has changed yeah.
Also, as I’ve been on the U3 prerelease versions since the first wave of access to it, I know that U3 iOS already ran as fast as iPhone 1.7 before batching was reintroduced on my itouch 3GS, back then on 3.1.3
And I understand (at least where I’m aware of potential reasons) why UT are hesitating to set such information in stone. Like other aspects its something that is likely in a lot of flux and additionally only of direct use to a minority of the users at best, while the rest is primarily confused.
I’m toying with the idea of completely removing draw-call counts (in iOS internal profiler), but instead showing the exact amount of time those draw-calls took - such metric would be much more accurate and meaningful from stand-point of optimizations.
