Renderer.sortingOrder maxes out around 32000?

I have a custom isometric tilemap system created with 2D Unity. It uses the renderer.sortingOrder to ensure building sprites are drawn ontop of each other correctly depending on their tilemap position. This is very important to ensure the perspective looks correct. In general this works well.

However, it seems that if you set the renderer.sortingOrder to 32768 or greater then it changes it to a negative value and the sprite disappears from view. The Unity documentation says this value is an int but I guess it has a really low upper limit? How can I work around this? Why is the limit so low?

 

Sounds a bit overkill - you could sort them without this by using CameraSortMode and offsetting the mesh origin point instead which gives you unlimited variation (although it's a hack as well).

Why not use the minus range as well, or is there a problem with this?

I'd imagine the reason it's that number is because its a signed short int (65536). I guess an int might be possible, see what Unity has to say about it.

 

I tried using the negative values too, but I can't get any negative sortingOrder sprite to be rendered. Perhaps I am doing something wrong but that is what I've found so far. I will investigate offsetting the mesh z order and putting the camera really far back. This seems hacky but it might be my only option if I want a tilemap that has any real size. Thanks

 

Just ran into the same issue... at the very least this should be documented

 

It is indeed internally signed 16-bit value. As of writing this the negative values also work. Not sure if that was the case in 2013 when this thread started. The bottom line is that sortingOrder was not designed to solve cases like 64k+ objects.

I will make sure that this gets documented.

The best workaround is what hippocoder suggest: The combination of CameraSortMode, z-value and depth buffer.