Florin Herinean wrote:
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.
I wholeheartedly agree with this. There is lots of value-add in Java3D which it would appall me to have to implement for myself. Additionally, it's an api for Java programmers with a reasonable OO structure, which JOGL definitely is not. The reasons I'm looking at JOGL are the following:
*) Opportunity to eliminate GC issues with picking in Java3D (My old hobby-horse) *) Ability to control these display list building issues. *) Access to the stencil buffer.
I think it unlikely that the cost-benefit equation for me would involve me moving to JOGL though - this is only my 'lunch-time' project after all.
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.
Of course, the trouble with this is that it would not fit well with the Direct3D version Java3D. In general (stencil buffer aside), I'm happy with the capabilites of Java3D, what I'd like is more ways to tweak its run-time behaviour.
Oh well, back to transaction processing... <context switch here>
Rob
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".
--
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".
