Resolve alpha depth issues automatically

[ngokevin]

Issue by jcarpenter
Friday Nov 20, 2015 at 23:32 GMT
Originally opened as https://github.com/aframevr/aframe-core/issues/498

---

It will be common to superimpose images w/ alpha channels. There is a currently a footgun where order of declaration in the DOM must be carefully managed, or transparent elements will cull each other.

For example, in the AnimeUI test scene in A-Frame, I have a series of transparent images arranged on the z-axis. I must declare them in order of depth, furthest from camera to closest, or I get blending problems.

<vr-image src="images/schematic1.png" width="7" height="7" position="0 0 -6"></vr-image>
<vr-image src="images/ring2.png" width="3" height="3" position="0 0 -2"></vr-image>
<vr-image src="images/ring1.png" width="0.5" height="0.5" position="0 0 0"></vr-image>

This is what it looks like when the user takes the correct steps:

This is problematic because:

• The failure state is obvious and ugly
• The cause will not be obvious to users
• The resolution is sometimes not feasible. The point of A-Frame is grouping elements to fit your scene layout and mental model. The current resolution forces you to group things by z-axis.

We should solve this automatically for users.

[ngokevin]

Comment by jcarpenter
Friday Nov 20, 2015 at 23:34 GMT

---

I believe Jaume refers to this issue in a recent tweet re: OIT (order independent transparency):

https://twitter.com/mrdoob/status/667835175108112384

Paging @caseyyee who's dealt with this before. Perhaps @fernandojsg also has some suggestions.

[ngokevin]

Comment by caseyyee
Saturday Nov 21, 2015 at 00:19 GMT

---

I've had to fiddle with a bunch of different properties in the past. I really don't fully understand how each one works under the hood, but if re-arranging the order in which objects are added to the scene doesn't work, i've used some of these properties in different combinations to get things working:

Mesh.renderOrder
Controls the order in which objects are rendered.

Material.depthTest=false
Whether to have depth test enabled when rendering this material. Default is true.

Here's a good fiddle I found that demonstrates the combo:
http://jsfiddle.net/sg02e5sm/2/

Material.alphaTest
Sometimes the alpha on the texture itself is problematic. Adjusting this value can make it work properly. It does clip data sometimes though if you are not careful.

Renderer.sortObjects
Defines whether the renderer should sort objects. Default is true.

Each of these have different impacts on perf as well (especially forcing sort order).

As per @jcarpenter, The user shouldn't have to deal with any of this. I think we could probably be intelligent with how objects are sorted in the scene to make it work for most people.

[ngokevin]

Comment by jcarpenter
Saturday Nov 21, 2015 at 02:18 GMT

---

More from Doob: https://twitter.com/mrdoob/status/667850994068422656

I fear OIT cant be easily solved by mere mortals like us in the application layer. GPUs should solve that for us...

[ngokevin]

Comment by jcarpenter
Saturday Nov 21, 2015 at 02:18 GMT

---

Adding @kearwood to thread also...

[ngokevin]

Comment by fernandojsg
Saturday Nov 21, 2015 at 09:57 GMT

---

Yes as mrdoob says it's not an easy problem and there're a lot of papers about how to do a real OIT.
@caseyyee pointed some properties that can be use for simple scenes and mainly for billboards as the one used on particles that they're just simple planes.
The problem is when the objects intersect between them, just as simple as like two boxes colliding. If two boxes intersect each other you can't fix it by change the rendering order, in that case you should split the faces and do a sorting for faces not objects. In this case the sorting is a huge bottleneck.
One step further is when some faces intersect each other in this case, the most general one, you need to sort by fragments not just even by faces, so the result is a huge performance problem.
So as mrdoob pointed the only easy solution could be that the GPU would take care of that for the most general case, meanwhile I believe we could just rely on this kind of tricks and simple properties to finetune our scene 😞

[ngokevin]

Comment by jcarpenter
Thursday Nov 26, 2015 at 04:06 GMT

---

Just spent 20 minutes trying to figure out why animating opacity on a foreground element was making all other images in the scene disappear. It’s because they were further away in z-space, and I forgot to take into account this issue. I definitely foresee some huge user confusion on this one...

[ngokevin]

Comment by jcarpenter
Sunday Nov 29, 2015 at 22:28 GMT

---

Sent email to Games mailing list about this...

[kennardconsulting]

Test case for 0.5.0:

The yellow square with opacity: 1 works fine. The yellow square with partial opacity does not appear unless the DOM elements are re-ordered:

<html>
<head>
	<script src="aframe-v0.5.0.min.js"></script>
</head>
<body style="background-color: black">
	<a-scene>
		<a-plane material="color: red; opacity: 0.5" position="0 1 -2"></a-plane>
		<a-plane material="color: yellow;" position="-0.6 1.6 -2.1"></a-plane>
		<a-plane material="color: yellow; opacity: 0.5" position="0.6 1.6 -2.1"></a-plane>
		<!-- Move red plane here and it works -->
	</a-scene>
</body>
</html>

[MagicIndustries]

I have an issue where a fadeIn / fadeOut of a simple plane in front of the camera is making other elements with transparency disappear. Is this the same issue?

I'm adding the fade plane dynamically, so should I be trying to add it to the top or the bottom of the DOM to try to beat this?

I should note the fade plane ends up being a child of the camera currently.

And since this is something I'm working on at work, if there's anything I can do to help move the final solution forward just let me know. I have no idea where this would start though :)

[ngokevin]

material="alphaTest: 0.5" seems to magically help in most cases.

[jfaust]

Is there a reason that the standard solution to this (sorting transparent objects based on distance to the camera), is actively disabled by AFrame? Admittedly it doesn't always work but in most situations it works way better than manually controlling the render order. Especially in head-tracked VR, where the user's head can be anywhere.

At least having the option to turn it on would be great.

I'm referring specifically to a-scene.js:486

renderer.sortObjects = false;

[ngokevin]

I'm not sure why that's disabled. @dmarcos, aware of any history?

[dmarcos]

As far as I remember it was disabled to favor manual control. We can revisit. I have not dealt much with transparent objects so no familliar with all the problematic of automatic sorting.