We do similar things for some of our subsystems. For certain things we manage the virtual objects ourselves then crunch them down into pre-transformed vertices and lay them into shared geometry arrays. Another trick is even to merge textures into shared textures and to shift the texture coordinates into the new texture space.
The you can continue this line of thought to actually build mini-renderers inside of Java3d using dynamic geometries and a system which sorts your triangles into the proper geometry array dynamically. So as you added items into your mini-renderer it would create as many unique shapes as it would need to render the various materials. The triangles would then be placed into the apprioriate geometry array's with field of view culling. We have done this in a couple of places with great success, but I would only recommend this for certain types of things. Note that Java3d compilation and scene state rendering actually does all these things for you very efficiently on things which are even slightly static in their geometric construction... this dynamic technique is only helpful when you have highly dynamic geometry or a very well understood rendering context. This can also be done for static objects and so you can enjoy a nice hybrid approach. For example... we have a new version of our avatar rendering system which needs to render a very complex skin for the avatar. The actual vertices are actually calculated seperatly from their rendering. But the kicker is that how the skin is to be actually rendered can vary in an infinate set of combinations. In the simplest case the skin is rendered as a single mesh with a single texture. In another case we might want to render a part of the mesh with a multi-pass technique (Dot3, etc). But rather than pre-think all these combinations we automatically sort the triangles by Brush (sort of like a Max material) and then hand them into a mini-rendering system. This system manages 1 or more shape3d's and will fill in their geometry. What is nice is that we only do the triangle to shape3d mapping when the skin changes, even though we are recalculating the vertices every frame and updading all the shapes every frame. Hmmm, guess I rambled on a bit. David Yazel -----Original Message----- From: Raj Vaidya [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 04, 2002 2:20 PM To: [EMAIL PROTECTED] Subject: Re: [JAVA3D] A basic doubt Hi Chien and Doug: Just a wild idea.... Is it not possible to string several (hundreds of) spheres all in one IndexedTriangleStripArray, and put several of these (300 is the magic number is it ?) under one Shape3D and all of them coordinate transformed to their appropriate locations so that the need for TransformGroups can be obviated. If picking individual spheres is not a concern how would this compare with TransformGroup + Shape3D + shared Geometry. Wish I knew how much memory a Shape3D and TransformGroup (w/ embedded Transform3D) would consume. If the TransformGroup + Shape3D memory cost is not that expensive, this approach would be quite ludicrous. Regards Raj =========================================================================== 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".