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:Native method)
javax.media.j3d.GeometryArrayRetained.buildGA(GeometryArrayRetained.java:2684)
javax.media.j3d.DisplayListRenderMethod.buildDisplayList(DisplayListRenderMethod.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%).
It is use to prevent cleanup display list when geometry outside outside view frustum for a while.
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.
There is no such flag to do this.
Display List will build on demand when geometry is inside frustum. However we can disable it via -Dj3d.displaylist=false or explicitly set capability bits that can modify geometry.
You can try to attach an offscreen canvas and explicitly position each and every geometry inside frustum, render it one by one and remove the canvas. This may work if flag -Dj3d.sharedctx = true is enabled and OGL driver support context sharing. (so display list can share among multiple OGL context) However this option is not available in D3D version.
Good luck !
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".
