The program was originally implemented as a set of beans, each bean represents a shape or some type of functionality, for example, box, sphere, collision, etc. These beans do not display themselves on the standard GUI. Instead they have to be able to create an entry in the scene graph so that they are displayed in the Canvas3D.
for information about Java Beans classes see:
So each bean needs to be able to read/write itself to/from VRML and X3D, be able to display itself via the scene graph, and implement the following interfaces:
|PropertyChangeListener||A message passing interface between beans|
|BeanContext||Standard way to allow hierarchical tree of beans to be defined at build time (Glasgow standard)|
|MutableTreeNode||displays itself in a JTree|
|Serializable||required for bean|
Each bean is cross linked to a Java Scene graph class but is NOT extended from it. So for example the transformGroupBean is cross linked by pointers (sorry references) to and from the Java3D TransformGroup class.
- 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.
- 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 sphereBean 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.
- 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.
- New behavior can similarly be added by slotting in a new behavior bean.
- 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.
- There may be some duplication of data storage.
mjbWorld packageContains environment and input/output
- mjbWorld.java <-- main application
- mjbFrame.java <-- top level frame
- filter.java <-- input/output filters exten this class
The following classes form a parallel structure to the Scene Graph and cross
linked to it.
The either store the persistent information or have access to it, therefore they can be serialised.
I have separated this package out in preparation for conversion to beans, but that's not yet complete so they are not valid beans.
Initially the beans could be used to build a scene graph at build time (not sure what benefit this would give as the program builds the model at runtime) but it would be an interesting extra capability to be able to build a scene graph from within a programming environment like JBuilder. And it does give us a standard set of interfaces to add capability at runtime.
- node_bean.java <-- other nodes extend this
The following classes are properties used in the above classes (attributes in XML terms).
How editors are implemented in mjbWorld
The following classes are editors for the parameters
- baseEditor.java <-- this is the base class for editors that is extended by all the following
extensions of scene graph objects
The following classes are extensions of scene graph objects