JDK-8095058 : [3D] Texture transparency is ignored in 8u40
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8u40,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-02-07
  • Updated: 2015-07-06
  • Resolved: 2015-04-23
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 JDK 9
8u60Fixed 9Fixed
Related Reports
Relates :  
Relates :  
Description
Starting with 8u40 early release (build 23), the rendering of textured 3D nodes overlaping other nodes differs from previous releases, up to 8u31.

Before 8u40 : the polygons rendered behind the transparent one are visible with their own color

After 8u40 : the polygons rendered behind the transparent one are visible with a default color (scene background probably)

I suspect a z-buffer issue here...

I copy here a SSCE to illustrate the problem. I tested it against 8u25 8u31 8u40 and 9, as one can see on joined screenshots.

-----


import java.awt.BasicStroke;
import java.awt.Graphics2D;
import java.awt.image.BufferedImage;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.util.Map.Entry;
import java.util.TreeMap;

import javafx.application.Application;
import javafx.scene.Group;
import javafx.scene.PerspectiveCamera;
import javafx.scene.Scene;
import javafx.scene.SceneAntialiasing;
import javafx.scene.control.Label;
import javafx.scene.image.Image;
import javafx.scene.paint.Color;
import javafx.scene.paint.PhongMaterial;
import javafx.scene.shape.Box;
import javafx.scene.transform.Rotate;
import javafx.scene.transform.Translate;
import javafx.stage.Stage;

import javax.imageio.ImageIO;

public class TransparencyBug extends Application {

	@Override
	public void start(Stage stage) throws Exception {
		final TreeMap<Object, Object> props = new TreeMap<>(System.getProperties());
		for (Entry<Object, Object> entry : props.entrySet()) {
			System.out.println(entry);
		}

		final BufferedImage awtImage = new BufferedImage(100, 100, BufferedImage.TYPE_INT_ARGB);
		final Graphics2D g = (Graphics2D) awtImage.getGraphics();
		g.setColor(java.awt.Color.WHITE);
		g.setStroke(new BasicStroke(20));
		g.drawLine(-20, -20, 120, 120);
		g.drawLine(-20, 120, 120, -20);
		final ByteArrayOutputStream imageData = new ByteArrayOutputStream();
		ImageIO.write(awtImage, "png", imageData);
		final Image fxImage = new Image(new ByteArrayInputStream(imageData.toByteArray()));

		final Box box1 = new Box(200, 200, 200);
		box1.setMaterial(new PhongMaterial(Color.RED));
		final Box box2 = new Box(100, 100, 100);
		final PhongMaterial material = new PhongMaterial();
		material.setDiffuseMap(fxImage);
		box2.setMaterial(material);
		box2.getTransforms().add(new Translate(0, 20, -130));
		final Label label = new Label(System.getProperty("java.vendor") + "\nJava v."
				+ System.getProperty("java.runtime.version") + "\nFX v." + System.getProperty("javafx.runtime.version"));
		label.getTransforms().add(new Translate(-95, -95, -100.1));
		final Group group = new Group();
		group.getTransforms().add(new Translate(350, 250));
		group.getChildren().addAll(box1, box2, label);
		final Scene scene = new Scene(group, 600, 600, true, SceneAntialiasing.BALANCED);
		scene.setCamera(new PerspectiveCamera());
		scene.getCamera().getTransforms().addAll(new Rotate(-15, Rotate.Y_AXIS), new Rotate(-10, Rotate.X_AXIS));
		stage.setScene(scene);
		stage.show();
	}

	public static void main(String[] args) {
		launch(args);
	}

}


Comments
Changeset: 32e20d3446e0 Author: Chien Yang <chien.yang@oracle.com> Date: 2015-04-22 17:00 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/32e20d3446e0 Changeset: 9f3933818ce5 Author: Chien Yang <chien.yang@oracle.com> Date: 2015-04-22 16:58 -0700 URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/9f3933818ce5
23-04-2015

Looks good to me. +1
22-04-2015

I think ==0 is probably fine. See my last comment.
22-04-2015

In my earlier experiment, the alpha values aren't necessary small; blocky edges still appear with a 0.1 check. We would prefer to address this as a separate issue in RT-40600 which I'm currently looking into the use of blending.
22-04-2015

Also, if these are sampled values, then could the floating point really be a "converted value from 0->255" and thus be quantized down to 0? Even if it is mipmap interpolated, the data came from at most 8 samples and so if they were all 0, then we'd get 0. If 4 or more of them are just 1/255 then we'd round up, so this would only be an issue if there were 1-3 samples that all happened to be just 1/255. Even one of 8 samples at an alpha value of 4 or more would round up to an alpha value of 1/255 for the interpolated sample. So, I think the chances of ending up with really small values would be rare and it would be limited to the visible fringe around an object...
22-04-2015

Right, because we are using mipmap we are now getting an interpolation range of non zero alphas. Kevin and I have discussed and we are looking into enabling blending as a better solution.
22-04-2015

A fair question, and I asked Chien the same question offline (mainly to see if there would be any difference). I will note that testing for == 0 restores the pre-8u40 behavior and matches the 2D pipeline. In 8u20 we used GL_ALPHA_TEST (and the D3D equivalent) with a test for == 0 and replaced that with the equivalent shader test, but missed the 3D shaders. Also, when blending is enabled, which it isn't currently for 3D, but needs to be at some point, blending with a small, but non-zero alpha will give you better results than discarding the fragment.
22-04-2015

Is == 0 considered a good test for transparency in a shader? Could the value be a result of an interpolation and as such be very small, but not 0?
22-04-2015

@Kevin: Please review the proposed fix. The fix is to teach 3D shaders to do the same as existing 2D shaders for diffuse map with transparency. http://cr.openjdk.java.net/~ckyang/RT-40004/webrev.00/ While fixing this bug I uncovered another regression bug introduced in 8u40 when we support auto-mipmapping. It caused the rendered texture to look blocky on the tilted sides of the 3D shape. Please see RT-40600 for details.
22-04-2015

Right, this regression affected both d3d and es2 pipe. We can undo the deleted alpha test for desktop in the native code. That will fix this regression but it doesn't solve 3D (transparency) support for embedded.
17-04-2015

But that doesn't explain the regression. I don't think this is entirely the same issue as RT-28874 (although very much related), since that issue was present in 8.
17-04-2015

This is a blending issue that 3D currently doesn't support. Fixing this will also resolve the pressing issue in RT-28874.
17-04-2015

Thanks for the information. I managed to trace it down to the fix for RT-35173
07-04-2015

This is very unlikely to be a merge bug. When hg bisect reports a merge changeset it almost always means that the bug was introduced in one of the two branches being merged and not in the merge changeset itself. You need to either use "hg bisect --extend" at that point (if you are using a new enough hg) or you need to go back further manually with "hg update".
07-04-2015

This is likely a merge bug. Using hg bisect points to the following changeset: The first bad revision is: changeset: 7611:abe50f87067a parent: 7610:292cf1a8bc82 parent: 7607:376fe4bf61aa user: kcr date: Thu Jul 31 15:59:05 2014 -0700 summary: Automated merge with http://hg.openjdk.java.net/openjfx/8u20/rt
07-04-2015

That's exactly what I'm experiencing right now. Last year I created a JavaFX 3D sample application (see https://bitbucket.org/beatngu13/eiffeltower ) at my alma mater. If I switch from u31 to u40, the texture transparency is ignored.
02-04-2015

Attached images from submitter.
07-02-2015

Unfortunately there is no way for bug submitters to attach files. You can e-mail them to me and I will attach them.
07-02-2015

By the way, how do I join my screenshots ?
07-02-2015