visual errors in native SWT

[arsiamons]

Hi!
I am starting with jReality and want to use it within a view of a RCP-application. To introduce not more dependencies than really needed i use a stripped down version - backends.share, core, io, jogl, swt, tool and antlr.

I experience problems with the JOGL rendering on my laptop with onboard Intel GM45 running under Ubuntu 9.10 64bit:

or:


Produce by this minimal code:

Code: Select all

		SwtViewer viewer = new SwtViewer(canvas);

		JrScene scene = JrSceneFactory.getDefaultDesktopScene();
		SceneGraphComponent contentNode = scene.getPath("emptyPickPath").getLastComponent();

		viewer.setSceneRoot(scene.getSceneRoot());
		viewer.setCameraPath(scene.getPath("cameraPath"));

		//IndexedFaceSet ifs = Primitives.icosahedron(); 
		IndexedFaceSet ifs = Primitives.coloredCube(); 
		contentNode.setGeometry(ifs);

		// center and scale the content
		Rectangle3D bds = BoundingBoxUtility.calculateBoundingBox(contentNode);
		double[] ext = bds.getExtent();
		double objectSize = Math.max(Math.max(ext[0], ext[1]), ext[2]);
		double[] center = bds.getCenter();

		MatrixBuilder mb = MatrixBuilder.euclidean();
		mb.scale(targetObjectSize/objectSize);
		mb.translate(-center[0], -center[1], -center[2]);
		Matrix newMatrix = mb.getMatrix();
		newMatrix.assignTo(contentNode);

It appears that the back is rendered while the front is transparent - and the graphic card driver is the problem, but: The odd thing is that JRViewerVR does not show this behaviour as well as the code above on another PC (Ubuntu 9.10 32bit, ATI Radeon HD 2400) is ok.

Have i missed something important?

I have tested different variations including switching over to current JOGL 2.0beta10. If someone has a hint, or i can provide more information, please answer!

Thanks, Mario.

[STRESS]

Looks like backface culling is behaving wrongly. Maybe JRView has a different winding on the geometry that is why it works accidentally.

You mentioned JOGL2 did that work out of the box with jReality? Because I was thinking of migrating to JOGL2 as well but I wonder if I have to change parts of the JOGL backend.

[arsiamons]

Thanks for your answer!

Looks like backface culling is behaving wrongly. Maybe JRView has a different winding on the geometry that is why it works accidentally.

Is it plausible that this also happens when loading the same input file? Can it be changed? I tested inverting the normals but this really messed the rendering up.

You mentioned JOGL2 did that work out of the box with jReality? Because I was thinking of migrating to JOGL2 as well but I wonder if I have to change parts of the JOGL backend.

Not quite. First: I've done this in a quick and dirty way to resolve the compiler errors.
What worked for me:
- It seemes that from the GL object some functionality was dropped. The new GL2 object (can be acquired from GL with #getGL2()) seems to include the missing methods and constants.
- I set the often used reference JOGLRenderer#globalGL as a GL2 object and fixed the compile errors in other objects in the same way.
- Some methods seems to be renamed, dropped e.g. _ARB (or so) from the end of the method name - even in the GL2 object.
- Some interfaces/abstract classes have a new dispose method - filling these maybe can solve some memory leak problems reported in the forum?

I don't know if this approach is valid or if using the GL2 object has other disadvantages - but it gives me a compilable result and the renderings seems similar as before.

[STRESS]

loading the same input file? Can it be changed? I tested inverting the normals but this really messed the rendering up.

No that wouldn't be the case well in that case it only springs one other thing into my mind, that JRViewer sets different GL culling states by any change. While your application doesn't set the same GL states. With any sort of glDebugger it probably would be possible to see if that's the case. Well inverting the normals will not change that, since hardware culling doesn't actually use the normal.

Not quite. First: I've done this in a quick and dirty way to resolve the compiler errors.
What worked for me:
- It seemes that from the GL object some functionality was dropped. The new GL2 object (can be acquired from GL with #getGL2()) seems to include the missing methods and constants.
- I set the often used reference JOGLRenderer#globalGL as a GL2 object and fixed the compile errors in other objects in the same way.
- Some methods seems to be renamed, dropped e.g. _ARB (or so) from the end of the method name - even in the GL2 object.
- Some interfaces/abstract classes have a new dispose method - filling these maybe can solve some memory leak problems reported in the forum?

Thank you for sharing your experience. Hmm that's about what I've guessed maybe a little less work than I initial anticipated but to do it probably you better would copy the JOGL backend and make a JOGL2 backend of that. I wonder if there are any official plans of doing so?

[arsiamons]

No that wouldn't be the case well in that case it only springs one other thing into my mind, that JRViewer sets different GL culling states by any change. While your application doesn't set the same GL states. With any sort of glDebugger it probably would be possible to see if that's the case.

OK, perhaps i will try this later as this seems to me not that promising. Till then i blame the display driver and wait for a new one...

Thank you for sharing your experience.

No problem!

Hmm that's about what I've guessed maybe a little less work than I initial anticipated but to do it probably you better would copy the JOGL backend and make a JOGL2 backend of that. I wonder if there are any official plans of doing so?

I encountered an GLException* when invoking JOGL2 code on windows - therefore parallel development seems advisable - in addition that JOGL2 is yet declared beta.

*) javax.media.opengl.GLException: Error: attempted to make an external GLContext without a valid pixelformat
at com.sun.opengl.impl.windows.wgl.WindowsExternalWGLContext.create(WindowsExternalWGLContext.java:76)
at com.sun.opengl.impl.windows.wgl.WindowsWGLDrawableFactory.createExternalGLContext(WindowsWGLDrawableFactory.java:169)

-> happend at the statement:

Code: Select all

GLContext context = GLDrawableFactory.getFactory(GLProfile.getDefault()).createExternalGLContext();