Introduction

Modelzilla is a modeling and visualization framework for the purpose of reducing development time of physical modeling and visualization applications, and enabling integration of applications that use the framework. It is loved by both programmers and users, although the Japanese fear it. Here we describe how to develop applications with Modelzilla, after some general introduction and praise.

Advantages to end users

Users of Modelzilla enjoy several advantages as opposed to using standalone three-dimensional graphics programs. Modelzilla has no large disadvantages compared to a standalone system, because we have worked so hard to make the framework as versatile as possible. Users enjoy these advantages:

Integration of graphics

Graphics created by different application modules are rendered in a common view-port. This can be a convenient for someone dealing with information coming from a variety of sources, or models of a variety of ideas. And it can makes is possible to generate images that are not possible to generate with multiple separate applications. Suppose you are trying to compose in image that has a depiction of a large molecule, a depiction of some volumetric data, and a depiction of an imagined virus. Say the molecule is one of the proteins forming the virus capsid, and the volumetric data is electrostatic potential guiding the protein into position. Suppose you use completely separate programs to generate a picture of each, and try to combine the pictures into one that shows how each object interacts in 3D space. Each picture will have to be from the same viewpoint and use the same projection, and you will have to somehow be able to properly overlay the pictures including the depth information, so that pieces of objects in front properly overlay objects in the back. You would be lucky to find a three-dimensional graphics application can output graphics as well as depth information for compositing. Doing this composition in image space is nearly impossible. Another option is that each program can output the 3D information that used to generate the 2D picture as 3D triangles, lines and points. You could then use a fourth program to read in this information and generate a picture. This will work as long as each of your programs can output the same 3D information readable by the fourth. Unlikely.

Applications that use the Modelzilla framework enjoy this graphics composition ability as a natural property of the system. All applications run in the same process and direct their graphics to the same view-port. Some one using this software interactively may then generate their picture much more easily than by using three totally separate programs. They may adjust their volumetric data depiction to fit their molecule. They can move around their imagined virus and adjust the construction of its capsid to make their idea look feasible. And they can do all of this interactively within the same virtual universe.

Integration of geometry

It was a simplification when we stated Modelzilla applications "draw to the same view-port". In fact, Modelzilla has a geometrical expression language that applications use to define the directly geometrical manifestation of what ever they are designed to model or visualize. These geometries are then rendered to the view-port by the framework. Because this intermediate geometry expression system sits between the applications and the graphics, geometry becomes a medium for application integration. Although applications are not aware of one another directly (unless the developer deliberately writes one Modelzilla application as an extension to another) they are able to acquire the geometry associate with a certain object and either generate more geometry using this geometry as input, or modify the geometry in place.

For example, CAD-Zilla (a geometrical modeler application) can do solid booean operations on geometries created by any other application, like operating on a molecular surface generated by VincentVanMol (a molecular graphics application). CAD-Zilla can also be used to define the extrusion section VincentVanMol uses to generate its ribbon depiction of proteins. GridZilla (a volumetric data visualization application) can do surface color mapping onto any geometry, like mapping an electrostatic potential grid onto a molecular surface generated by VincentVanMol, or mapping a result of stress analysis or heat transfer calculation on to an engineering part created with CAD-Zilla. GridZilla can also do volumetric operations on grids, like assigning each volumetric data point within a surface generated by CAD-Zilla or VincentVanMol to a new value.

Integration of user input data

Modelzilla has a facility for keeping all user input data in a general database. This facility is the central nervous system of the system. A properly written application keeps all direct user input in the Modelzilla database. This includes information that the user considers his or her specification of the model, like the radius of a circle, the color of an atom, the location and element of an atom, or the filename of some volumetric data. Applications then compute derived information from the data they keep in the database, like a circle's polygonal geometry from the radius, a molecular surface geometry from atomic information, or an iso-contour from volumetric data. (Note it is up to the application designer what information will be kept in the database. For example the VincentVanMol application could keep only a molecular definition filename in the database and keep the molecular information in its own specialized data structures that have nothing to do with the Modelzilla database, or it could read the molecular definition file and transfer this information to the database.) The database is a network of data nodes with an overlying tree like organization. All data big and small fits within the database, be it a node to hold a scalar value or a node to define a molecular surface. Nodes can keep variables internally or can be parameterized by input nodes.

The Modelzilla database facilitates communication within and between application modules. A database is controlled by interactive use or changes can be scripted. These nodes may be leaves (which require no further specification) or branch points to more database nodes. The derived state of a data node is computed according to the values of its input nodes. Its derived data state is stored internally via its own specialized means. A data node presents its output (the relevant information for nodes it is the input to) either by virtue of being a special type with known properties to the nodes it is input to, or by registering a set of output data types. The database management code knows which nodes are dependant on which other nodes. It asks the nodes to compute their state in an order such the state of the input nodes is computed before the state of nodes that are its input. The specialized user interface a Modelzilla application put the wishes of the user into effect by controlling nodes in the database. The application defined nodes than carry out the work of generating geometry, reading files, or generally making the users input take effect in the model.

An application that properly keeps its user input data in the database benefits from a number of services that come with the framework.

The most crucial is Modelzilla's ability to save and load the entire database in an XML file. (The files with the .MVG extension. MVG stands for Modelzilla Virtual Graphics. Or maybe it means Modelzilla's very good.) When the file is opened, the database management simply does the normal state validation procedure, causing the model to be regenerated exactly as the user left it.
Because the entire application state is derivable from the situation in the Modelzilla database, undo/redo is as simple as recording the previous user input state of a node before changing, adding, or removing it. These state changes are kept in a stack that is easily managed by the Modelzilla undo/redo service.
We are planning on writing an animator application (the Animazillator) that can interpolate the state of any set of nodes in the database over time. The model should than be recomputed automatically. This is another example of an application module effecting the operations of other applications that it is not aware of by exact identity.
The Modelzilla selection system is based on building a selection set of nodes in the database. Usually this is the level the user needs to select with. Applications are free to implement their own selection system for objects foreign to the database.
The database allows the user to copy, delete, do deep assignments and make links in a uniform way.

A common user interface for common needs

Modelzilla comes with a standard user interface that handles many tasks needed by anyone doing a three-dimensional graphics. People using Modelzilla applications won't have to re-learn how to use these common tasks. These tasks include view point transformations, object transformations, input of common types of data, management of light sources and clipping planes, the undo system, the object selection system, and export utilities.

Advantages to programmers

An application written to use the Modelzilla framework will have a broader use than standalone applications because users are able to use other Modelzilla applications in one universe to do things more easily or couldn't other wise do at all. Your application is more valuable to people if it has friends in high places.

Modelzilla already handles the most tedious graphics programming. It handles dependencies between elements of the model. It handles file saving/opening. It handles undo/redo. It handles some common user interface needs. Over Modelzilla we have written a nice CAD program in about 25 thousand lines, a molecular graphics program in about 20 thousand lines, a volumetric visualizer in about 15 thousand lines, and various quickie programs for people around the lab. Considering "we" at the time of the writing is one person, that's a pretty efficient use of programming effort.

The Modelzilla framework is written in JAVA, the best systems language known to man.

Overview of programming with Modelzilla

A Modelzilla application is a graphical user interface that controls database nodes in response to user input. The database nodes then compute geometries or otherwise compute the users desires according to the user input they are holding. The computations are usually rendered in a 3D "geometry viewer" view-port.

Differences with programming for AVS

Modelzilla is roughly based on the model of AVS (or possibly OpenDX). Some differences with AVS are:

Modelzilla applications run in the same process as the framework, as opposed to AVS which starts up compute processes which die when finished. This affords many conveniences described below.
Modelzilla applications are in control of the framework rather than the framework controlling them. It's hard to be control if you keep dying and being reborn.
Modelzilla applications can have user interfaces that are totally independent of the framework. An application normally builds a specialized user interface that is convenient for presenting and controlling the user input it requires. An application is free to use some of the user interface components for controlling data nodes that come with Modelzilla too.
Modelzilla applications are bigger than AVS "modules". Modelzilla applications are in fact officially called "application modules". AVS has a more fine grained approach to module invocation that says every type of operator or object is a separate "module". Modelzilla application modules are like bundles of independent operators and objects (each expressed as a database node of a type defined by the application module) that come with a common user interface to make all these little modules easy to use.
Modelzilla applications are as easy to use as monolithic applications. Nothing in AVS is easy.
Modelzilla applications run on Windows, Linux, Solaris and MacOS at least 10.3 without "if defs" or recompilations at all.
The Modelzilla database holds any type of information, where as the AVS network has only the big operators and objects. The Modelzilla database will typically have thousands of nodes, where as the AVS network will have a couple dozen. In fact, AVS modules really have no way to store user input persistently except by kludgey means like writing special files. This is why user input in AVS is rather un-detailed.
Modelzilla does not have built in volumetric data visualization. It does have an application module, GridZilla, for this. Modelzilla is more general than AVS.
Modelzilla applications can use interactive mouse input from the view-port trivially.
Modelzilla does not require the user directly access its network data structure, because the application module user interfaces handle this for the user. AVS requires the user control the program through the network editor. (Modelzilla does have a network editor for advanced users.)

Differences with programming a monolithic application

In Modelzilla the programmer normally does render directly into the graphics context. The programmer creates geometries that are rendered to the graphics context by the framework. The framework actually uses a pluggable scene rendering unit, enabling to generate images using OpenGL, Java2D, or in the past Java3D. In the future the framework may acquire the ability give the application developer a hook to render an object directly into the rendering context. This would not be without cost, however. An object rendered strait from user input to the graphics context would not useable in geometrical operations offered by various application modules. And such an object would be invisible in geometrical exports, such as a POV-Ray scene dump or a VRML scene dump.

In Modelzilla the programmer is not supposed to keep user input data outside the database. Now, if the data is not something that is designed to persist in a model file, or the entire goal of the application is to do file conversions, than of course the application is free to keep its input however it wants. The application might even have its own independent database system. In this case the application would have to monitor changes to its special data model and make changes to the situation in the view-port accordingly. It could make changes to the view-port by directly communicating with the Viewer Core layer. A GUI user would then unfortunately not be able to select and deal with these objects in the usual manner. The application would have to handle this too. Or the application could keep a small presence in the Modelzilla database for the purpose of making its objects accessible to the user and other applications in the normal way.

A Modelzilla application does not have a main function. It has an initialization class invoked by the user or automatically once the framework has been started.

Layered architecture

The Modelzilla framework is organized into independently reusable packages, in a layered organization such that each layer requires the code in the layers below it, but not above it. And some packages are independent of any layer. Specifically, the main three layers in the framework are from lowest to highest:

geometry storage and operations
graphical rendering of geometry
user input/output machine
Modelzilla applications are built over the first three layers

The widget library used by Modelzilla may be used separately, as well as the Molecular Data Structure library.

This kind of organization is all too rare in these days. Improperly designed code will mix the graphics rendering code in with the geometry building code. The user input information might be kept in the user interface components as well, creating a tangled web of dependencies. Connecting every element of the program to every other makes it harder to keep everything in the program working properly because ideas are intertwined. The layered architecture has these advantages:

Lower level layers may be reused in other systems without including the higher layers.
Making changes to code in higher level layers cannot break lower level layer operations.
Generally the layers communicate through well defined channels that hide internal details from each other.
The layered organization also speeds compile times because dependencies go only one way.
Each layer forms a small API that is easy to digest.