Draw order is messed up when using Perspective Camera

[Svampson]

So in the game I'm working on the characters consists of two parts (head and body) and when I'm using perspective camera the head (which is slightly behind the body) starts drawing in front of the body depending on the distance from the camera.
Is there a way to solve this or is it an inherent flaw with Unity? I would really prefer using the perspective camera (Since it looks way better when using 3D environments)

[unikronsoftware]

There are a few solutions to this, some of them better than others. I am working on one which will solve this problem pretty much permanently, without any additional draw calls.

If you're using perspective cameras, one sure fire way of fixing it is to use two separate materials for the head and the body (with two separate renderqueue values). This does work, and with the latest 1.70 beta, you can actually set up multiple materials from within the interface making it really easy to implement.

If you don't really animate these sprites a lot (i.e. using sprite animation, not moving them about), and draw call overhead is a concern, you can simply use a solid shader, and draw the pixel outline in the sprite editor (again in 1.70 beta 2). This means there will be more triangles per sprite, but sorting errors never happen with solid objects. Animating sprites using this technique means allocations when the sprite is switched, but this may not be a problem in your project and may work out better. (Again, another balancing act)

Another approach is to use 2 cameras, one perspective for all your 3d stuff, and another 2D one without clearing z, positioning the objects at the correct z depth and scaling them correctly. This is actually much easier to work out than it sounds, and you get perfect sorting, every time.

Ultimately, this really depends very much on your game and how you need things to interact on there.

If you'd like to discuss your needs in more detail, feel free to email support at unikronsoftware dot com, and I can perhaps offer some more suggestions once I understand your requirements.

[Svampson]

I've thought about giving them different render queue values, but that would probably result in some oddness when two characters overlap slightly

And they are pretty reliant on animating so the second option probably wouldn't work

The 2 camera solution sounds interesting, but would it work in cases where the 3D geometry overlaps the characters? And if it would then I would appreciate if you could elaborate

Oh, any ETA on your permanent solution? I'm not in a real hurry or anything just wondering


A screenshot to show the perspective I'm going for.

[unikronsoftware]

I'll try to create a Sample scene for this.

[unikronsoftware]

I tried the 2 camera system and it looks like it is possible. So basically the concept is you create a second ortho camera, set it to display just one layer, and set the sprites to this layer. After that, you work out where the sprite would be in the second camera (its easier if you simply have other proxy objects in the game viewport for debugging, but these objects aren't visible in any other view).

You can do this by simply transforming your object position into screen space on the 3d camera, and then doing the inverse to work out where it would need to be in the 2D Camera. You can do the same with sizes (ultimately these will just be ratios of distance from camera, fov, etc. which can be simplified to be very efficient). The tricky part is to work out where the objects w coordinate would be in the perspective camera, as the z position in the ortho camera would need to be the correct z/w value to intersect correctly with occluding 3d geometry.

I'm gonna investigate this a bit further to see if it can be done by tricking Unity into believing its one thing but doing something completely different, and making a lot of the work automatic.

Thing is, I won't be able to spend the time I need on this until version 1.70 final is ready and out of the way.

The other thing I was planning would also solve this quite efficiently, its basically like the static sprite batcher, but dynamic, automatically creating a skinned object out of the parts you set up. You'd then be able to move these parts independently, and they are sorted in local Z before the mesh is updated.

What you want to do really depends on your timescale.

[Svampson]

Thanks for your help!

I'm probably gonna wait until I'm almost ready to release (which should take a couple of months) before I start messing around with that, and if I'm lucky the dynamic sprite batcher/something similiar will be ready by then so I can use that

[adiron]

There are a few solutions to this, some of them better than others. I am working on one which will solve this problem pretty much permanently, without any additional draw calls.

If you're using perspective cameras, one sure fire way of fixing it is to use two separate materials for the head and the body (with two separate renderqueue values). This does work, and with the latest 1.70 beta, you can actually set up multiple materials from within the interface making it really easy to implement.

Hi. I'm new to this whole thing. Basically, what I need to do is to create another atlas for every layer if I want one? (and change the renderqueue)

Edit: How would I go about setting a different renderQueue for each one and all that? This is getting quite complicated.

[unikronsoftware]

With more recent version of Unity (3.5.6, 4.x), set
camera.transparencySortMode = TransparencySortMode.Orthographic;
on your perspective camera.

There shouldn't be any sorting issues when used in this way.

[adiron]

That was quick. Yes, it works! Thank you.