> Date: Sun, 9 Feb 2003 23:24:07 -0700 > From: Anirban Bhadore <[EMAIL PROTECTED]> > > So as it looks like manipulation of a live scene graph has a major > performance problem. Am I missing something? Any suggestions? How the game > writers are handling these scenarios in Java3d?
If you must update geometry directly, you might want to give the GeometryArray BY_REF semantics a try, particularly with the interleaved formats. This will in most cases at least avoid making copies of your data. Just updating the reference to the Geometry in a Shape3D node isn't the same thing; Java 3D will still make a copy. Updating the structure of a live scene graph with thousands of Shape3Ds and hundreds of BranchGroups and Transform3Ds is a heavy-weight operation to say the least. Java 3D internally doesn't work directly with the application scene graph; it doesn't support the spatial organization or attribute sorting capabilities needed for high-performance spatial queries and efficient use of the rendering hardware. Every time you update a live scene graph the new state has to be propagated into the internal Java 3D data structures. It also has to be synchronized with all the threads that are contending for access. Try to consolidate your nodes as much as possible. Java 3D will try to do this itself if you compile the scene graph and leave enough capability bits unset, but this doesn't really help for such a dynamically changing scene graph. The perf_guide.txt file distributed with the release may be helpful. -- Mark Hood =========================================================================== 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".
