I agree with Florin. And I'd like to remember that OpenGL is good, but DirectX support is a must. As you know, some video cards has poor OpenGL implementation, but has good Direct3D performance. That is why Java3D has both versions.
Other point : 3D OO is heavy to run. Java or C++. Over OpenGL or over DirectX. If you think your Java3D code could run faster and better if in pure native code you can try some tools, as JET, to generate Win32 native code from Java. http://www.excelsior-usa.com/jet.html It supports Java3D very well. (see a "to-be-compiled" demo included in JET) I am not telling this is the unique or the best one. Just try the free trial version, and see what changes in performance, memory, etc in your application. I guess it does several optimizations, faster floating point operations, faster low level calls, etc. I just try it with some demos, and it runs as expected. I will do not post about performance (gain or lost), since they can not be repreducible, and 3D are heavyly video card dependant. Some of you will discover that: Sun HotSpot JVM is a magic thing. Alessandro ----- Original Message ----- From: "Florin Herinean" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 20, 2003 9:23 AM Subject: [JAVA3D] AW: [JAVA3D] AW: [JAVA3D] Java 3D, GL4Java, JOGL, GLUT Hmmm. It *must* map to something. ogl, directx or anything. java3d is not "drawing" anything by itself, instead it uses a native api to make hardware rendering. I think (but I'm not the expert) that the most of the *java* code is somewhat neutral, and the native java3d libraries deals with specific ogl/directx implementations. My ideea, was to give up the native libraries, and implement instead the specific rendering parts as adapters over jogl or any other 3d wrapper. In the end, it can be a totaly independent jogl implementation, *and* a java3d which can be supplied with adapters for jogl, jd3d, etc. The adapters will play the role of the current native libraries. It might be that java3d will loose some speed with that approach, but I don't think that it is really significant. And the speed lost at higher level might be regained or surpassed by optimizations that will be allowed by the access to low level api's. My 2cents. Cheers, Florin -----Urspr�ngliche Nachricht----- Von: Kevin Glass [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 20. Juni 2003 14:00 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] AW: [JAVA3D] Java 3D, GL4Java, JOGL, GLUT Sorry, I hadn't looked.. in that case, couldn't java 3d be sped up by changing the architecture so it doesn't map to OpenGL.. Kev Florin Herinean wrote: >Did you have a look into the source code of some core java3d (decompiled) >classes ? Or even look with javap at member definitions ? For example, >almost all of the native methods present in Canvas3D have *direct* >counterpart in opengl. I don't think that java3d will loose performance by >replacing those native calls to calls of jogl wrapper methods. > >Cheers, > >Florin .... =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
