Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. How can we improve our URP documentation to cover your needs? Give us your feedback. Take our survey and let us know.
    Dismiss Notice

renderqueue sorting

Discussion in 'Shaders' started by hoesing, Aug 29, 2010.

  1. hoesing

    hoesing

    Joined:
    Jun 20, 2009
    Posts:
    5
    Do render queues 2001-2999 do far to near object sorting within the queue? I'm hoping that they don't since they're in the opaque range.

    Do all queues in the 3000+ range do far to near object sorting within the queue?

    Thanks!
     
  2. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    In Unity 2.x, queues 1500 to 2500 are considered opaque and are not sorted back to front (first they are sorted by other stuff, and then front to back to get better Z culling). All other queues are sorted back to front.

    In Unity 3.0, all queues up to 2500 will be considered opaque.
     
  3. hoesing

    hoesing

    Joined:
    Jun 20, 2009
    Posts:
    5
    Exactly the info I was looking for. Thanks for the quick response!
     
  4. hoesing

    hoesing

    Joined:
    Jun 20, 2009
    Posts:
    5
    Actually, one extension to that question:

    Do you know if draw call batching on iOS/Android only happens in the opaque queues?

    I was going under that assumption, and was planning to get around it by manually sorting my objects into opaque render queues to get them to draw in the correct order, while still getting batched. Not an insane number of queues, probably something like 32 total. That's also assuming that batching doesn't cross queue boundaries. Yes, lots of assumptions :)

    Thanks!
     
  5. Aras

    Aras

    Unity Technologies

    Joined:
    Nov 7, 2005
    Posts:
    4,770
    It happens on anything that can be batched.

    That said, transparent stuff needs to be drawn back-to-front by definition, so they can only be batched if consecutive objects (after sorting back-to-front) still have the same material.

    I'd suggest not to go overboard with crazy solutions. It's not the draw calls that matter in the end, it's how much time is taken per frame, and where your bottleneck is. Are you really sure your performance is limited by draw calls and/or poor batching?
     
  6. hoesing

    hoesing

    Joined:
    Jun 20, 2009
    Posts:
    5
    Yeah, I realized after I posted that the batching probably happens per-queue after the sort. For some reason I was thinking it was possible that batching would be turned off on translucent queues, but that doesn't really make much sense.

    I'm going with multiple render queues because it's the easiest way to force correct draw order in my particular situation. There are annoying specifics that make it difficult to do spatial partitioning, so I'd rather just force the correct behavior.

    Thanks again for all the info, it was very helpful!
     
  7. xakzhong

    xakzhong

    Joined:
    Sep 25, 2014
    Posts:
    12
    "first they are sorted by other stuff, and then front to back to get better Z culling",Can you give more detail about the "other stuff"?because sometimes we just want opaque object rend from front to back for best depth test,but the unity doesn't do it as expected(some back object drawed first;checked drawcall order in framedebugger and Adreno Profiler).
     
  8. bgolus

    bgolus

    Joined:
    Dec 7, 2012
    Posts:
    11,608
    They're drawn front to back by their bounds, but the depth order of their bounds might not match the visual order of the actual polygons that are drawn. That's just kind of what happens with render bounds. They might also get batched together, or they can have their sort order modified on the render component via script.
     
unityunity