Hi Rob, 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. Of course, if java3d will be dropped, then I'll have to go over to jogl, but I do hope that java3d will remain on the market, since at the moment is the only high level 3d api present. The ideea of rewritting again all the functionality already present in java3d in order to move to jogl is quite annoying for me. I really like java3d and the way it is structured.
It would be absolutely great to have jogl as a subpart of java3d immediate mode api. For example, even in jogl you need a canvas on which you want to draw, the GLCanvas. Why not make it that GLCanvas to be the Canvas3D ? They do have similar functionality. Or even better, Canvas3D to extend GLCanvas ! Then you only need to expose from the Canvas3D the methods getGL() and getGLU() and voila! java3d is cooperating with jogl. Those who wants higher level can use the normal java3d api, those who wants to use low level functions can use the jogl api. And most important, you can mix them ! I hope that somebody responsible will read my suggestions and think seriously about them. What seemed to be impossible with java3d and GL4java now looks very *possible*, since both jogl and java3d sit under the same umbrella. With Best Regards, Florin Herinean -----Ursprüngliche Nachricht----- Von: Rob Nugent [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 19. Juni 2003 14:20 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] Stress testing and 'buildGA' cost. Florin, I fear you are right about the RFE nature of this. I'm hoping that maybe there's some undocumented run-time flag that the j3d folks might be able to share with us to force the building of the geometry arrays. I can probably force this behaviour myself by starting my app with the camera initially positioned somewhere where all the geometry is visible, but this is a pretty nasty bodge. I've been thinking about moving to JOGL to get more control, but it really is horribly low-level after Java3D, and I don't think I can face writing a whole load of scenegraph/clipping/culling code etc. Rob Florin Herinean wrote: > Well, that looks like a RFE for me, and I totaly agree with it. We > (developers) need more fine grained control over how the geometries/display > lists are created/sent to the underlying API. > > From my point of view, it would be nice to allow low level operations on > display lists, like creation/deletion, especialy if we can execute them in a > separate thread. Something like: > > class GeometryArray: > -------------------- > > public void createDisplayList(); > public void removeDisplayList(); > public void enableDisplayList(boolean enable); > public boolean isDisplayListEnabled(); > public boolean hasDisplayList(); > > It would be great if such implementation will be done for both retained and > immediate modes. > > Kind Regards, > > Florin Herinean > > > -----Ursprüngliche Nachricht----- > Von: Rob Nugent [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 19. Juni 2003 13:31 > An: [EMAIL PROTECTED] > Betreff: [JAVA3D] Stress testing and 'buildGA' cost. > > > I'm deliberately coding a scene to act as a stress test to see how much > geometry > I can load into a scene graph and still get good performance. The scene is > one > of a landscape through which the ViewPlatform moves. I'm deliberately using > a > distant back clip plane, so that I can see objects from a long way away. > > Now, what I see is generally good performance (around 20fps), interrupted by > periods of horrible stuttering (with the frame rate dropping to below 1 > fps). > > This appears to be due to Java3D rebuilding its display lists. Overall this > shows up as around 2% of my time spent in the following stack trace: > > TRACE 555: > > javax.media.j3d.GeometryArrayRetained.buildGA(GeometryArrayRetained.java:Nat > ive > method) > > javax.media.j3d.GeometryArrayRetained.buildGA(GeometryArrayRetained.java:268 > 4) > > javax.media.j3d.DisplayListRenderMethod.buildDisplayList(DisplayListRenderMe > thod.java:177) > > javax.media.j3d.RenderMolecule.updateDisplayList(RenderMolecule.java:2260) > > javax.media.j3d.RenderBin.updateDirtyDisplayLists(RenderBin.java:3069) > javax.media.j3d.Renderer.doWork(Renderer.java:887) > javax.media.j3d.J3dThread.run(J3dThread.java:250) > > Further the problem is lessened by using '-Dj3d.docompaction=false' which > (if I > understand correctly) prevent j3d from flushing its display lists if they > haven't been used for a while. In this circumstance, the 'buildGA' cost > falls to > a negligible amount (< 0.1%). > > However, this still leaves me with the issue of horrible stuttering when > geometry is encountered *for the first time*, presumably as this is when the > display lists are built. > > What I was wondering, was whether there is any way to force these display > lists > to be built up front. I sooner take some extra startup cost, then put up > with > this stuttering. > > This is all particularly annoying, since if I move my ViewPlatform to a > point > where *all* my geometry is visible on screen, I still get good performance > (~10fps), but only once all the display lists are built. > > I'd welcome any comments/suggestions. > > Rob > -- > > > Rob Nugent > Sun Microsystems, Southampton, UK > > [EMAIL PROTECTED] > > Tel: +44 (0) 1489 585503 > Fax: +44 (0) 1489 881363 > > =========================================================================== > 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". > -- Rob Nugent Sun Microsystems, Southampton, UK [EMAIL PROTECTED] Tel: +44 (0) 1489 585503 Fax: +44 (0) 1489 881363 =========================================================================== 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".
