Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice

Dynamic Batching - some clarity?

Discussion in 'Editor & General Support' started by MattFS, May 1, 2011.

  1. MattFS

    MattFS

    Joined:
    Jul 14, 2009
    Posts:
    219
    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!
     
  2. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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.
     
  3. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    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
     
  4. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Some official clarification is actually needed in this case, so I would very much appreciate a unity staff reply.
     
  5. MattFS

    MattFS

    Joined:
    Jul 14, 2009
    Posts:
    219
    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!
     
  6. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    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
     
  7. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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!! :( :( :(
     
  8. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    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)
     
    Last edited: May 3, 2011
  9. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Well that sounds crazily strange. Come on, maybe test performance first, and then do something. The days of 30 DIP = 0 fps are long gone
     
  10. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    Alexey... clarification on how it works please :)
     
  11. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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
     
  12. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    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.
     
  13. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Well, as Rej was saying from the very beginning, we probably shouldn't document batching at all.
    300 verts are here simply because if we start to enumerate all possible cases it will be useless for everyone apart one or two people.
    Well what i call crazy, with your analogy: all the same but you wanted plum tomatoes from the very beginning, and you believed that beans can be transformed to them somehow.
    What do I see in that thread? People come out of nowhere, reads something, and make some conclusions without actually checking stuff. Really,
    WTH? Did you try to run your game? Does it batch like you wanted? If not - is it slow?
    Come on guys, with every thread like this you got us more and more inclined to exclude any info on batching from docs
     
  14. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    The limit is 900 attributes (meaning 300 XYZNUV vertices)
    different scale won't work
    non-uniform-scale won't batch with uniform scale
    multi-pass material won't batch
    if you use tex-gen most likely no-batch (there are strict rules on that one, but i skip it to avoid more confusion)
     
  15. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601

    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.
     
    Last edited: May 3, 2011
  16. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    No, if we must to draw current batch, we will start new one. Actually one mesh drawn is just corner case - it is a batch from one mesh 8). So no, we will try to batch every time

    1,3 answered more or less

    4 - yes - good idea actually, if i have a penny for every test with two objects and two draw calls (second one for deferred buffer resolve)...

    But anyway, far better is to educate guys, that draw calls are far from being the most important metric. So far we are thinking to remove it like completely. But that's for the future
     
  17. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    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.
     
  18. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Well, yes, but what if we change it to "Rendering Time" with intelligent hints about where possible problems are? We need to put something into new versions to keep all of ya excited ;-))
     
  19. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    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)
     
  20. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    did we screw this? well, bug report (feature request probably) - we have development build - seems like perfect place to enable perfhud
    As a side note - you can find dll that forces app to use perfhud (i won't say you where, because, well, you understand ;-))
    Also, don't forget the mighty PIX ;-)
     
  21. Dreamora

    Dreamora

    Joined:
    Apr 5, 2008
    Posts:
    26,601
    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 :)
     
    Last edited: May 4, 2011
  22. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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 :)
     
  23. Fidde

    Fidde

    Joined:
    Dec 20, 2010
    Posts:
    109
    Thanks for the info Alexey (and questions, Dreamora). Very interesting read on this arcane and important topic.
     
  24. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Ok, let me re-iterate the main points:
    Draw Call cost consists of two things:
    1. Driver overhead and Unity overhead. It is pure CPU cost. If you are GPU bound (fillrate, for example) even drawing whole scene in 1 DIP won't make your game faster. Sure, both Apple and Unity strives to make their overhead lower. Even on older devices draw call is way faster then it used to be
    2. GPU overhead. Without going into technical side of things - drawing two objects with different textures might be slower then drawing two objects with same texture etc. What can I say about it? Noone can avoid that cost. But sure we are trying to sort by material (on unity side) etc. Anyway - this cost will be here dis-regarding batching. And sure, there are even more to this, like on PowerVR (gpu inside iphones) it has less impact due to architecture etc.

    So in short - i wouldn't say that you should not care about draw calls at all (1k draw calls would kill iphone most likely ;-)), but you should first understand what makes your game slower, and only then run around forums blaming batching for everything 8).
     
  25. Demostenes

    Demostenes

    Joined:
    Sep 10, 2010
    Posts:
    1,106
    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.
     
    Last edited: May 4, 2011
  26. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Well, I can see your point, but we have moving targets here, so that's why (if you search forums) you can see me saying the same about batching limitations in more then one thread ;-). It is just when discussion is going into direction "my two objects are not batched i'm doomed" you wanted it never be mentioned in docs - because people miss the point entirely
     
  27. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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?
     
  28. Demostenes

    Demostenes

    Joined:
    Sep 10, 2010
    Posts:
    1,106
    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 :)
     
  29. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    well, check the time that cpu spent rendering your frame
    look at cpu-waits-gpu
    enable gpu timing (in AppController)
    i mean there is no silver bullet - you should look at your game and profiler readings to understand what's going on
     
  30. Demostenes

    Demostenes

    Joined:
    Sep 10, 2010
    Posts:
    1,106
    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.
     
  31. AcidArrow

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,700
    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.
     
  32. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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...
     
    Last edited: May 4, 2011
  33. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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.
     
  34. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Well, if you ARE heavy on cpu side batching *might* help
    but oh well, i posted some catches before in that thread
     
  35. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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...
     
  36. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    well, use mobile shaders
    check unify community for Rej's bake material to texture script
    get creative in one word ;-)
     
  37. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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... :-(
     
  38. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    you get it slightly wrong
    you are limited by *900* attributes per mesh (as of now - we might change it)
    meaning if you use XYZNUV - you are limited by 300 vertices
    XYZUV - it should be 450 vertices
     
  39. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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...
     
  40. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    well, look at stuff i posted and if you got all this and still do not batch - bug report it with repro and drop case number
     
  41. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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...
     
  42. BigRedSwitch

    BigRedSwitch

    Joined:
    Feb 11, 2009
    Posts:
    724
    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!
     
  43. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I do not know the specifics, but that is what I read from the large number of posts relating to draw calls :)
     
  44. kurylo3d

    kurylo3d

    Joined:
    Nov 7, 2009
    Posts:
    1,123
    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?
     
  45. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,401
    Yes, that's what dynamic batching means. Static batching is for objects that don't move.

    --Eric
     
  46. kurylo3d

    kurylo3d

    Joined:
    Nov 7, 2009
    Posts:
    1,123
    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?
     
  47. crafTDev

    crafTDev

    Joined:
    Nov 5, 2008
    Posts:
    1,820
    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...
     
  48. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    Just as heads-up - we fixed some issues with batching in 3.4, the biggest one stopping batch prematurely. So if you have some issues, please wait and try with 3.4
     
  49. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    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 :p
     
  50. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,624
    well, i'm in mobile team, so i tested the fix on ipad first ;-)