I'm sure there's an explanation for this, but I'm having trouble imagining what it is.

cubes-simple.pd

This patch is drawing first a green cube with low opacity (90% transparent), and then drawing a red cube with high opacity (10% transparent). I would have expected the more-opaque red color to dominate -- you would see mostly the red cube, with faint bits of green sticking out in places.

Instead, we see through the green transparent parts all the way to the black background, and the red is visible only outside those bounds.

Am I right in thinking this is really weird?

Let's say in the real world you have a large green glass cube, empty in the middle, mostly transparent, and you put a small opaque red cube inside it. The red cube will block the background. But in this patch, if you do the same thing by reducing the red cube's size to, say, 0.1, then the red cube disappears!

By contrast, if you reverse the transparency (opaque green, transparent red), then you get an expected result.

[alpha]'s help file does mention that opaque elements should be drawn before transparent ones, but that would seem to require some fancy tap dancing if the objects' alpha values will change -- in this patch, I would have to flip the positions of the two drawling chains depending on the value of the top-right toggle. I guess the easiest way would be with separate [gemhead]s and switch their rendering order?

I still think it's weird.

hjh

Update: Apparently this is standard in 3D graphics frameworks -- https://www.khronos.org/opengl/wiki/Transparency_Sorting -- "In order to achieve translucency, all opaque objects must be drawn before drawing any translucent ones."

In Pd, this means [t a a] with varying degrees of translucency underneath may not work (unless translucency is always constant), because, if two shapes switch translucency priority, there's no way in [t a a...] to change their order.

So I file it under "unanticipated fine print," with a solution.

hjh