transparent Image3D is sometimes opaque
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?
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).
As you already discovered you have to draw transparent objects from back to front.
When drawing a transparent object, the object is drawn, and blended with the pixels that are behind it.
So this happens when you draw from back to front:
You draw the red image, it is blended with the white background. You can tell by the "pink" instead of pure red colour that it is blended with the white background. Then you draw the green image, it is blended with the already drawn white background and red image. Finally you draw the blue image, which is blended with the already drawn objects.
But now we draw from front to back:
We draw the red plane first. It is blended with the white background which you can see because it is pink instead of red. Now we draw the green plane. It is blended with the white background, you can tell by the colour, it is not pure, deep, green. But, the renderer sees that a part falls behind the red plane, so it doesn't draw that part. But, you think: the red plane is transparent, the renderer should draw behind that red plane! Well no, the renderer only keeps track of the depth / z-order of the pixels in the z-buffer / depth-buffer, it doesn't know if that pixel is transparent or not. The same story goes for the blue plane, only the part that is not obscured by other objects is drawn.
What is this depth buffer you speak of?
In the depth-buffer the depth of every pixel is stored. When you draw a pixel at 2,2 with az of 1, the depth-buffer at 2,2 is updated with the value 1. Now when you draw a line from 1,2 to 3,2 with az of 3, the renderer will only draw the pixels where the depth-buffer has a value of >= 3. So pixel 1,2 is drawn (and the depth-buffer at 1,2 set to 3). Pixel 2,2 is not drawn, because the depth-buffer indicates that that pixel is already drawn with a lesser depth (1 vs 3). Pixel 3,2 is drawn and the depth-buffer at 3,2 is set to 3.
So the depth-buffer is used to keep track of the z-order of every pixel to prevent overwriting that pixel with a pixel that is farther away.
If you want to draw transparent objects the right way, see this answer.
Excerpt from that answer:
I don't know if FireMonkey supports disabling depth-buffer writes, you have to find out yourself.
链接地址: http://www.djcxy.com/p/56760.html下一篇: 透明Image3D有时是不透明的