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".

Reply via email to