Java 3D Implementation - OpenGL vs DirectX

This document is to track some of the nuiances of the differences between running either the OpenGL or DirectX versions of Java 3D.

Platform

Obviously the DirectX version of Java 3D is only available for Windows platforms.

Features

Our opinion is that the OpenGL implementation of Java 3D is more feature rich than the DirectX implementation. Java3D 1.2.1 DirectX implementation uses DirectX 7.0. Java 3D 1.3 will use DirectX 8.0.

Performance

With OpenGL as the primary platform independent implementation we believe Sun has put more effort into the OpenGL implementation. Currently the OpenGL implementation appears to deliver roughly 30% to 50% better frame rates.

Stability

Since OpenGL was Sun's first implementation and hence Java 3D has had more history with OpenGL we believe that OpenGL should be more stable. However in bug testing a major application we found the DirectX 1.2.1 implementation to be far more stable than the OpenGL 1.2.1 implementation.

Details

Features

Features not supported by Java3D v1.2.1 DirectX version:

• Line width
• Line antialiasing
• Point size
• Point antialiasing
• PolygonAttributes backFaceNormalFlip
• RenderingAttributes ROP_XOR
• 3D Texture
• Texture color table

Performance

Typically resolutions below 16 bpp do not provide hardware acceleration (i.e. 256 color mode is unsupported).

Under Win98, OpenGL hardware acceleration is not supported for multiple monitors. You either need to disable one monitor in the display setting or switch to the DirectX version.

Stability

Technobabble

Interpretation of depth buffer values

For OpenGL version,
----------------------
glDrawPixels(width, height, GL_DEPTH_COMPONENT, GL_FLOAT, floatData);
glReadPixels(xOffset, yoffset, width, height, GL_DEPTH_COMPONENT, GL_FLOAT, floatData);

are used, it is up to the driver to handle the case when there is no z-buffer or it is not readable.

For D3D version using DX 7.0 (i.e. Java3D v1.2.1 )
-------------------------------------------------
If device has no z surface needed, i.e. dpcTriCaps.dwRasterCaps & D3DPRASTERCAPS_ZBUFFERLESSHSR then all the read/write depthcomponent will silently ignore.

Otherwise, the z surface is created. If during z surface lock D3D return fail, a message will printout "Fail to lock surface " with error code and operation return without doing anything.

For D3D version using DX 8.0 (i.e. next Java3D 1.3 release)
----------------------------------------------
The specification only allow locking the depth surface to read/write when D3DFMT_D16_LOCKABLE format is used. But this means we can't use stencil buffer by specific format D3DFMT_D24S8 for features such as DecalGroup. Thus DepthComponent can't coexist with other features in Java3D that required stencil buffer. Right now the depth format available is search with stencil buffer has priority. So under the nvidia driver, if display mode is 16 bit than DepthComponent is support.

If the z surface fail to get using DX function GetDepthStencilSurface(), an error message will display when -Dj3d.debug=true is used on startup. All read/write DepthComponent is ignored. Same thing happen when lock surface fail.

Further References

OpenGL Information for Microsoft Windows can be found at: http://www.opengl.org/developers/faqs/technical/mswindows.htm

Direct3D vs. OpenGL: A Comparison - http://www.xmission.com/~legalize/d3d-vs-opengl.html