Firemonkey semi-transparent Image3D is sometimes opaque

Question

I create a FireMonkey app with 3 semi-transparent tImage3D's. Here's the code and the screen. All seems well.

procedure TForm1.Form3DCreate(Sender: TObject);

// create a new semi-transparent timage3d
// object with color and Z position.
procedure NewImage ( const nColor : tColor;
                     const nZ     : integer );
begin
  // create the image
  with tImage3D . Create ( self ) do
    begin
      // put it on the screen
      Parent := self;
      // set the size
      Width := 10;
      Height := 10;
      // set the image to a single pixel.
      Bitmap . Width := 1;
      Bitmap . Height := 1;
      // set the Alpha to $80 to make it
      // semi-transparent
      Bitmap . Pixels [ 0, 0 ] := $80000000 + nColor;
      // set the z position
      Position . Z := nZ;
    end;
end;

begin
  NewImage ( claRed,   +10 );
  NewImage ( claGreen,   0 );
  NewImage ( claBlue,  -10 );
end;

Now reverse the order. Now they are opaque.

begin
  NewImage ( claRed,   -10 );
  NewImage ( claGreen,   0 );
  NewImage ( claBlue,  +10 );
end;

What am I missing?

Answer 1

FireMonkey (as of now) doesn’t support rendering semi-transparent objects in 3D.

FireMonkey only supports blending of semi-transparent objects (either through the Opacity property or because of their texture, for instance a semi-transparent PNG image), but blending alone is not enough to get it right in 3D with a Z-Buffer (which is what FMX, and most 3D apps are using).

For a technical explanation, you can read about Transparency sorting, the article is about OpenGL, but applies to DirectX too.

So to get correct rendering, you need to have your semi-transparent objects sorted back-to-front from the camera's point of view.

You can get more details and some code in this post to work-around the issue:

Rendering semi-transparent object in FireMonkey

but keep in mind it'll just be a workaround.

Ideally this should be handled by the FireMonkey scene-graph, as it is rendering-dependent, otherwise, you end up having to change the scene-graph structure, which can have various other side-effects, and is even more problematic if you have more than one camera looking at the same scene.

Also, the sorting approach will only work with convex objects that don’t intersect, and for which you don’t have triple-overlap, as in:

For which there exists no correct sorting (none of the elements is in front of the others).