Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Draw Call Batching and Per Pixel Lighting

Discussion in 'Editor & General Support' started by rflagg, Apr 5, 2013.

  1. rflagg

    rflagg

    Joined:
    Jan 18, 2013
    Posts:
    30
    I'm working on a 2d sprite based game with a top-down perspective. The level is made up of many separate sprites all pieced together. All of the level sprites I have on a single atlas and those all get batched together into 1 draw call when I'm in game.

    However the draw calls skyrocket once I add in a single light. It goes from 1 draw call for all the sprites combined, to 2 draw calls for each one. On a level with 30 sprites on the screen, that's 60 draw calls instead of 1.

    The render mode on the light is set to Auto. When I switch it to Not Important, the draw calls go back to 1. Does this mean you can't do per pixel lighting when trying to batch draw calls?

    Currently I'm not using Unity Pro. Could this be a reason why the batching isn't working properly?

    My rendering path in player settings is set to Forward Rendering. I have dynamic batching enabled (though I think here what I really want is static batching), and I am using 2d toolkit to do the sprite management.
     
  2. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,623
    the problem with batching + per-pixel lighting is:
    when you need to do multi-pass rendering (several per-pixel lights, important point/spot lights) you want to make sure that your transformed geometry matches exactly between passes (otherwise your depth check will be screwed). Due to this we stop batching the geometry when you want multi-pass render.
    On the other hand:
    You do understand that DrawCall is pure CPU cost? what's your target platfrom that you worry about 60 DIPs?
    EDIT: sure, the problem is with runtime batching (we transform vertices at runtime) - static batching (or some kind of one-time combine meshes script) should do the trick.
     
    Last edited: Apr 5, 2013
  3. FiveFingers

    FiveFingers

    Joined:
    Oct 15, 2009
    Posts:
    541
    This is easy to solve. I guess you won't need pixel light the sprites quads right ?
    Filter the impact of the pixel light so that is calculated only on certain layers (eg background, terrain, whatsoever).

    Orion Attack webplayer/iOS (link in signature) uses this technique for the pixel light that reveals the grid upon building a tower.
     
  4. rflagg

    rflagg

    Joined:
    Jan 18, 2013
    Posts:
    30
    Yes, I read the draw call documentation about it being purely CPU. Target platform is iPad. It's not 60 draw calls though. that was just an example. I could have roughly 100 tiles on screen which would results in 300 draw calls.

    I should clarify, these level tiles are static and won't be moving. So I do want static batching, which as you say would solve the problem and batch it all together?

    Thanks for the suggestion. I'll definitely consider going this route if performance is an issue. Some sprites I may want per pixel lighting though since I would eventually like to add normal maps to the sprites to get a nice lighting effect across the sprite. Ground tiles probably wont need it, and vertex lighting should do for those.
     
  5. Alexey

    Alexey

    Unity Technologies

    Joined:
    May 10, 2010
    Posts:
    1,623
    yes, sure - in case of static batching vertices are pre-transformed at build time - so should be good.
    Anyway, if you want to stay on free - you still can per-use combine meshes script (or how it is called).
    ipad2 can do it yes ;-)
    but anyway, it is doable to batch it - be it static batch or some sort of one-time-at-level-load combining through script