Well,
I didn't actually said that there are no shortcuts in the native layer. I simply
don't know anything about that. But with the current trend in hardware
rendering/graphic drivers, I'm expecting those shortcuts to be present there,
and not in the high level api.
For
example, the tests that were done to compare java3d with gl4java, showed that
java3d performs much better on low end / older machines, while gl4java was
flying on the newer graphic cards. That only meant that the similar shortcuts as
java3d was using were already implemented at hardware/driver level of the newer
graphic cards, so the gl4java test didn't take any performance
penalty.
Besides that, it's difficult to say that java3d is "too slow". It all
depends on the complexity of the scenegraph. If you start putting all the logic
of a high level scenegraph over gl4java, you'll get it slow
too.
Cheers,
Florin
-----Urspr�ngliche Nachricht-----Again, its once of these trade offs. With the current opinion being that Java3D is too slow it would seem odd to move towards a more generic solution (although in most cases I would see this as the far nicer thing to do).
Von: Kevin Glass [mailto:[EMAIL PROTECTED]
Gesendet: Freitag, 20. Juni 2003 15:00
An: [EMAIL PROTECTED]
Betreff: Re: [JAVA3D] AW: [JAVA3D] AW: [JAVA3D] Java 3D, GL4Java, JOGL, GLUT
I'm still getting over the shock that java3d doesn't currently take lots of shortcuts inside the native layer..
Kev
Florin Herinean wrote:
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 D:\java\bin>javap javax.media.j3d.Canvas3D Compiled from Canvas3D.java public class javax.media.j3d.Canvas3D extends java.awt.Canvas { ... cut ... native int getTextureUnitCount(long); native long createContext(long, int, int, long, long, boolean,boolean);native void createQueryContext(long, int, int, boolean, int, int); static native void destroyContext(long, int, long); native int createOffScreenBuffer(long, long, int, int, int); native void destroyOffScreenBuffer(long, long, int); native void readOffScreenBuffer(long, int, int, int); native void accum(long, float); native void accumReturn(long); native void clearAccum(long); native int getNumCtxLights(long); native boolean decal1stChildSetup(long); native void decalNthChildSetup(long); native void decalReset(long, boolean); native void ctxUpdateEyeLightingEnable(long, boolean); native void setDepthFunc(long, int); native void setBlendColor(long, float, float, float, float); native void setBlendFunc(long, int, int); native void setFogEnableFlag(long, boolean); native void setFullSceneAntialiasing(long, boolean); native int resizeD3DCanvas(long); native int toggleFullScreenMode(long); native void setGlobalAlpha(long, float); native void disableGlobalAlpha(long); native void updateSeparateSpecularColorEnable(long, boolean); native void beginScene(long); native void endScene(long); native boolean validGraphicsMode(); native void setLightEnables(long, long, int); native void setSceneAmbient(long, float, float, float); native void disableFog(long); native void disableModelClip(long); native void resetRenderingAttributes(long, boolean, boolean); native void resetTextureNative(long, int); native void activeTextureUnit(long, int); ... cut ... } D:\java\bin> -----Urspr�ngliche Nachricht----- Von: Kevin Glass [mailto:[EMAIL PROTECTED]] Gesendet: Freitag, 20. Juni 2003 09:16 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] Java 3D, GL4Java, JOGL, GLUT If you were to base a Java 3D implementation on top of a native binding to OpenGL (any binding) how could you hope to gain back any speed? Isn't oneofthe benefits of not implementing ontop of an OpenGL binding that you can do more on the native side and reduce the number of calls across JNI? Kev ������ ����ѹ (Andrew Davison) wrote: Florin, You know that I've played with GL4java, which is pretty much like jogl. My experience was terrible. Apart from good performance, the lack of a high level API stopped me to continue in that direction. I thought Gl4Java did have GLUT libraries? But I notice that the reference to them on the GL4Java docs page (http://gl4java.sourceforge.net/docs/overview/benefits.html) no longer works. There's also a reference to jFree-D on GL4Java's home page (http://www.jausoft.com/gl4java.html) which was a free implementation of Java 3D on top of GL4Java and JOGL -- that no longer works either. I think it was circulating during 1999 then disappeared. The author was Jean-Christophe Taveau ([EMAIL PROTECTED]) The JOGL home page (http://copa.pajato.com/jogl/jogl.html) refers to a Java 3D implementation by Andy King. His home page is available (http://www.magma.ca/~aking/), but the link to his Java stuff is down!! There seems to have been lots of work on adding scene graph capabilities. But it's all mysteriously disappeared....... :) - Andrew ----------------------------------------------------------------------------- Dr. Andrew Davison E-mail: [EMAIL PROTECTED] Dept. of Computer Engineering Fax: +66 74 212895 (then 201 after office hrs) Prince of Songkla University Tel: +66 74 211030 x2240 (then x316) Hat Yai, Songkhla 90112, Thailand or: +66 74 212895 x316 http://fivedots.coe.psu.ac.th/~ad =========================================================================== 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". ========================================================================= 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".=========================================================================== 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". ========================================================================= 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".
