Do the Java3D scenegraph classes really need to be Serializable and
implement things like NURBS etc? as I guess adding this sort of thing might
increase memory footprint and decrease efficiency? Could I suggest a
different approach? why not keep the core package as it is and have two
utility packages. The current one for viewers (i.e. programs that have
behaviors but have a fixed scene graph structure). i.e. lean & mean.
Then add a new utility package for editors (programs which construct and
edit the scene graph). This package could use the approach from the
following program. i.e. have a parallel structure to hold the additional
information not used to directly draw the scene.
http://easyweb.easynet.co.uk/m.baker/
The model is implemented as a set of beans, each one is cross linked to a
Java Scene graph class but is NOT extended from it. So for example the
m_transformgroup bean is cross linked by pointers (sorry references) to and
from the Java3D TransformGroup class.
Pros -
1) These classes can be beans and can be serialized because they are
separate from the Java3d classes. Persistent data can either be stored in
the bean, possibly duplicating the information in the Scene graph. Or the
data can be held in the scene graph only, this requires read/write methods
in the bean to serialize its parallel scene graph node.
2) I think this is neater architecturally, because is allows a separation
between the model data and the data that is used to render it. For example
m_sphere only needs to store the radius, but the scene graph holds all the
vertexes that make up the sphere in a Geometry Node. There are lots of
other examples where this separation simplifies things.
3) new editing functionality, for example NURBS can be easily added just by
adding a NURBS bean at build time. This would be cross linked to the
current geometry node in the scene graph.
4) new behavior can similarly be added by slotting in a new behavior bean.
Cons,
1) This makes it difficult to use the current Sun/VRML utilities for
reading different file formats. So the editor utility package would need a
new bean to read/write each filetype, such as VRML.
2) There may be some duplication of data storage.
Just an idea,
Martin
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
