JDK-8123305 : D3D: Near clip appears to clip further (away from viewer) than the specified near value
  • Type: Bug
  • Component: javafx
  • Sub-Component: graphics
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-09-11
  • Updated: 2015-06-17
  • Resolved: 2013-12-03
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
8Fixed
Related Reports
Blocks :  
JDK-8123525 - D3D: Prism shouldn't set D3DRS_CLIPPING to false
Duplicate :  
JDK-8094141 - [FX3D] ParallelCamera, Rotation, Clipping: Difference between Mac and Win7
Relates :  
JDK-8124131 - [FX3D] Camera: FarClip and NearClip dependence.
Description
Attached are a test program and 2 images that illustrates the problem on prism-d3d pipe (see NearFarClipBad.PNG). This program works as expected on the prism-es2 pipe (see NearFarClipGood.PNG). The Blue square represents the edge of the near clip and the Red square represents the edge of the far clip.
Comments
Verified with b119
11-12-2013
Target build: b119
03-12-2013
Changeset: 268fe91a74e0 Author: vadim Date: 2013-12-03 12:24 +0400 URL: http://hg.openjdk.java.net/openjfx/8/graphics/rt/rev/268fe91a74e0
03-12-2013
I've added tempAdjustClipSpaceMat as Chien suggested and deleted a couple of extra line breaks nearby. I've run gradle -PFULL_TEST=true clean test, explicitly checking the result of the NearAndFarClipTest as well as manual testing.
03-12-2013
Agree with Chien's comments, although #1 could be done as a follow-up issue if you don't want to retest it after making the change. Have you run all of the existing tests to ensure no regressions? Seems fine to me (we did something very much like this for Java 3D for a similar reason). +1
03-12-2013
Looks good to me. I have 2 minor suggestions but none is a blocker. 1) The new method, adjustClipSpace(), will create new double array per call ( double[] m = projViewTx.get(null); ). Why not do what is already done in the caller of this method create a new static double array (see tempTx)? We can clean this up together when we need to address MT // Temp. variables (Not Thread Safe) private static GeneralTransform3D tempTx = new GeneralTransform3D(); private static Vec3d tempVec3d = new Vec3d(); private static double adjustClipSpaceMat = new double[16]; // 4x4 matrix 2) Please delete the extra space between the method description and the method itself.
02-12-2013
Chien, Kevin, Please review a fix for this bug. http://cr.openjdk.java.net/~vadim/RT-32880/webrev.00/ The problem is described in the previous comment. The NDC (normalized device coordinates) are computed by dividing the result of projection transformation by the w component. Here E are coordinates in the eye space, C in the clip space and NDC is in the device coordinates. (Xc, Yc, Zc, Wc) = Mproj * (Xe, Ye, Ze, 1) (Xndc, Yndc, Zndc) = (Xc/Wc, Yc/Wc, Zc/Wc) The resulting Zndc is in the range from -1 to 1, but Direct3D expect it to be from 0 to 1, so we need our Z'ndc to be: Z'ndc = (Zndc+1)/2 Z'ndc = Z'/Wc so Z'c = (Zc/Wc+1)/2*Wc = (Zc+Wc)/2 Since Zc is computed by multiplying 3rd row of the Mproj by the E vector, and Wc using the 4h row, we need M'proj to be such that its 3rd row will be M'proj3 = (Mproj3+Mproj4)/2 So I've added D3DContext.adjustClipSpace method which modifies viewProj matrix in such a way so that computed NDC coordinates will use [0..1] range for Z values. I've modified NearAndFarClipTest toy so that it includes 2 sliders for adjusting near and far clip planes so it can be easily seen how it behaves. The test in the RT-27890 can also be used to verify the fix.
02-12-2013
The problem here is that OpenGL projection matrix transforms z eye coordinates from [near, far] to the [-1, 1] device coordinates, while Direct3D expects them to be in the [0, 1] range. The solution can be either to create different projection transforms for different pipelines, or to scale device coordinates in the D3D vertex shader. I'm investigating the latter solution, there seems to be some problem in the test itself.
29-11-2013
Please remember to remove the comment and enable the test code in the visual unit test, NearAndFarClipTest.java, before resolving this bug: // Enable Near Clip test once RT-32880 is fixed. // D3D: Near clip appears to clip further (away from viewer) than the specified near value // // Verify Near Clip // Color color = getColor(testScene, WIDTH / 2, HEIGHT / 2); // assertColorEquals(Color.BLUE, color, TOLERANCE);
18-11-2013
Converted test case into unit test and example (toys) in the rt repository: apps/toys/FX8-3DFeatures/src/fx83dfeatures/NearAndFarClipTest.java tests/system/src/test/java/test3d/NearAndFarClipTest.java
13-09-2013