JDK-8091693 : Would like API to help with depth sorting for transparent (blended) objects
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: fx2.0
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2011-07-22
  • Updated: 2018-09-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8170852 - Order-independent transparency for 3D objects
Relates :  
JDK-8090548 - 3D: Support blending when diffuse component has alpha (transparency)
Description
Run the attached app. It creates image with transparent areas. Then it creates 3D scene with two intersecting ImageViews on it. One part of image is rendered so that it assumes scene background in non-opaque pixels.
Comments
Not part of the FX 8 PRD, consider for future release
27-10-2012
We can discuss this in more detail later. The short answer is that it is too expensive (and in some cases may not be possible) to just "do the right thing", so we will need an API to enable depth sorting for transparency as well as to control what kind of depth sorting is done.
24-08-2011
I don't understand what kind of API is needed.
24-08-2011
There are multiple issues, so we will likely end up filing a few different JIRA issues and closing this one, but it can be a placeholder for now.
24-08-2011
Reopening as Feature
24-08-2011
So it looks like for the new feature we have to request Z-buffering to occur not only to whole objects but for their parts and individual pixels. Is my understanding correct?
22-08-2011
I can also change their order to get this picture.
22-08-2011
From this screenshot you can clearly see that translucent pixels are rendered correctly for blue circle and rendered over white background for red circle.
22-08-2011
My understanding is that the problem is due to the fact that these objects are crossing, so from the camera one part of first object is behind the second one and it is vice versa for the second parts of both object. And Z-ordering is done for whole objects, not for their parts. Is that true? I've modified the testcase to illustrate that.
22-08-2011
We could provide future API to do transparency sorting. The Z-buffer fighting issue is a slightly different problem, and would require cooperation from the application in some cases (although the simpler cases could be possible just a mode to enable it). In any case, we should file a new Feature request (since reopening this issue isn't quite right). I don't know whether we can target it for Lombard, but we should consider it.
24-07-2011
Can this be considered to be resolved in future? I believe it is possible.
24-07-2011
This is not a bug, but is rather an inherent limitation of mixing transparency (or other uses of blending) with depth testing. The basic problem, which you will see if you make the second primitive be farther away in Z than the first, is that blending requires rendering the primitives in back to front order so that the pixels to be blended against are already in the frame buffer when you render them. The attached test program shows a slightly different issue known as "Z-buffer fighting" which happens when you render two coplanar polygons. Some pixels from the first polygon will appear in front of the second while other pixels in the first polygon will appear behind the second.
23-07-2011
I've just updated the testcase
22-07-2011
You're right, you need prism.depthtest=true
22-07-2011
The test program as written shows no problems. This is likely because depthTest is not yet working for renderToImage (see RT-13911). If I force depth testing with the "soon-to-be-removed" prism.depthtest=true flag, then I see the artifacts, but they appear to be caused by the inherent limitation of using depth testing for transparent primitives.
22-07-2011
This issue limits the ImageView applicability for 3D.
22-07-2011