JOGL3Viewer ORTHOGONAL viewing

Found a bug? Post here.
Post Reply
cznlzq
Posts: 17
Joined: Mon 5. Mar 2012, 22:55

JOGL3Viewer ORTHOGONAL viewing

Post by cznlzq » Wed 3. Sep 2014, 21:48

Hi,

I think this is a bug.

When we use cam.setPerspective(false) to get the ORTHOGONAL viewing, the rendering is messed up.

PERSPECTIVE:
PERSPECTIVE.PNG
PERSPECTIVE.PNG (53.14 KiB) Viewed 1350 times
ORTHOGONAL
ORTHOGONAL.PNG
ORTHOGONAL.PNG (66.58 KiB) Viewed 1350 times
I guess the camera PERSPECTIVE/ORTHOGONAL property only affects the projection matrix which determines the position information in the shaders.
From the rendering results, the gl_Position should be correct but somehow the color is not.

By the way, it only happens when the TRANSPARENCY of face appearance is enabled.
When the TRANSPARENCY is disabled, everything is fine for both PERSPECTIVE and ORTHOGONAL viewing.

Please take a look,
thanks.

Andre
Posts: 226
Joined: Fri 18. Sep 2009, 11:30

Re: JOGL3Viewer ORTHOGONAL viewing

Post by Andre » Tue 9. Sep 2014, 17:44

Hi cznlzq,

it took a while to understand the problem, why isn't it working for orthogonal perspective. It depends of the depth of the clipping planes. Because the transparency-shader starts rendering from the far clipping plane the exactness is high at the far clipping plane and low at the near clipping plane. This doesn't have any effect for the perspective mode, because the transformation of the frustum to the NDC-Cube takes care of it.

This bug only happens for the orthogonal case and you can get aware of it when you change the value of the far clipping plane to a lower number. We changed it from 1000 to 100 and got right working transparency.

We asked us, why the far clipping plane is that far away and found as answer, because of the Skybox which has a depth and is not infinity. This sounds like a bug for me but has probably a reason in the past...

cznlzq
Posts: 17
Joined: Mon 5. Mar 2012, 22:55

Re: JOGL3Viewer ORTHOGONAL viewing

Post by cznlzq » Wed 10. Sep 2014, 15:59

Hi Andre,

Thanks for the information.

With my testing, it indeed is related to far plane. But apparently, 100 is not the solution for all.

IndexedFaceSetFactory ifsf = new IndexedFaceSetFactory();
double [][] vertices = new double[][] {
{-.8f, .3f, .5f, 1},
{.3f, .3f, .5f, 1},
{.3f, -.8f, .5f, 1},
{.3f, -.8f, .5f, 1},
{-.8f, -.8f, .5f, 1},
{-.8f, .3f, .5f, 1},

{-.3f, .8f, .25f, 1},
{.8f, .8f, .25f, 1},
{.8f, -.3f, .25f, 1},
{.8f, -.3f, .25f, 1},
{-.3f, -.3f, .25f, 1},
{-.3f, .8f, .25f, 1},

{-.9f, -.5f, .75f, 1},
{-.5f, -.5f, .75f, 1},
{-.5f, -.9f, .75f, 1},
{-.5f, -.9f, .75f, 1},
{-.9f, -.9f, .75f, 1},
{-.9f, -.5f, .75f, 1}
};
int [][] faceIndices = new int [][] {
{0, 1, 2}, {3, 4, 5},
{6, 7, 8}, {9, 10, 11},
{12, 13, 14}, {15, 16, 17}
};

Color[] faceColor = new Color[]{new Color(0, 255, 0), new Color(0, 255, 0),
new Color(0, 0, 255), new Color(0, 0, 255), new Color(255, 0, 0), new Color(255, 0, 0)};

ifsf.setVertexCount( vertices.length );
ifsf.setVertexCoordinates( vertices );
ifsf.setFaceCount( faceIndices.length);
ifsf.setFaceIndices( faceIndices );
ifsf.setGenerateFaceNormals( true );
ifsf.setFaceColors(faceColor);
ifsf.update();
SceneGraphComponent sgc = SceneGraphUtility.createFullSceneGraphComponent("Cube");
sgc.setGeometry(ifsf.getIndexedFaceSet());
sgc.setAppearance(new Appearance());

Appearance app = sgc.getAppearance();
app.setAttribute(CommonAttributes.TRANSPARENCY_ENABLED, true);
app.setAttribute(CommonAttributes.POLYGON_SHADER+"."+CommonAttributes.TRANSPARENCY, .3);

return sgc;

When the far plane is 100, the result is bad
far100.PNG
far100.PNG (117.37 KiB) Viewed 1332 times
After I change it to 20, the result is good
far20.PNG
far20.PNG (101.87 KiB) Viewed 1332 times
And you mentioned "This doesn't have any effect for the perspective mode, because the transformation of the frustum to the NDC-Cube takes care of it. "

And currently, I'm kind of confused for this,

Because when I looked at the ORTHOGONAL projection matrix in P3.java

public static double[] makeOrthographicProjectionMatrix(double[] m, Rectangle2D viewport, double near, double far) {
// assert dim checks
double l = viewport.getMinX();
double r = viewport.getMaxX();
double b = viewport.getMinY();
double t = viewport.getMaxY();
if (m == null) m = new double[16];
Rn.setIdentityMatrix(m);
m[0] = 2/(r-l);
m[5] = 2/(t-b);
m[10] = -2/(far-near);
m[3] = -(r+l)/(r-l);
m[7] = -(t+b)/(t-b);
m[11] = -(far+near)/(far-near);
return m;
}

I think it's correct.

Is it really related to the NDC-Cube only?

Anyway, overall I can't see any difference between ORTHOGONAL and perspective in the DepthPeeling solution.
Probably you guys would have more insight thoughts about that.

Thanks.
Andre wrote:Hi cznlzq,

it took a while to understand the problem, why isn't it working for orthogonal perspective. It depends of the depth of the clipping planes. Because the transparency-shader starts rendering from the far clipping plane the exactness is high at the far clipping plane and low at the near clipping plane. This doesn't have any effect for the perspective mode, because the transformation of the frustum to the NDC-Cube takes care of it.

This bug only happens for the orthogonal case and you can get aware of it when you change the value of the far clipping plane to a lower number. We changed it from 1000 to 100 and got right working transparency.

We asked us, why the far clipping plane is that far away and found as answer, because of the Skybox which has a depth and is not infinity. This sounds like a bug for me but has probably a reason in the past...

Andre
Posts: 226
Joined: Fri 18. Sep 2009, 11:30

Re: JOGL3Viewer ORTHOGONAL viewing

Post by Andre » Wed 10. Sep 2014, 16:17

I'm sorry, of course 100 is not the main solution. It depends on the size of the geometry inside the scene. At least for the 3 geometries I tried a got nice results with 100. I only wanted to say, that probably a value around 100 would help you to find a solution for you.

BTW: You can generate the "bug" for perspective mode as well but the perspective transformation from the frustum to the ndc-cube takes more or less care of it. You can find a nice 2D-explanation at figure 4.7
http://www.arcsynthesis.org/gltut/Posit ... ction.html

If you draw the same example for the orthogonal case and compare it, you can see that geometry placed close to the near clipping plane will fail because the shader thinks it has the same depth (the resolution is not high enough).

Transparency is rendered from the rear (farclipping plane) so the float-pointer resolution is high at the far clipping plane and gets lower the closer it gets to the near clipping plane.

cznlzq
Posts: 17
Joined: Mon 5. Mar 2012, 22:55

Re: JOGL3Viewer ORTHOGONAL viewing

Post by cznlzq » Wed 10. Sep 2014, 21:30

I knew 100 is not the solution for all.

The relationship between distance and z is linear in an orthographic projection, but not in a perspective projection.

It would be easier to deal with linear cases, isn't it?

But anyway, for this specific case,

I draw these vertices,

double [][] vertices = new double[][] {
{-.8f, .3f, .5f, 1},
{.3f, .3f, .5f, 1},
{.3f, -.8f, .5f, 1},
{.3f, -.8f, .5f, 1},
{-.8f, -.8f, .5f, 1},
{-.8f, .3f, .5f, 1},

{-.3f, .8f, .25f, 1},
{.8f, .8f, .25f, 1},
{.8f, -.3f, .25f, 1},
{.8f, -.3f, .25f, 1},
{-.3f, -.3f, .25f, 1},
{-.3f, .8f, .25f, 1},

{-.9f, -.5f, .75f, 1},
{-.5f, -.5f, .75f, 1},
{-.5f, -.9f, .75f, 1},
{-.5f, -.9f, .75f, 1},
{-.9f, -.9f, .75f, 1},
{-.9f, -.5f, .75f, 1}
};

the z in which is between 0-1

and rendering shader tries to map it linear to 0.1-100

What you are telling me is that, the resolution of this mapping will cause kind of z fighting which messes up the rendering when we are using the transparent shader.
But I don't think this mapping range is so huge that it cannot tell the correct depth information in this linear case.

One more thing, I also noticed that if I turn the transparency off, the rendering looks good.
non-transparent far 100.PNG
non-transparent far 100.PNG (95.87 KiB) Viewed 1327 times
Both are far 100, how come the non-transparent shader doesn't have the mapping range/resolution/precision(whatever you call it) problem
but the transparent shader does(which has to set a smaller far value like 20)?
You know, both of them are using exactly the same orthographic projection matrix.

I find this very interesting and I just want to make myself clearly understood what's going on there.

Is it possible that the transparent shader doesn't deal with the depth correctly?

Thanks
Andre wrote:I'm sorry, of course 100 is not the main solution. It depends on the size of the geometry inside the scene. At least for the 3 geometries I tried a got nice results with 100. I only wanted to say, that probably a value around 100 would help you to find a solution for you.

BTW: You can generate the "bug" for perspective mode as well but the perspective transformation from the frustum to the ndc-cube takes more or less care of it. You can find a nice 2D-explanation at figure 4.7
http://www.arcsynthesis.org/gltut/Posit ... ction.html

If you draw the same example for the orthogonal case and compare it, you can see that geometry placed close to the near clipping plane will fail because the shader thinks it has the same depth (the resolution is not high enough).

Transparency is rendered from the rear (farclipping plane) so the float-pointer resolution is high at the far clipping plane and gets lower the closer it gets to the near clipping plane.

cznlzq
Posts: 17
Joined: Mon 5. Mar 2012, 22:55

Re: JOGL3Viewer ORTHOGONAL viewing

Post by cznlzq » Wed 10. Sep 2014, 23:18

Another example tells that this assumption, "the resolution is not high enough" is the reason for the bad rendering, cannot stand.

I set the near -100 and far remains 100 for the ORTHOGONAL viewing.
This setting supposes to make the resolution problem worse according to "the resolution is not high enough" assumption.
However, it works.
near -100 far 100.PNG
near -100 far 100.PNG (86.38 KiB) Viewed 1327 times
Summary, 0.1 to 100 doesn't work, 0.1 to 20 works, -100 to 100 works.
So I think "the resolution is not high enough" is not the reason for the bad rendering.

Thanks.
Andre wrote:I'm sorry, of course 100 is not the main solution. It depends on the size of the geometry inside the scene. At least for the 3 geometries I tried a got nice results with 100. I only wanted to say, that probably a value around 100 would help you to find a solution for you.

BTW: You can generate the "bug" for perspective mode as well but the perspective transformation from the frustum to the ndc-cube takes more or less care of it. You can find a nice 2D-explanation at figure 4.7
http://www.arcsynthesis.org/gltut/Posit ... ction.html

If you draw the same example for the orthogonal case and compare it, you can see that geometry placed close to the near clipping plane will fail because the shader thinks it has the same depth (the resolution is not high enough).

Transparency is rendered from the rear (farclipping plane) so the float-pointer resolution is high at the far clipping plane and gets lower the closer it gets to the near clipping plane.

Post Reply