mjbWorld - Beans In mjbWorld

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.

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

mjbWorld package

Contains environment and input/output

mjbModel package


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.


Properties

The following classes are properties used in the above classes (attributes in XML terms).


Property editors

How editors are implemented in mjbWorld

The following classes are editors for the parameters

extensions of scene graph objects


The following classes are extensions of scene graph objects

metadata block
see also:

Java Beans -- Architecture

Correspondence about this page

Book Shop - Further reading.

Where I can, I have put links to Amazon for books that are relevant to the subject, click on the appropriate country flag to get more details of the book or to buy it from them.

 

Commercial Software Shop

Where I can, I have put links to Amazon for commercial software, not directly related to this site, but related to the subject being discussed, click on the appropriate country flag to get more details of the software or to buy it from them.

 

This site may have errors. Don't use for critical systems.

Copyright (c) 1998-2017 Martin John Baker - All rights reserved - privacy policy.