[OFFICIAL] 2D Sorting feedback

After andy touch asked about the 2D workflow in unity, I mentioned my trouble with 2D sorting. He asked for more info so... here goes

(These experiences are from Ori and the blind forest which doesn't use the SpriteRenderer but the same applies to sprite renderers. It's mostly relevant for 2.5D games using a perspective camera)

Our artists laid out the tiles and used the z axis as depth. Obviously for transparent stuff, the higher the z value, the earlier it should get drawn. This draw ordering should be consistent to what the artist laid out and should never change. Sounds easy but this is a mess right now in unity.

Here's the story of what we went through:

1. Just a regular perspective camera and sprite renderers. Pops under movement and rotation... this is because stuff is sorted on distance from camera, moving or rotating this changes the distance and thus the order, sigh...

2. Use this (http://docs.unity3d.com/ScriptReference/TransparencySortMode.html) to make camera act like an orthographic camera. A little better, but under rotation this still fails. Plus, this doesn't work in the scene view - which would mean art between scene view and game view doesn't match up. We hacked it into the scene view, but it still isn't stable under rotation. Artists rotate the camera all the time to get a better view so that's still not workable.

3. Use "Order in Layer" based on the actual Z position of the object to enforce some more order. Better, but if objects are on the same order, stuff still pops.

4. Add a random offset to that z position to force stuff to be in another order than a close neighbour. However... turns out order in layer is not actually an int, values only go from -32768 to 32767. Not nearly enough to give a precise enough range.

5. Use the sorting order on materials too. Turns out though you can only go up so high with those too before unity does weird stuff... Still not precise enough.

6. Use above, and additional sorting layers spanning ranges of z, with more precision in the center layer and..... you get the point, we shipped with an incredibly complex system JUST to keep tiles stabily sorted


Luckily, there's just three small things that need to be done:

1. Add a TransparencySortMode.ZAxis. Don't use distance to camera but just the actual z position of the object.

2. Apply this TransparencySortMode to the scene view. (Ideally you'd just pick the default sorting mode in the project and it sets it to all cameras)

3. When objects do still sort the same, they should be rendered based on some well defined order - probably based on transform order like the UI is.


Lastly, if the sortingOrder could be usable in it's full int range, that would be good too, but I imagine that's an optimization.

Hope that helps

TL;DR: 2D Sorting in unity only works for super simple cases, it's not stable, workarounds are hard. Fix is easy

 

+1 for sorting order to be a full Int.

In our game, we're using an puppet animation library called Spriter, to animate our characters, and it uses z-position to sort character pieces internally.

This means we need to rely on Sorting Order to actually sort our different units, and we're doing so based on their y-position on screen. In order to avoid z-fighting (when y values are tied) we need to incorporate a random offset in addition to the y-position, and once we do that we begin running out of precision values.

 

Great to hear unity will take a look at this! Thanks

@gskinner: Yeah we had that exact issue with our random offsets.
I do feel that ideally we don't have to mess around with sorting order at all. I'm guessing you're game is isometric? I think there was a prototype in the unity 2D alpha's doing isometric sorting. It was implemented by calculating a proper sorting order by iterating over all objects though Lots of performance and GC overhead in that prototype...

Ideally the camera sorting behaviour would be extended even further to allow for different types of 2D games (perhaps a TransparencySortMode.Standard2D, TransparencySortMode.Isometric2D etc. assuming in principle z-axis depth, y-axis as isometric depth etc.) but I wanted to keep the proposed changes simple.

 

Here's my situation with sprite sorting (Unity 5.3.0f4):
1) I am making a 2D game.
2) I have 3 different materials (shaders) on my sprites.
3) I need control over sort order (really anything would work).
4) Sort order simply does not work correctly. It seems to be sorting by material (which I would call a bug).

I have put all of my sprites into the same "Sorting Layer" (Default), and I use the sprite "Order in Layer" to sort them.

It appears that the renderer is sorting by MATERIAL (or shader) first, and THEN the "Sorting Layer" and "Order in Layer". So that means I cannot control the sort order for different materials.

Here's my example (in order back-to-front):
Head (order 1 material1)
Nose (order 2 material3)
Eye (order 3 material1)
Highlight (order 100 material2)

Note: I've named my materials in the order I created them which may be related to the order they are rendered.

I've got an instance of material3 sandwiched between a pair of material1, and material2 is a UI element that needs to render on top. If "Order in Layer" worked as advertised, this should work but it does not. Instead, I'm seeing this:
Head (order 1 material1)
Eye (order 3 material1)
Highlight (order 100 material2)
Nose (order 2 material3)

I have tried putting them on different "Sorting Layer" but that had no impact. I also tried messing with their z-depth, but that also had no impact.

So is this a known bug? Is there some work-around?

 

I want to echo PV Loon's request to allow for Z sorting based on Z-position instead of distance to the camera. That would solve a lot of problems elegantly.

 

So small update on this, I got an e-mail from some unity folks that they intend to fix this. They only mentioned making sorting order a full int though. After explaining again why this is only a small patch and we need z position sort (thanks Xelnath!), they added me on skype aaand.... never heard from them again! I hope they still have some time for this at some point

 

+1 for the topic
I make an isometric game and sorting is complicated with Unity

 

I'd just like to say that if there any sort of better sorting solution made for Z coordinates, please please make something similar for Y coordinates, and just do X while you're at it. Give the camera an option for sorting solutions. The Box2D implementation is XY only, and as such, there are XY Isometric games where Z is not closed to the camera, it's Y.

Other than that, better sorting would be awesome. You have no idea (well, many people probably have a very good idea) how frustrating it was to wrestle with the sorting and issues that accompany it at times.

 

Trying to build a 2d Sprite game using mecanim. Is this the same issue as the one I'm having where if you have two mecanim objects with multiple parts standing near overlap of each other, that various body parts and pieces from one enemy will overlap the neighboring enemy?

 

is this sorting problem now fixed in the unity 5.5 2d preview?

 

Excellent post I have been dealing with this issue in a 2d game I'm doing. Now I have a solution. Thanks

 

Has anyone tried out the Sorting Group Component in the 2D Experimental Preview? It would be great to get some feedback on it and if it solves some of your issues .

 

Hi Johannes

yeah I've tried the experimental 2D preview and while the sorting group is neat, it doesn't solve any of the issues mentioned here. Heck, in the demo for the sorting group, try rotating the camera (perspective) and you'll see the sorting flicker.... (almost all of the demos in the preview do FYI). Not a huge deal for a pure 2D game but for 2.5D games this is terrible to work with and we're back to the hacks mentioned above.

I hope the 2D preview can address the issues mentioned here and implement some of the suggestions. Just the Z-Axis based sort + scene view sorting like the main camera will help so much.

Generally I feel like users shouldn't have to mess with sorting layers & groups manually unless we really want absolute control, we just need a good default sorting. Sorting on Z axis & hierarchy order would definitely work for pure 2D games and for 95% of 2.5D games already.

If you want to do isometric too maybe you would want to sort on a custom axis but heck even there Z axis sorting would still be much better than this sortingOrder troubles

-Arthur

 

Hi Arthur,
Thanks for the reply.Yes the Sorting Group currently focuses on 2D mode Scene View.
We are working on a solution based on yours and other suggestions here but it was not ready to get into Preview.1.

Cheers
Joh

 

Awesome, great to hear! Curious to see what the team has come up with, will try it out once it's there thanks!

 

Any update to this?

Currently I use a system similar to OrderInLayer = Z position. With some division (math) to extend its limitations.

My camera is Perspective, with sprites billboarded.

However, some of my objects are very complex (many individual pieces that need to have specific order in layer, within the object itself.)

I was interested in trying Sorting Groups, but don't want to waste the time based on what the OP says.

Since every object (Characters, Plants, Trees) are multiple sprites, I need two things:

1. For each object (one parent gameobject) to sort all its sprites it has to a single layer, based on Z-Axis. (All body part sprite pieces that make up a single character object, will render infront/behind other objects based on Z-Axis, despite their order in layer among themselves).
2. For all children of that object, to be able to sort to any order in layer, while maintaining the above overall layer. (ex. I could have six arms, one behind another, with the sixth arm at (BaseLayer + 6), but all arms will still render behind a different character object that is 1 unit infront of their Z-Axis.

Do Sorting Groups solve this? It looks like it does in the little gif on the page, but it's hard to read even after watching it repeatedly. I'm trying to find a more thorough explanation or preview of this feature, but found this instead.

I thought this is exactly what Sorting Groups are for, but the OP's problem is strikingly similar to my own, minus the camera rotation issues. I do not rotate the camera, but it is a 3D world with 2D sprites, perspective camera, and setting OrderInLayer to Z-position is the only thing that has ever worked for me up until this point. And although it works, it is far from perfect when the character walks too close to another complex object.

 

Hi Carter,
Sorting Groups only work with Sorting Layer and OrderInLayer. If you are setting the OrderInLayer then it should work for you. If you need axis distance sorting, as the OP, we are currently working on a solution. Coming soon.

 

I just tried the new sorting group feature, it's great and works well, but i am having trouble to do something i already did on my project but manually and with lot of time
So there is a boss, a huge humanoid boss (with long legs, torso, arms ...), and my character needs to be able to run between his legs, so my character is always in front of the boss except against his right or left leg.

In the boss sorting group, i set "Default" as sorting layer, then i added a nested sorting group in his left leg and put "Front" as sorting layer, it works only locally (even if i set -9000 in sorting order it still appear in front of his body so it's great !) but the leg still appears behind my character.

I think nested sorting group with different sorting layer should be ignored and should manage their children themself

(apologize for my english)

 

Awesome! I can't wait for these updates
Thank you & all the 2D team for your hard work.

 

puppet 2D have a great script, sorting layer for mesh

 

Hi,
We just released the 2D Experimental Preview 2. One of the new experimental features in this release is the Axis Distance Sort.
http://forum.unity3d.com/threads/2d-experimental-preview-release-2.427253/

Hope you guys can check it out and give us some feedback on it.
Here's a short clip of how the feature can be used.

 

You. Are. Awesome!

Thank you!

 

Oh. My. Finally. Wow. Lovely. Can't wait to use it.

Thank you times a bajillion.

 

Hey - thanks 100 x bajillion. Custom axis sorting fixed my interaction between my 2d sprite characters and 3d transparent objects by setting my sorting order to 0 for all sprites, then using z depth to layer.

The default shaders then worked out the rest - including transparent objects.

Keep up the good work.

 

TransparencySorting only seems to only work well when you use sorting groups, is this intended? My game sorts on Y and things like trees (which are 6 units high) do not seem to work unless I put them in a group, even if I set the sprite layer and order to equal values to the player. The player is 2 units high and only moves behind the tree once he walks roughly 2 units up it if no group is used. Great feature though, will start implementing it soon!

 

I'm having the same issue in Unity 5.6 as OtakuD. It seems the sorting position is based on the center of the object and not the pivot. Any way to work around this? I tried parenting it to an empty game object but it didn't help, same issue. Please help!

 

PS I'm referring to the new Axis Sorting Distance Feature. I set my camera settings in the Graphics setting to Transparency mode X:0, Y:1, Z:1

 

I'm really excited to get this sorting problem sorted out (loooolz)

 

I really like this feature as I thought I would have to implement my own solution to this problem.

But I have a suggestion that I would really appreciate if you could take it into account.

Is it possible to get the reference to when it "swaps" between visibilities based on the sprite's custom pivot instead the center of the sprite? E.g. if you have a tree and you want to swap a character's sprite when he passes the trunk, instead walking through the crown.

 

I think we are all eagerly awaiting guidance/ a fix here

 

Silly me, I didnt read all the other posts as I didn't think other people would have the same problem :S. In fact I read till OtakuD posted the same thing, even with a tree.

Sorry for duplicating the issue

 

No it's cool! Good to know I'm not the only one

 

This would be amazing if only it could use the sprite pivot rather than the center of the sprite!

In our isometric game using 2D sprites we rotate the sprites to face the camera, so using the custom z-axis sorting results in tall sprites often incorrectly appearing behind shorter ones.

e.g.


results in:

 

What it's not for sprite pivot or no option for it? Make it happen!!

 

I also just realized that the sorting is not based on the sprite's pivot. It's based on the sprite's center, which doesn't work for top-down 2D games with objects that are not all the same size.

As it stands, a 2h x 1w tile rectangle cannot properly be sorted with any object that is not 2 tiles tall.

 

Yes it is currently based on the Sprite's center. We are currently looking into making it work in other ways.

 

This is good to know. Please keep us updated on this.

There is actually no way of making this implementation of 2D sorting work with a top-down game in which a character can be "behind" and "in front" of objects, like in Hyper Light Drifter, Stardew Valley, etc. It only works when the objects are the same height.

I think that it should also work with individually-sorted tiles in the tilemap.

 

Hello there.

I was wondering if there is now a way to sort sprites using a pivot or if it is still in development.

 

@RhenaudTheLukark It still in development.

 

Okay, thanks for the answer. I hope it'll be ready soon!

 

Correct me if im wrong, but wouldnt this work with pivots if you just made the parent hold the entity's transform data (with a size of 1)

-EmptyGameObjectParent (Sorting Group - No spriterenderer.)
--ChildSprite
---ChildOfChildSprite_Piece1, 2, 3, etc

The parent is the pivot point. It having no size means its center is also the bottom, top, etc.

This way all sprites in the parent gameobject have a sorting order based on a spriteless parent's z-axis.

Regardless of sprite height/size.

This is also the only way I have found to make very specific pivot points regardless of the sprite itself. Even multiple pivots for animation (multiple parents).

-MasterParent (w/ Animator)
-Pivot1
--Pivot2
---Sprites

I have very complex objects with this type of hierarchy. For example a tree with ten individual branches & leaves, independently animated, all sharing the same bottom pivot & sorting order based on z axis of pivot.

 

@RhenaudTheLukark @AssembledVS @Yukichu @apatton @nosajtevol @Leucaruth @OtakuD


ALL gameobjects have to have a parent pivot, preferably with a sorting group. (I get weird pivot points when not using a sorting group).

Here is a test. Custom Axis Z = 1.

The stick figure's pivot points are always the red dot on them. (Central of sprite for no pivot parent. Bottom for pivot parent.)

LeftExample

Spoiler

shows pivot parents, but without a sorting group. For some weird reason, it has the pivot at Z = 30, rather than Z = 1. No idea why. Weird offset.

RightExample

Spoiler

has pivot parents AND sorting groups on all objects. (Only tree is required for sorting group, but in my game I have all gameobjects have both a pivot parent & sorting group). It is perfect. The tree's pivot is exactly at the black circle.

The CentralExample

Spoiler

has no pivot parents. The center of the tree sprite & center of the stick figure are where it determines if the sprite should be front/behind.

So you want to do this hierarchy:

-PivotParent (Gameobject with no Sprite; Preferably with a SortingGroup)
--Sprites





So you can move the pivot anywhere you want. Custom pivots which obey by the Sorting Order mode you set.

 

That's pretty neat, thanks a lot for that solution!

I'll use that while this system won't be ready. It adds an useless GameObject for each object, but it'll do for now!

 

The way I structure my gameobjects turns it from a useless parent to a vital component in all my gameobject structure.

• Root Parent GameObject (Most Scripts, Sorting Group, Transform Position, All Data (ex. Multiplayer, PlayerStats)
  • Graphics Game Object (SpriteRenderer, Colliders, Tag/Layer settings, Animator, & Graphic-based Scripts
    • Child SpriteRenderers
  • Misc. Game Objects (See Any Below)
  • Camera Game Object (If player or a special scene)
  • GUI Game Object (Canvas & GUI attached)
  • Additional Transform Positions (ex. a second spawn point for the object, for dropping items in a special way)
  • Debugger GameObject (Holds Debugger Scripts)

I do this for very particular reasons: Readability/Accessibility & Organization. I have a total separation of Simulation (Data) & Game Engine (Rendering/Input).

The best part is that it is organized in a way I can easily read & access quickly. I don't have to sift through scripts to find the ones which deal with art & rendering (Layer Order logic, Animation system, mouse hightlight effects, etc.). For example, if my gameobjects would benefit from it, I would create a child "Multiplayer Game Object" so I can more quickly access multiplayer-specific scripts / inspector settings. Then I just reference that gameobject when I need it.

I treat it like a folder system. The GameObject is a folder, while the Components attached are the flies. It feels like the Root Parent is the brain, while the graphics object is the body. I wouldn't want to do it any other way.

For other cases, such as the "Debugger GameObject", it is also so I can simply delete/disable that gameobject, without it changing any other part. So rather than clicking to disable 4 vaguely named scripts scattered in the inspector, I just disable 1 very obvious gameobject. I try to keep each gameobject as its own separate, independent component.

My entire game is separated into C# Code/Data and Unity/Rendering. So technically, the game works without Unity - there is just nothing to display. (Although that becomes less true the more reliant the data is on UnityEditor/Assets).

This helps greatly through. Especially for multiplayer & save/load. The main benefit is that all data sent across the network or saved through serialization to file, just deals with only the scripts on the root object. It never has to touch Unity (the Graphics Game Object). All Graphics/ (animations, sprites, meshes) are entirely separate, so they can be removed/edited without effecting the actual game because all graphic scripts are tied to the graphics gameobject. I could delete all graphics from the game, and it will still run flawlessly (just without any art). I used to have the Collision GameObject, but my game doesn't do much Physics, so I merged it with the Graphics GameObject because it made sense.

Idk if this is helpful for others, but it really has helped me tremendously deal with all of my gameobjects. My game is a bit complex though. Some of my gameobjects have a lot of components & pieces.

 

This post and the one following it is interesting.

How would you get this method to work with Tilemap tiles, though? I see that as the biggest issue, as game objects like the player, enemies, and NPCs can be sorted in a number of ways, including with a dynamic sorting script (which was the norm before this "automatic" sorting was recently introduced).

 

Is there any way currently to sort WorldSpace Canvas objects along with the parent SortingGroup? I have several Sprite objects which have persistent UI elements following them about, and the UI needs to sort along with the Sprites.

If this isn't possible, then my feedback would be to provide a way to sort anything with a SortingLayer field using the SortingGroup, UI included.

 

Hi, is there an update regarding the pivot point. i've just tried to use this in unity 2017.3 and found its not accounting for the pivot and seems to be based on the centre of the image.

 

As CarterG81 pointed out, the way to have sprites sort properly right now is to have a root game object with a sorting group component and your sprite to be a child. It will then sort by pivot. I think that they're working on an alternative method but this seems to work now.

 

I just ran into this problem, apparently this is still based on the center of the image in 2017.4.5.

When are we gonna have the option to sort by pivot? Is this being worked on?