Why are overlapping transparent materials painted in wrong order?

I have 2 planes stacked over each other with an offset, both have a standard material assigned which is set to rendering mode “Transparent” and a color, no other changes to the material.

6159769--673438--m1.png
6159769--673441--m2.png

Blue plane is on top, red plane is on bottom.

The problem: depending on the camera perspective the bottom plane overlaps the top plane. Here’s editor view and game view with different camera perspectives:


Why does the red plane seem to overlap the blue one and how can i fix that?

Above was Standard, just tried HDRP. Problem is there as well :frowning:

This is working as expected. Fast, efficient, and correct real time transparency sorting is an unsolved problem. There’s just no good way to do per pixel transparency sorting. With real time raytracing becoming a viable option, it’s possible this will be finally solved in the near future (next 5 years), it’s still a problem for now.

So instead for real time rendering we have to approximate it. Generally this is done by sorting on a per mesh level. Objects are sorted by the CPU before rendering. By default for perspective cameras transparent objects are sorted by their spherical bounds distance from the camera. For something like two planes, it might seem weird that they don’t sort correctly because the correct order is so obvious to us, but it’s not as easy as it looks. Especially since as soon as two planes intersect there is no solution. And unfortunately planes are one of the places where the approximation is most obviously wrong. It’s just not the common case it’s trying to solve. Most of the time when you have simple planes or quads you want to sort, they’re particle systems, which have a custom sorting system, or sprites which are usually used with explicit sorting or an orthographic camera which sorts purely by depth.

One fix for this is to manually sort your meshes, either using the render queue on the materials, or using the renderer component’s sorting order, which while not exposed on mesh renderers inspectors, is accessible via script. If your plane surfaces are always going to aligned like this, you can sort them just by the “up” axis. If they’re not, well, you can look up polygon sorting algorithms on your own…

2 Likes

Out of curiousity, are the planes on the same layer, or is each one on a different layer?

All the same layer. I did some research and found at least 5 different approaches to this, none of them is a 100% solution.

Thanks @bgolus I found the sorting order in hdrp being exposed, didn’t know about it being exposed via script otherwise. Good hint.

Although from what I read the disadvantage is that each new order is a new render layer and hence a render pass and hence costs performance, at least from what i read on the internet. Not sure if that’s correct though.

HDRP’s Sorting Priority is similar to the built in renderer’s Sorting Order, however the HDRP’s range for that is -100 to 100, where the built in rendering paths it is -32768 to 32767. There’s no real extra cost with using either of these, as they just affect the order the sorting that Unity already does returns. You’re always paying the “cost” of that feature regardless of if you use it or not since the sorting algorithm is already checking it. Layers are a separate concept of which there are several different things with that name. Those also general don’t come with any extra cost to use, though light layers may.

1 Like