Dynamic Batching - some clarity?

hi all,

I've read a lot of the threads on here and most people seem to be under the impression that the 300vert limit is per object but my tests show otherwise.

• 2 objects with 250verts will not batch (Draw Calls 2, Batches 0).
• 2 objects with 148verts (254tris) will not batch, even though their combined total is still less than 300verts
• 120 objects with 4verts (2tris) will batch up to ~480verts (Draw Calls 1, Batches 120)

And yes, I am well aware of batching requirements, stripping, UV/Smooth Groups and other little caveats that are sometimes overlooked - I'm talking about the 'true' "Unity" verts that the FBX Exporter displays in the Preview pane.

So I'm confused.. the official Unity docs say

...and as mentioned, reading through threads here suggest it is per-object ? But - my tests say otherwise and I guess the wording of the documents is ambiguous... "meshes" as in a collection of that combined are less than 300? ...or "meshes" as in several meshes where each is less than 300?

And it seems this '300' number is ambiguous as well as my tests either wouldn't batch whilst trying to follow the doc guidelines, but then would batch wonderfully as I broke the doc guidelines?

Could a Unity engineer chime in and give us the technical requirements for this?

Cheers!

 

It is per batch. Each batch can contain up to 300 verts. Once you have filled one batch up, it will make another. It's good for very low poly things. It is not per object, it is per batch where a batch is a number of objects combined into a single draw call.

So say you have 3 80 polygon trees? that will use up 240 of the current batch, and one draw call.

What worries me is your finding here:

That should get batched. Not sure why not. Also not sure why 300 is a mythical limit, and why 300 was chosen.

 

It's not just vertices, but also triangles. I thought the docs were fixed by now, but apparently not. Also, the actual limit seems to be 287 tris (I guess it should be "about 300" rather than "exactly 300"). The vertex limit is even less, about 190. So basically the docs are misleading to the point of being wrong. As for why the limits, batching isn't free, so I assume they tested and found the point where the cost of batching outweighed the cost of draw calls, and made the limit less than that.

--Eric

 

Some official clarification is actually needed in this case, so I would very much appreciate a unity staff reply.

 

thanks for the replies...
Eric5h5, when you say 'about 300tris', did you get this value through your own tests as the docs specify the limit in verts.
Yeh I can understand how they would have come to the 300 limit but it would be good to have a more in depth 'official' explanation of this as when you're working with already extremely low poly models (for web/iphone) then these limits can really change your workflow... different story for those people making games where each prop is 3000tris!

cheers!

 

There was a discussion about this previously; someone from UT said it was supposed to be tris. And yes I tested myself too, as always...don't just take anyone's word for it, not even the guys who made it.

--Eric

 

Hold the phone!

Basically my entire game is built around the concept that anything with sub 300 verts, using the same material will be batched, and now it's coming to light that this is completely wrong information, and you have to work within frankly impossible limitations to see any kind of real use to this dynamic batching?

Combining objects into 300 vert batches is practically useless, and not what the documentation says *AT ALL*:

It doesn't matter which way you read this, it suggests that if you have objects containing less than 300 verts, then they will be batched, as long as they use the same material. How could something this important be misrepresented in such an epic way??

Dynamic batching was supposed to be an easy solution to the previous method of creating a single draw-call - using skinned meshes - but if the information above is correct (you have to have < 287 polys and < 190 verts, and even if you do that, they'll only be combined up to 300 verts - hence if you have 2x 190 vert objects, they won't get batched anyway), then this is nothing like as good as the skinned mesh method.

I'm seriously upset about this, to be honest. It's an absolutely EPIC fail on Unity's part, and really shouldn't have happened. What's more, the documentation should be fixed immediately!!

 

I'm pretty sure its meant to be verts and not tris, reason is that in Unity iPhone 1.x there was originally the bug that they meant verts and had tris in the docs. Would be very strange if they F***ed it up now vice versa, also the discussion on the matter here on the board with a unity dev implied that its verts cause he also pointed out that it is 300 "default verts", that means vertex with position, 1 uv, normal
if the vertex contains more information like 2 uv or the tangent, then the number will drop, down to 200 with fully packed ones I think.

Whats unknown is the max batch size. On Unity iPhone 1.x it was about 4000, generally its limited though to what makes sense performance wise. when the batching wastes more frametime than it gains, it will switch to a new batch. With 4000 already being the number of pre 3GS hardware on iOS 2 and 3, I would suspect that dynamic batches on the desktop are limited to something in the 1000 - 2000 range, as anything beyond that takes more frame time than just leaving them alone.

One could argument with 10000 objects that would be vice versa, but you will find out why batching will be your smallest problem when you hit 10000 objects


Also I would not call it useless, for 2D games its more than enough. If you feel like whining or just that 300 default verts is by far too little, go over to shiva and try to get your mouth rolled back when you see that the limit there for dyn batching is 32 verts, which shows much better what dyn batching is for and thats batching mini crap (stones, grass and alike) that surrounds you, the point is NOT to batch the environment or characters or vehicles (skinned renderers don't batch anyway) cause the batching of them takes significantly more time than 1 drawcall will save ya as the vertex buffer is rebuilt every single frame! (-> thats dyn batching)

 

Alexey... clarification on how it works please

 

When it says in the documentation that anything < 300 verts will be batched with objects using the same material, it's not "crazy" to expect that to be the case. Calling it "crazy" is like going to the supermarket and buying a can of baked beans, getting home, finding the can actually contains plum tomatoes and being OK with that! Personally, if I buy beans, I expect beans!!

If rules are laid out and people follow them, they should expect the outcome they're told about. Not something which has no resemblance to the actual outcome.

On that note, could you please tell us what the score with this dynamic batching actually is and if it is just for doing "stuff on the periphery" or if we can actually use it to make games which push the boundaries of what we normally expect to see on an iOS device.

Thanks.

SB

 

The documentation though does not say that all will go in one batch, doing so would totally kill the benefit of batching as beyond a few thousand verts, you waste more frametime on updating the dynamic batch mesh each than the drawcalls of the distinct objects will use in 95%+ of all cases.

 

While I fully agree on the WTH, just due to the fact that talking about optimizations and "your need" for them if you have not even verified that the problem is in any form related, I'm also forced to say that I get undoubtfully the feeling that the later might give a clear impression of "mocking about customers", "false advertisement on the page and optimization docs" or something along the line, which I'm sure wasn't your intention behind it (you are likely just pissed that we hammer on the topic while you know that it has 31 corner cases which can disable batching or make it look as if it were disabled, but which might change and thus don't make sense in the doc or are just too techie )


What people are seeking are some general information on what the requirements are to even stand a chance to have it batching.

Right now its good faith, educated, blind guessing, we know even less about the U3 batching system than we knew about the Unity iPhone 1.x one and there the information were already scarse enough to not fill a single piece of paper with it.

I know it might be pretty tricky, that part is obvious and out of discussion given the way vertices and related data work, how and where they are processed etc, but independent of how complicated and complex it is, you still need to have a form of measurement that decides whats batched and what not as code can not god style way decide to do it or not so share at least that measure. People that don't understand it can always ask those who do, but if we all know nothing about it, then its granted to backfire, as you can see on this and the other 3 threads on the matter that every single time went out of control basically after a UT staff member has thrown in a statement like this, even if not meant the way it sounds

My request / recommendation would be:

1. Share the worst case number of vertices that would batch, that means the number of vertices that would batch when completely full packed with UVs, tangents etc. A UT dev mentioned that it could at go down till 200 verts at worst if I recall right
2. Share the max batching size, if dynamic basing on what its decided and what happens beyond it (at the time its not even clear if meshes that exceed the max batch size get added to a second batch or will exist on their own - just to give you an idea on how devastating the situation surrounding the batching information is)
3. In cases its technically disabled, list at least the general "idiot proof ones" like non-uniform scaling, lightmaps, multipass materials, reflection, reflection, potentially alpha blend / cutoff (or just make it the other way round: requires opaque if thats the case)
4. Include crucial informations on the documentations on where batching works but that stats are missleading so less tech versed users that don't live on the board still have a chance like when using pixel lights, blob projectors and alike or usage of realtime shadows in forward rendering where even with working batching additional draw calls will be added just due to the required redraw of the objects geometry itself.

Nobody cares about the inner working (ok most don't, a few techies here including me potentially wouldn't be unhappy to know it but we are professional enough to not die nor whine without that as long as the information we have gives us some predictability on it)



EDIT: I need to train my letters per minute again I guess
Thanks alexey
Thats already a lot of valuable information.

 

Agreed, the DrawCalls, at least if we exclude iOS3 and pre 3GS mobile platforms (and android with sucky drivers aka most), are by far not the most important metric if a really important metric at all (4th gen iOS devices + iPad1 should have force educated some on the missthinking I guess and hope).
On the desktop its basically impossible to hit the drawcall wall without crushing through 3 others first anyway. Also its just one of about many things to keep in mind for optimization from a tech point of view.

For mobile though I wouldn't cut it, at least not until the day you also drop pre ARMV7 cpu or OES 1.1 only hardware support on mobiles, where it still is an important metric as it gives a good guideline to keep artists "within reasonable bounds" to target the devices.

 

That naturally gets my full support as its 10 times more meaningfull for 95%+ of the users that don't talk technologian (perhaps also cause even if Unity don't give me the information, there are still the tools for those with the background aka apples OGL instruments, nvperfhud (given the support works again and NV finally fixes the driver prob for 32bit on 64bit) and gDebugger that are going to give a plentitude of low level informations)

 

In the 3.0 beta it was broke yes.
Its possible that it returned working, I was in the situation that I had to decide between a driver that works fine otherwise and one that supports NVPerf and I decided for the one that gives me better experience on day to day but which killed out the possibility to use nvperf, need to check if they finally got that straight again and test if Unity works in there again too.

And I agree, given its screwed, the dev build would definitely be the top place to enable it

I omitted PIX, cause its great for its tasks, but in this context it and with nvperfhud on the plate, I didn't consider it "comparable" anymore


Thanks again for the insight on the batching Alexey, well appreciated.

EDIT: Seems to work again in U3.3 with the finally updated NV PerfHUD 6.70

 

Thanks for some insights Alexey. Although many of us would love to actually build our games with a best practises in mind. If you say drawcalls are not a problem then I am going to take your advice and not worry about draw. In fact fill rate is at the top of my mind for iOS. Batching is something of a problem on the device for me when I have 20 different ones going.

The driver likely does batch textures by itself though, so what we see in unity is not necessarily a nightmare scenario

 

Thanks for the info Alexey (and questions, Dreamora). Very interesting read on this arcane and important topic.

 

This is not true. Such description is crucial for correct usage. If you document only few information, it will generate more questions, if you document none, you will achieve only "it is broken" response. Unity documentation is very shallow in general. It is good for newbies and clicking few casual kid games, but once you try to push Unity to its limits (and you will with each bigger game done by adults), there is desperate lack of any detailed information. Especially kind of information like "how this works inside", or "what is slow, what not, what to do and what rather not and WHY"
Many people on this forum who are selling their "plugins" showed, that writing good documentation is possible, if you like your job and have will. Unity team should be ashamed, that indies are capable of far superior work, then full-time documentation team.

 

Alexey - you say that drawcalls shouldn't be our focus anymore, but what is a reasonable amount of draw-calls on iOS devices? On the iPhone 3G, I was panicing when I hit 10 drawcalls, so what's the 3GS equivalent level? My game has been (at times) knocking on 80+ drawcalls, and it's ran like a dog, but it's difficult to actually come up with what the time drain is - is it a draw-call or fill-rate issue, or is it that the game is CPU bound, and how do I establish that?

 

Sure, I understand this. But in case of existing full documentation you can just put url and tell "you missed the point, read again", instead of writing many paragraphs with complex answer, which should be in documentation already

 

I would reccomend you to do some stress test on your target platform. Then you will easily see, what is top for you. Each game is different, number of verts and drawcalls is not enough to make any conclussions.

 

Iphone 4 has a pretty good cpu so draw calls are not much of a problem. Fillrate is a problem there.

On iphone 3gs, fillrate is not much of a problem, because it has the same GPU as 4 but 1/4 of the pixels. The cpu is slower though, so draw calls may be a problem (with something much higher than the 20-30 draw calls that was the bottle neck on pre-3g hardware).

In short though, as the phone hardware becomes more powerful, it is much harder and complex to find what the bottlenecks are, because in the end it depends on a lot of things you have in your game.

To find what the bottleneck is in your game though, you will have to use the profiler as much as you can.

 

I think I see what Alexey is getting at here. I mean most devices will be: 3gs, 4g or ipad equivalents, not 3g. This means 9 times out of 10 it's going to be fill rate for ipad or 4g. I am glad that is already my focus

S7ARBVCK: you strike me as someone who has never done a game before this one. The way you are going is that you aren't even profiling. Profiling is the first thing you do to find the real cause, because the real cause is never obvious.

What alexey said to you is if you have any number on cpu waits cpu line, it means draw calls are not a problem because draw calls are handled on the cpu. So cpu waits gpu means the draw calls are faster than the slow down. That the cpu is sitting around waiting.

In screenshots of your game I see two issues: 1. a lot of physics. 2. a lot of particles.

If cpu is too high on physics and there is no cpu wait gpu, this means physics are the bottleneck. To solve this, you might consider swapping the car that just crashed for a proxy which is just a couple of cubes on the moment of impact. You might want to lower Solver Iteriation count and raise sleep velocity. There is a lot of tricks. Once Physics has been made as fast as possible for that, there's lots of things to do in script to speed it up. Only when you have cpu waits gpu then you move to the next step... fill rate... because obviously, draw calls are not yet a problem.

You have to look at things like large transparent quads for ui, or particle systems. You also might want to look at shaders here. Are the shaders optimal? texture sizes are also a problem in a lot of cases too. And so on...

 

Thanks!

I've only worked on 46 professionally published titles so far, including being the producer on Crysis...

I can appreciate your assumption, but the game I'm working on is pretty big and quite a push for an iOS device. As I've actually written it all myself, it's taken me a while - I started it on Unity iPhone 1.7, when there was no such thing as a debugger or a profiler. All my debugging has been done "old skool" style with Debug.Log statements.

You're also right about the physics and particles too, but I have systems in place to attempt to control these as much as possible. The game runs surprisingly fast for what it's doing, it's just that I'd much sooner it was even faster based on how the documentation describes the draw-call batching.

 

Also - your suggestions are all covered already. Thanks for suggesting them, though - makes me feel like everything I've done is right. The only mesh colliders in the game are on the player car and the world - none of the others are at all. The GUI uses sprite manager 2, and all icons are cropped to the size used for the image. All AI cars use the same texture, the player car uses it's own texture, the world uses 3 textures (plus lightmaps, limited to 5 per stage), and the UI uses one texture, so each level is made up from 11 textures, which are all 1024x1024.

I must admit a bit of defeat with shaders - I have a working knowledge of them, but I couldn't vouch for the fact that they're the fastest available. I've always been a C\C++ coder, and just used the shaders "off the shelf" which worked...

 

On reading your responses to this thread, I'm not sure I'll ever be able to get Batching to work out for me, to be honest. If each element of the vertex essentially counts as a vertex (for the purposes of the batching calculation) then with XYZ and UV components for the object, alongside the numbers touted here for the amount allowed, I'd need to be looking at an object which uses < 200 verts, which I just don't think I could get to work with the visual style of my game... :-(

 

OK - accepted, but unfortunately it still doesn't seem to work in my game, despite the fact that all the vehicles are < 300 verts and all use exactly the same material in order to aid batching. Not sure where I can be going wrong...

 

are the meshes exported with reset X form applied or such? batching wont work if the root transform scale is different from what I have heard. That may just be people throwing information in the air though...

 

I have to claim ignorance when it comes to the application of reset X-Form on the models; I'd expect that was performed, as it seems to be part of the standard work-flow for game-artists. Any idea how I can tell and resolve the issue? I'm keen to try anything, really!

 

I do not know the specifics, but that is what I read from the large number of posts relating to draw calls

 

Do small model peices get batched even if they are moving objects. For instnace a bunch of cans or a bunch of bricks... that get blown off a wall in an explosion... are those being batched while they move? or.. Do they get batched once they stop moving and physics are disabled?

 

Yes, that's what dynamic batching means. Static batching is for objects that don't move.

--Eric

 

Dont really see why people are complaining so much on this thread. Its an awesome feature to have.. espeacially if ur blowing up an alley full of garbage... or a wall full of bricks. Maybe it just wasnt documented correctly when they said how it works. I myself have had trouble trying to figure out if it works or not.

I read somewhere on this thread that it doesnt work for objects with shaders that use multiple passes. Does that mean normal mapped objects or objects with a spec pass cannot be dynamically batched?

 

Hmm...fillrate might be my problem...but where should I start? Are there any guides for how to solve this...currently using Ezgui + spritemanager...grid building my levels using just one quare plane a piece n vertex snapping them together then using on material for all that...

 

Hope this will be going for ios too as we have to buy a new unity pro + unity pro ios soon as my little team is due to become two