|
|
| Video Hardware
Return to the main FAQ page for more questions and answers.
This is an FAQ section about problems between J3D and video cards. We are in no way recommending any card over any other. If you ask us questions in this regard we will simply ignore them. We aim to document known problems so that if you come across them you should be able to fix it or at least see what others have experienced.
The following sites should be your starting place when you want to find out information about video cards, performance reviews etc.
3. Debugging What is happening
To find out what hardware accelaration and routines are being used, use the
command line option java -Dj3d.debug=true com.blah.MyClass To find out what modes you can get hardware acceleration under, try the Pixel Format Emulator from http://www.codemanual.com/opengl/samples_eng[1].shtml To force the card to run in a particular mode use:
java -Dj3d.d3ddevice=emulation
=hardware
=tnlhardware
If the given mode is not supported, the program will exit.
4. DirectX crashes in 256 Color mode (PCs)
The beta version of DirectX for Java 3D 1.2 attempts to change the desktop from 256 colour to fullscreen 16bit colour. It will display a warning message telling you of this. If it is unable to do this then the application should exit. To find out if this is the case, set the debug flag (see the question above for info on how to do this).
Microsoft has indicated a number of problems running Direct3D on AMD systems with Win2K. There are fixes available for this and you should visit this MS Tech Note for more information.
There are a number of cards based on the TNT chips. All of them appear to be suffering from a problem that appears to be driver related because the same behaviour has been noted in non Java3D base apps. The main problem is the implementation of the extensions to OpenGL in the video drivers. Early model drivers were core OpenGL implementation only. Java 3D checks for the availability of extensions and uses them if they are. As newer drivers are released, new buggy implementations of the extensions are used, causing the problems to appear when you update drivers. For Win2K users, the nVidia reference Detonator 2 drivers apparently work very well now (July 2000). You need driver version 5.00.2195.0522 or later. These can be downloaded from here You should update to at least Java 3D v1.1.2; however, the following card specific workarounds are available for earlier versions of Java 3D: STB Velocity 4400 I'm not sure of the reason for this, but I've found if you create the cone and then call cone.setAppearance( new Appearance() ) the whole cone is drawn (works on all occurances of this problem I've run into) (reported by Chad Zalkin chadz@webmart.net)
STB have a FAQ on their card and problems that can be found at: Frederic Gillet (fog1@xbind.com) reports that the following combination works without any problems:
He notes that the last TNT Dentonator2 drivers gave problems with textures so he reverted back to the original drivers. Diamond Viper 550 I am pleased to say that I have managed to solve the problems by using an *older* version of Diamond's drivers! The drivers I am now using are 4.10.01.0220, filename 550220.exe, which I obtained from Diamond's European web site. If people have trouble finding them, let me know and I'll pass them on. There are still a few inconsistencies, e.g. the presence of a background image seems to stop hardware acceleration; hopefully this will be addressed in a future release of Java3D. (reported by Glenn Proctor gproctor@info.bt.co.uk) Creative Labs Setting No traingstrip option works. Known that this does _not_ work on Viper 550.
There are some odd bugs relating to sharing
For NT make sure you have at least version 5.1.118, 4.0.0. For Win95, the 5382b08 beta driver seems to work well. The drivers can be fetched from http://www.ati.com/na/pages/spdrivers/index.html
3Dfx cards based on the (Older - Voodoo 1 and 2 ?) Voodoo chipset can run accelarated J3D applications, despite being full screen oriented. Jonathan Williams (ehannenwill@cc.curtin.edu.au) supplies the following HOWTO:
If you'd like to see textures running, try the TextureText application. That works fine as well... And I've tried this under both 95 and NT without any hassles. I've also tried the majority of the Java3D examples, and they all work fine for my configuratation - Remember, Java3D and the 3dfx OpenGL drivers are still both beta so your individual millage may vary. Obviously, you'll need the OpenGL version of Java3D to get this working. If you have the DirectX version, do not install over the top, as this will cause problems. Uninstall it first, then install the OpenGL version over the top - The usual disclaimers apply. Also, be forewarned that this is a memory hog - I suspect there is a memory leak somewhere (There also seems to be a link between this and the use of jpg textures - I haven't had time to experiment with this enough). Another minor note, my applications have an quit keystroke, and I use a little utility to stop people alt-tabbing away from the 3D Window. The sample applications don't have this facility so you'll have to alt-tab once (which should select the console you started the application from) and hit ctrl-c. That should let you exit without any dramas. Voodoo 3 The Voodoo 3 has limited texture support (maximum size of 256x256) and up through the ver 1.04 drivers exhibit texture corruption (OpenGL driver). 3dfx released driver version 1.06 on November 6, 2000, the texture corruption problems seem to be significantly less than before but our testing did still exhibit some texture corruption. We are seeing corruption on images that are not sized in powers of two (the same images display perfectly on GeForce video cards). Images that are 256x256 now appear to be displayed perfect (previously these images were corrupted badly on driver versions 1.03 and 1.04).
Various reports of dropping of texture maps leaving blank grey objects. Nothing confirmed. No solutions yet available.
10. AccelECLIPSE (AGP)
Polygons are clipped and filled incorrectly. Not minor errors, but large flashes and spikes appear out of all the polygons. The Java 3D team says this is related to the use of Open GL Vertex Arrays on the AccelEclipse. We had a similar problem on the Diamond FireGL 4000s, which use the same chipset. They fixed it in subsequent driver releases. No solutions have been reported.
To enable hardware accelaration under Win2K change the display depth from 16 bit to 32 bit. According to Doug Gehringer of Sun: The resulting performance is slower than under Windows98 (using SPEC Viewperf), but HW accelerated none the less. If you are getting a crash on exit or removal of the Canvas3D try the latest Detonater3 drivers. So far there have only been good reports and no bad ones.
The SGI VW, both 320 and 540 models have suffered, right from the outset, very poor performance of Java3D applications. This extends further to Java2 in general. Swing applications have problems dealing with colour maps (for example grey components end up being yellow or pink). This translates to the Java3D handling as well. SGI is not willing to fix this problem.
Early drivers for the VX1 and GVX1 cards were very flaky. Like the Visual Workstation, Swing and Java3D did not play nicely with the cards. The drivers from v 2.15 and later seem to fix many of the problems. John Sutter supplies the following extra hints: There is a registry entry you can set to disable fast double-buffering; when this is set to 1, your app's gui works correctly. The path in the registry for this entry is
HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/glint/Device0
Add a new DWORD value called With V2.16 drivers, when mixing Swing and Java3D, there are still problems. 3DLabs recommends using the "SolidWorks" settings to get the best performance.
There seem to be a few issues floating around with these cards. At least two bugs are known to exist: 4760874 which says that there are no valid OpenGL configurations available for what Java3D would like (typically seen as an exception in the constructor of SimpleUniverse) which may have something to do with the amount of Z-buffer depth that is automatically configured for the card. Normally it uses 12-bit depth buffer, where Java3D would like to use 16-bit as a minimum. The driver config allows the ability to select a 32-bit mode, which seems to fix the problems.
15. Why does J3D crash with XWindows on Linux?
Firstly, read the README that comes with the blackdown port of Java3D as the answer is there. That's why the provide it. You've read it haven't you?. If you still haven't read it, then you will need to disable shared contexts for it to work. java -Dj3d.sharedctx=false Myprogram There are a new set of problems with RedHat 7.2. The main issue is the combination of the latest versions of nVidia drivers, XFree and Mesa. The solution is too long to post here, but this post to the J3D list in March 2002 should provide most of the information you need:
|
|
[ j3d.org Home ]
[ Java OpenGL ]
[ Aviatrix3D ]
[ Tutorials ]
[ Books ]
[ Contact Us ]
Hosted by Yumetech, Inc Last Updated: $Date: 2006/04/18 18:19:59 $ |