My question is then, what are the rules for batching exactly? They seem to be nebulous and everyone seems to have a different opinion on how it works exactly. I understand sharing materials, that there’s some vert/tri limit per object and that there’s a vert/tri limit per batch. I also understand that it is not as simple as that. Anyone care to help me clarify how this works so that I can better understand how to optimize for my game?
As far as i know in order objects to batch tehey need to
-
share the same material
-
must noct be animated with bones or otherwise being deformed
-
have a tri count of 300 max
-
be marked as static (for static batching)
-
Standard GUIElements such as GUIText don´t batch at all, resulting in 1 more drawcall per Element.
-
and a unity developer wrote in some post you should target to armv7 (armv6 + armv7 ) as this is supposed to have some optimizations concerning batching.
I believe that it’s very important we actually get a document about this. Batching results have generally seemed buggy to me, but without a ruleset, how am I actually supposed to know if it is expected behavior?
I checked the Static box on a bunch of roads and houses and my framerate dropped by like 400-500% and the previously smooth interpolation of frames became jerky. So I unchecked the Static boxes and got the framerate back up… Then I found a gap in a couple of road sections and repositioned them by a hair or two and my framerate dropped by 200-300%. After a couple of compiles into game mode it went back to the high frame rate I had prior. What is the deal with that??
BTH
the limit for dynamic batching is 300 vertices,
there’s no limit for static batching I am aware of.
There are other things at work as well. For example, make a cube and it will result in 1 draw call. Duplicate that cube 24 times and it’s still 1 draw call. Duplicate it again, and it results in 2 draw calls. So the limit for a dynamic batch isn’t 300 verts/tris per object, it seems to be 300 verts/tris per batch? I was just experimenting and I found this interesting. I was lead to believe before that it was 300 verts per object would batch.
It will batch as long as the overhead of dynamic batching still gains you performance.
It will breakup the batch / stop batching if the time to update the dynamic batch is higher than it would be without batching (ie when you would lose performance through batching)
I see, that makes sense.
Sure, it makes sense, but that doesn’t help us know when it’s working correctly. If they’re going to leave it as a complete mystery, what the rules are, then they should take away the ability to even know if batching is happening, as seeing unexpected results all the time is just infuriating.
Would like clarification on all the batching rules. For example I drop a car into the world, which is made up of separate chunks like the wheels but share the same texture. Overall its 800 polys, but far less as pieces.
Hmmmm… I’m getting inconsistencies with Transparency materials too. They don’t batch well the first time, like they don’t batch at all. Then if I convert back the cubes to a diffuse material, it batches fine. Then I tried Transparency again and now it batches ok this time.
Weird.
objects with transparent materials not always batch. I have been told that the reason is that when the frame is being drawn, when batched, transparent triangles in front may be rendered before what they have behind, resulting in image glitches (you can’t render transparency if you don’t know what is behind). Transparent materials objects may be rendered in different order, so they need not to be batched (if batched, they are rendered all at the same time).
You cant render all house windows if you don’t know exactly what is behind of each one. And iPhone architecture renders triangles in random order (newer hardware renders transparent objects the last).