What should happen when applying opacity less than 1 to a node with descendants?

[trusktr]

Hello Adrian, Rikard, and contributors,

I'd like your opinion:

If we have a node in a 3D scene, and it has many descendants (a sub tree), what should happen when we apply opacity with a value less than 1 to it?

1. It, and all of it's children should become transparent, multiplying opacities down the scene graph.
2. It's content should become transparent but not that of its descendants.
3. Same as (1), but the whole object should be flattened into a plane.

The reason I want your opinion is because the new specs for CSS 3D (css-transforms) state here that the answer is (3).

To see what I mean, view these two examples in Chrome 53 or higher:

• https://jsfiddle.net/trusktr/ymonmo70/16
• https://jsfiddle.net/trusktr/ymonmo70/17

The second example has opacity applied to the node that contains all the sub-nodes which compose the car. The opacity, according to spec, flattens the car into a plane (turns it into paper!).

I'm asking various 3D engine authors for opinions of what the correct or most expected behavior should be.

All the best,
~ Joe

[schteppe]

Hello,

Goo Engine is not a scene graph, but rather an entity component system. Only a few properties of entities are inherited through the graph, such as transform and hidden-ness.
If you're making an old school scene graph, like OSG, then I believe the opacity should be inherited and multiplied. However, I'm not a CSS3D expert so I cannot say what should be done there. Flattening the elements because of opacity sounds like a bug to me...

Stefan

[trusktr]

TLDR, some engines (like Three.js) like to have opacity apply locally and not propagate to children. Others (you mention OSG is like this?) like for opacity to be inherited.

I don't think either of Three.js or OSG like for objects to be flattened, which is the opinion I'm looking for. Do you agree with that?

Goo docs say:

And last but not least TransformComponent is the component you will use to link entities together to form a scene graph:

entity.transformComponent.attachChild(entity2.transformComponent);

So, in essence that is the scene graph, just that each node in the graph is limited to transforms. Hidden-ness is limited to the entity, right? This is much more desirable than CSS3D's flattening of a whole scene-graph sub-tree when opacity is applied to a root element of that sub-tree.

[schteppe]

Yes, in OSG the properties of a node are accumulated from the parents. If a property is set in a node, it will override any parent property with the same name. Similar to CSS, I guess. Read more here: http://trac.openscenegraph.org/projects/osg//wiki/Support/Tutorials/StateSets

Looking through the OSG tutorials, I'm not sure if opacity will multiply or just override the parent value. Needs some more research :)

If you want an object to be flattened in any 3D game engine, you would explicitly have to set the scale of the mesh (or any of its parents) to a small value along one of the axes. Setting opacity/alpha will not affect the transform at all. From a game developer perspective, this is expected.

However, CSS3D is not a game engine. I'm pretty sure there's a good reason for flattening. Would be interesting to hear the discussion behind this!

[trusktr]

If you want an object to be flattened in any 3D game engine, you would explicitly have to set the scale of the mesh (or any of its parents) to a small value along one of the axes. Setting opacity/alpha will not affect the transform at all. From a game developer perspective, this is expected.

Thanks for the input Stefan!

However, CSS3D is not a game engine. I'm pretty sure there's a good reason for flattening. Would be interesting to hear the discussion behind this!

If you're curious about the discussion, there's the archives here: https://lists.w3.org/Archives/Public/public-fx/2016JulSep (any topics that have my signature /#!/JoePea in the replies, or view by day, look for "CSS3D").

To sum it up, they say "opacity is a grouping property" (i.e. all children on the same 2D plane are a group), and therefore that means that it must flatten its children in order to apply opacity to the plane as a whole, as if the applying opacity to a texture on a plane. Basically, the children are flattened onto the plane and become part of the plane's final texture, after which opacity is applied.

Essentially, the answer, the way I interpret it, is "because ancient 2D APIs were designed and implemented like that, and we are carrying those 2D implementations into the 3D realm". The reason I interpret it like that is because when they flatten the 3D elements onto the 2D plane, then they can leverage the existing 2D implementation, instead of having to implement the 3D behavior (which the major browsers all do already, and which Chrome 53 was doing before following this spec, although none of them did it in a spec'd way).

My reply to that is: Treat 3D differently -- make opacity (and properties that interact with background) not entirely grouping in the 3D case, so that 3D children are not flattened back onto the plane they originate from (for example, in my flattening example I linked above, the vertices of the car's planes are flattened onto the parent plane of the red box), and so grouping applies only to 2D elements that remain on the parent's 2D plane (i.e. not popped out into 3D space). This will make it work in a way that is backwards-compatible with the ancient 2D web APIs.