JDK-8097241 : [3D] Texture with transparency rendered blocky on the tilted sides of the 3d shape
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u40
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-04-22
  • Updated: 2015-06-12
  • Resolved: 2015-05-01
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.
JDK 8
8u60Fixed
Related Reports
Relates :  
JDK-8095058 - [3D] Texture transparency is ignored in 8u40
Relates :  
JDK-8098226 - Implement auto-mipmap support
Relates :  
JDK-8090891 - Support for NON_PRE alpha
Relates :  
JDK-8090548 - 3D: Support blending when diffuse component has alpha (transparency)
Description
This bug was discovered while fixing RT-40004. I have identified that this regression was introduced by the work done to support auto-mipmapping (RT-26108). Please see attached images to compare the rendering difference before and after auto-mipmap support.
Comments
Changeset: 573e7b7a50bf Author: Chien Yang <chien.yang@oracle.com> Date: 2015-05-01 09:43 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/573e7b7a50bf Changeset: b6287603720b Author: Chien Yang <chien.yang@oracle.com> Date: 2015-05-01 09:45 -0700 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/b6287603720b
01-05-2015
+1 with one comment to note for later We will need to re-examine the blending equation used for 3D when we implement blending in 9, since the currently used equation, which matches 2D, assumes that we are using premultiplied alpha. When we add proper blending support we will also want to implement RT-17494 to allow for textures with non-premultiplied alpha. In such cases the blend equation that implements SRC_OVER changes from (1,1-alpha) to (alpha,1-alpha). I will add this comment to RT-28874.
01-05-2015
Reversing the order of the cubes will break the effect. This is the same issue we face with overlapping 3D transformed 2D shapes if the rendering order is not setup correctly. We may need to explore the possibility of providing a sorted rendering order in 9.
23-04-2015
I'm not familiar with the ramifications of using that blending from one 3D scene to another, but the changes look valid in isolation. Is the cube of X's rendered after the big red cube? If you reverse the ordering do you then end up with parts of the red cube carved out by the fringes of the X cube?
23-04-2015
@Kevin and Jim: Please review the proposed fix. I have tested it works beautifully on Windows (d3d) and Mac (es2). Please see attached images for the before and after fix: http://cr.openjdk.java.net/~ckyang/RT-40600/webrev.00/ In this fix we intentionally make 3D Node use the same default blendMode property setting of Node; i.e. SRC_OVER: https://docs.oracle.com/javase/8/javafx/api/javafx/scene/Node.html#blendModeProperty Our original plan was not to enable blending for 3D till 9 to give us more time to address a more comprehensive blending support for 3D. However we believe choosing the same default blendMode as Node is a natural choice. This default mode will also answer to the much requested feature mentioned in RT-28874, though it is not a complete solution to that feature.
23-04-2015
Target to 9, but since it is a regression introduced in 8u40 we should evaluate it for 8u60.
22-04-2015