The paper proposes an open architecture for 3D editors.
- Design Limits
- Bean Model
- How to implement modular architecture
The proposal is for a modular editor, the core functionality should be a resource which can be used and added to by users and open source community under the GNU license. The core functionality is as follows:
- The program must be able to:
- Create 3D models
- Edit existing 3D models
- Display and explore 3D Worlds.
- Allow people, who are not experts in 3D work, to create and manipulate interesting 3D worlds.
- The user should be able to create and manipulate:
- The program should use existing open standards such as: Java, VRML, Java3D, JavaBeans, and other storage and rendering standards.
- The program should be easily expandable, as far as possible by runtime
plugins, or otherwise by extending classes at build time. Plug-ins should
allow the addition of:
New storage formats
- The design of the program should be highly scalable, the design should
not impose limits (beyond the underling Java3D and platform limits) such as:
No limit to number of shapes supported.
No limit to complexity of shapes (number of triangles)
No limit to resolution (such as allowing double and float)
- Performance should be good enough for realtime editing and simple simulations
and games. The user of a reasonably upto date machine should be able to use
large models with:
- Reasonable load and save times.
- Reasonable screen refresh rates
- Acceptable delays in mouse interactions, etc.
- Physics modeling. Simulates the behavior of solid objects, objects do not pass through each other but collide and behave according to Newtonian mechanics, including gravity, also particle systems.
- Games generation framework, allows users to build and export games.
- Dynamic modeling and animation, such as bones/IK etc.
In order to avoid trying to do everything, I suggest defining the boundaries of the program as follows:
- It is an application as opposed to an applet. It is installed and run on the users system, not through a browser.
- It is client based as opposed to server based (it is a fat client). It is not designed for multi-user worlds.
- It is optimized for editing as opposed to a viewer. Although it can be used as a VRML viewer but simpler applications may prefer a more lightweight solution.
The program was originally written in Java and was 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.
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|
|mjbWorld Classes||Java3D classes|
The program is divided up into the following packages:
The mjbModel package contains classes representing all the node types such as Transform, IndexedFaceSet, Appearance, etc. Also their parameters.
The mjbWorld package contains the user interface, file filters etc.
The reason for this is to allow programmers to build a completely different user interface, but still use the underlying scene graph model.
The program can be assembled, at build time, from just the bean components required. This could done in most build environments such a JBuilder by dragging the required bean onto the screen.
When a new bean is added, the existing beans or at least any parents of this bean need to know about it, currently I have no standard way to do this, so currently some code editing is required.In the future we may be able to have a standard mechanism for the bean to register itself so that the other beans know about it. Possibly using Infobus or Java Spaces or 'Glasgow' standard but I have not done this yet.
A disadvantage of this approach is that, each customisation of the program would require a full build and distribution of the code. In some ways it would be better if additional addon objects could be added to the already compiled core program. I think it cold be possible to do this due to the 'late binding' of java objects. All we need is a mechanism for the core program to be able to discover the new objects and run them.
So, as described above, new shape types, can be written as beans and added to the program. The bean will have procedures to draw itself in 2D and 3D, describe itself in the tree view and read/write (serialise) itself to the standard formats.
files supported see here.
File read/write is done by serialising the mjbWorld scenegraph structure (the left side of the diagram above). This starts with the rootBean this saves its own parameters including child nodes below it (SFNode and MFNode). These child nodes are saved by calling their own save procedures and so on recursively. So the whole scene graph can be saved and each node only needs to know how to save its own parameters. File read is done in the same way.
So when a new node is added, it only needs to know how to load and save itself, No other classes and no general read/write parsers are needed.
But what if we want to support new file formats (both read and write) such as DXF or OBJ. One way would be ad this capability to each bean, so that it knows how to save itself as DXF or whatever, in addition to the other formats it supports.
There are some behaviours built into the core program, but these are very limited, repetitive behavours. These use VRML type Sensors and Interpolators. These work by sending events between the beans.
There is a need to add much more general purpose behaviours. It seems to me that the best way to do this is to support a scripting language in the program. There seem to be a number of such programs available, see below, so it seems silly to try to reinvent the wheel.
Whatever scripting language is chosen it needs to be able to.
- Set and read the bean properties.
- Call the bean methods
- Generate bean events.
- Be triggered by the bean events.
- The scripts need to be stored with the program (for example in XML format) or loaded interactively by the user
- needs to be open source so that we can be sure that it will always be available, and bugs can be fixed.
Examples of how this might be used: say you were writing a 3D game, when there was a collision between two objects, this would trigger a script which would alter the scores and start an explosion sequence.
Another example might be to drive an animation sequence.For information about scripting see here.
We also be able to dynamically add new tools, wizards, etc. to the program. Again this should be done by plugging in a general purpose scripting language. These wizards would be assigned to menu items and stored as scripts when the program is saved.