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

Unity 4.2 submesh draw order

Discussion in 'Editor & General Support' started by echo17, Jul 25, 2013.

  1. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    I'm the author of the SmoothMoves 2D skeletal animation plugin in the Asset Store. With the launch of Unity 4.2, some bugs have appeared in the depth of my animation's meshes. It appears that with Unity 4.2, the order of the submeshes in a mesh is not being followed (as set by Mesh.SetTriangles). Instead, it looks like the submeshes are being batched by material, ignoring the submesh index entirely.

    In Unity 4.1 and earlier, the index order was followed, allowing you to switch between materials, layering mesh data by depth. With 4.2, the batching is causing this to fail.

    Some images (note that submesh #1 and #3 are both using the same material, though they should be rendered in different passes):

    4.1 and earlier (Correct ordering)





    4.2 (Incorrect ordering due to batching)





    I've submitted a bug to Unity, but I was wondering if anyone else has experienced this issue, and if so, have they had any information from the Unity support team regarding what might have changed in 4.2?
     
  2. NeeravM

    NeeravM

    Joined:
    Jul 9, 2013
    Posts:
    4
    Hi,

    I am facing similer issue. I have posted it over here on this thread.
    Thanks for reporting the Bug, please post an update on the thread if you hear back from unity.
    In the mean while I am trying out using renderTextures for workarounds but they seem to be very performance expensive.
     
  3. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Some more information: This is using "Particles/Alpha Blended".

    If I use a cutout shader, it works for a single side, but the opposite side is culled. Besides which using cutout shaders on mobile is considered a no-no anyway.
     
  4. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Thanks for the link. If anyone comes across this issue in their project, please submit a bug report through Unity using the menu "Help > Report a Bug". Be sure to include screenshots / project files to help them diagnose the issue. The more bug reports they get, the better chance there is they'll fix the problem.
     
  5. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Unity support has confirmed the bug in 4.2 with me and has sent it on to their developers. They have no timeline for the fix, however.
     
  6. khoowaikeong

    khoowaikeong

    Joined:
    Jun 13, 2013
    Posts:
    18
    had encounter this bug... no solution still... :-?
     
  7. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    I'm not sure what Unity's timeline is for bug fixes, but I imagine they try to do as many as they can into a single release instead of releasing a lot of little patches. At least they have acknowledged the bug and claim to be working on it, so that is good news.

    For now, you'll probably want to revert to an older version of Unity until they get a patch out:

    http://unity3d.com/unity/download/archive
     
  8. Kuba

    Kuba

    Moderator

    Joined:
    Jan 13, 2009
    Posts:
    416
    Hey echo17,

    Thanks for submitting a great bug report. The fix will be available in the next (most likely a hotfix) release soon.
     
  9. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Awesome, that's great news, Kuba! I'll let my users know.
     
  10. khoowaikeong

    khoowaikeong

    Joined:
    Jun 13, 2013
    Posts:
    18
    heheheh, only reason we switch to 4.2 is to use new feature. so we are branching 4.1 and 4.2 and hope 4.2 will work properly soon. :D
     
  11. DanJC

    DanJC

    Joined:
    Feb 18, 2013
    Posts:
    15
    Thanks to those who reported it. I'm getting the bug too, glad to hear a fix is on the table.
     
  12. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    6,204
    Too bad this is being classified as a bug. I would rather it batched meshes/submeshes by material.
     
  13. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    The thing that makes it a bug is that it is batching submeshes that are separated by other materials. That is a serious break in design from the past. It keeps you from being able to order your submeshes, and gives a randomness to the final result. If you had several submeshes next to each other in the ordering that all shared a material, that would be acceptable to batch. It is when you have other materials between those submeshes that causes the problem.

    @Kuba: Any word on when the hotfix will be released?
     
  14. TakuanDaikon

    TakuanDaikon

    Joined:
    Jun 6, 2010
    Posts:
    268
    I encountered the same issue with draw order being different from previous versions and had to resort to dynamically cloning materials and setting the render order on the cloned materials. Using object pooling helps mitigate the effects of duplicating the materials, but is a workaround that I'd rather not have had to implement. The ability to specify render order is integral to my product, and having this behavior change was undesirable, even if it seems more efficient. Strangely, I was only seeing this in web builds, not sure of the significance of that...
     
    Last edited: Aug 22, 2013
  15. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    That does seem odd. I am seeing the batching problem in all builds, including the Unity editor as well.
     
  16. TakuanDaikon

    TakuanDaikon

    Joined:
    Jun 6, 2010
    Posts:
    268
    It's possible that I first noticed it in web builds because that's what I was focused on when I upgraded to the new version, and had implemented my workaround before noticing on other builds. The only detail that really sticks out with clarity for me was the fact that the behavior changed and that it took several hours for me to determine the cause and implement the workaround :(
     
  17. tap

    tap

    Joined:
    Jan 7, 2013
    Posts:
    1
    I'm also experiencing this error with my project and it's creating extremely noticeable/unfavorable results. I'm wondering when a hotfix will be released?
     
  18. khoowaikeong

    khoowaikeong

    Joined:
    Jun 13, 2013
    Posts:
    18
    the problem is even if we have the same material for the submesh, in 4.2 it would still mess up their order! it is a big problem for me as the reason for going to 4.2 is to use the stencil buffer, and once the order is messed up, the stencil value will be all wrong. i made them submesh so I could adjust the ref value for the stencil as a material property so i can support "masking within a masking". this doesn't work if the object isn't draw in the order of their index.
     
  19. Kuba

    Kuba

    Moderator

    Joined:
    Jan 13, 2009
    Posts:
    416
    The fix will be available in 4.2.1 which will be released very soon™.
     
  20. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Awesome, thanks for the heads up, Kuba!
     
  21. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Hey everyone. Unity 4.2.1 is out and the bug is gone! Upgrade away
     
  22. TakuanDaikon

    TakuanDaikon

    Joined:
    Jun 6, 2010
    Posts:
    268
    I just saw that as well. This is good news :)
     
  23. DanJC

    DanJC

    Joined:
    Feb 18, 2013
    Posts:
    15
    Yay and finally.
     
  24. Jlpeebles

    Jlpeebles

    Joined:
    Oct 21, 2012
    Posts:
    54
    Hmm just opened a project that's been sitting on the sidelines and I am still having a similar issue (4.2.1f4). I have particles being rendered under terrain. Ill have to look into it more tomorrow.
     
  25. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Unity team: It looks like this issue is back again in the 5 beta 9. Is this something that is going to be addressed before final release?
     
  26. AlkisFortuneFish

    AlkisFortuneFish

    Joined:
    Apr 26, 2013
    Posts:
    970
    No, this is explicitly listed as a compatibility breaking change.

    From the upgrade guide, page 3.
     
  27. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Well that's disappointing. Thanks for the info AlkisFortuneFish.
     
  28. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
  29. echo17

    echo17

    Joined:
    Nov 24, 2011
    Posts:
    1,249
    Unfortunately, no. Let's say you have two materials: an atlas of body parts and an atlas of weapons. In this scenario, let's say you want the arm to be drawn in the back, the weapon to be drawn next, then the hand to be drawn on top of that. You would order the materials: Body, Weapon, Body. If you set the render queue you'd have the exact same problem that Unity is introducing with their override of the index. You body material would either be rendered first or last, making the weapon not between the two other parts.

    It's really too bad that Unity made this decision. With the current method of being able to index, we have full control over how the mesh renders. We could even order the mesh to group materials if we wished, or put them in the correct order if we wanted that. Now, that control is completely going away.
     
  30. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,649
    Well, unfortunately it's a corner case - it causes a problem in this situation but allows for optimizations in the vast majority of situations.

    Other approaches that spring to mind, then:
    • Have a unique material per 'layer', instead of trying to reuse materials, and use renderQueue to enforce ordering. Materials are cheap, especially when they're sharing the same textures and shaders.
    • Instead of using MeshRenderer, use a custom script with OnRenderObject that uses Graphics.DrawMeshNow to render submeshes manually. That way you get complete control over render order.
    • Split your arm/weapon/hand into separate Meshes/MeshRenderers and use Z positioning to control sort order. If the materials used are transparent then I think it'd be a bug for us to not respect Z ordering.
    • Use alpha-tested materials instead of transparent materials, and set up the vertices in your mesh with appropriate Z values, so that the depth buffer resolves the problem. Then you wouldn't even need 3 material entries; you'd save a draw call entirely.
     
    hippocoder likes this.