3D Modeling by means of JavaBeans
E.M.Grinkrug
Department of Software Engineering
Moscow State University – Higher School of Economics
Moscow, Russia
e-mail: [email protected]
Abstract1
The paper presents JavaBeans component model
usage to implement 3D modeling and visualization
in Java. An extensible subset of Virtual Reality
Modeling Language is implemented as lightweight
JavaBeans library that can be used in Java Applets
and applications. The architectural approach used to
build the library is described and illustrated.
Keywords: Virtual Reality Modeling Language, 3D
applet, JavaBeans.
1. Introduction
This paper describes the use of the JavaBeans component
model in 3D-modeling – specifically, we discuss how to
support 3D-models creation, behavior and visualization
by means of JavaBeans components.
According to [1], last years Java programming language
is the leading programming language because of its
popularity. Many 3D-modeling tools and products are
implemented in Java. The Java programming community
has developed Java3D library [2] that supports 3Dobjects behavior and visualization, but the Java3D library
suffers from some disadvantages, namely: it is
significantly large, it is not fully documented (mainly, in
multi-threading point of view), and does not fully
correspond to the main multi-platform principle of the
Java machine, performing rendering by OpenGL or
DyrectX.
We present the implementation of 3D-modeling tools
using standard JavaBeans-components and propose an
approach to enhance the abilities for existing 3Dmodeling languages by means of the components usage.
As a starting point in our discussion, we use a subset of
basic node types found in Virtual Reality Modeling
Language (VRML) [3], that is the ISO-standard. The
subset of object types, that is similar to those of VRML
node types, is extended with new supplementary object
Proceedings of the 12th international workshop on
computer science and information technologies
CSIT’2010, Moscow – Saint-Petersburg, Russia, 2010
types aimed at enhancing our abilities for 3D-modeling
and visualization.
As a practical result of our work, we have developed the
extensible JavaBeans-components library that can be used
in any JavaBeans-components container, similar to BDK
[4, 5] in its ability to create, run, customize, and visualize
various 3D-models. The library can be used to create Java
applets and applications, that use 3D-models
visualization, without any need for additional plugins and
installations.
We did not have a goal of implementing the support in its
entirety for VRML and/or X3D (its successor language,
based on XML-syntax) [6], according to their standards.
The subset of their functional means, being extended with
new components and implementation principles, is
suitable for our discussion of JavaBeans-components
usage for 3D-modeling and visualization, for estimation
of the advantages and disadvantages of the approach we
used, and for practical applications of the component
library created.
2. 3D Modeling
As it was pointed out by one of the VRML creators [7],
“Java and VRML are perfect complements. Java is all
about how things behave but says very little about how
they appear. VRML is all about appearances, without
speaking to how things behave. You could say that
VRML is, while Java does.They need each other”.
The usage of the most popular JavaBeans component
model for 3D-modeling is not represented enough in
existing literature and Java programming practice.
Java3D library and X3D implementation Xj3D, based on
that library [2, 8], do not pay enough attention to the
component-oriented
issues.
Standard
VRML
implementations can support Java API of two kinds:
External Authoring Interface (EAI) and Script Authoring
Interface (SAI). EAI provides for external control over
the 3D-models, that are incapsulated in a VRML Browser
notion. SAI allows to have Java-implemented nodes in
VRML scene graph, that are to be inherited from the
abstract Script base class to participate in the scene
behavior. Limited abilities for Java-programs to
manipulate with 3D-models and their visualization in
Workshop on computer science and information technologies CSIT’2010, Moscow – Saint-Petersburg, Russia, 2010
1
standard VRML browsers are rooted in non-Java
implementations of the browsers. Existing Javaimplementations of different VRML subsets are aimed to
solve just a practical task of the 3D-models visualization
in Java-applets (e.g. BS Contact J3D applet [9]), or use
some proprietary component model (as in Demicron
WireFusion [10]). Usually, only the whole visualized 3Dmodel can be made acccessible as a JavaBeans
component. Last time JavaFX platform for Rich Internet
Applications [11] was developed. JavaFX Script [12] –
the declarative language for GUI description seems to be
close ideologically with VRML, but is compiled into
Java-bytecodes. So far, there are no attempts to have 3Dmodeling and visualization abilities in JavaFX, apart from
Java3D usage [13].
In VRML 3D-model is defined by directed acyclic graph
(DAG) of Node-objects. Node-object is an instance of
one of the predefined base types and/or an instance of
user-defined type. There are two ways to define new node
type in VRML: 1) – by use of script nodes providing their
implementation codes (in Java or JavaScript language,
according to VRML Standard), and 2) – by defining
composed node types (prototypes in VRML terms), that
are composed using previously defined node types. Each
node instance contains a set of typed fields, where all
field types are predefined in VRML Standard and can be
classified as scalar or vector types. There are field types
that allow to hold references to another node instances,
and that is how graph of the model (scene graph in
VRML terms) is defined. The graph must be traversable,
i.e. must be a DAG. It should not necessary be a tree
since it can contain nodes (or subgraphs) referrenced
(shared) by two or more nodes. That feature allows for
sharing the same data in different contects and for
optimizing the size of declarative descriptions in
transferred files. All node types are classified according
to their goals and usage: there are geometry description
nodes, visual features description nodes, sensor nodes,
etc. Some nodes directly determine 3D-model
visualization result, while others do that implicitly or are
not used for visualization at all.
Fields in a node instance are defined by the node type. A
field can contain a value of the predefined type and can
be used for input only (eventIn in VRML terms), output
only (eventOut, generating event when assigned) or for
both of that access types. Apart from nodes graph, there
can be event routes graph defined in a model. The event
from output field of a node can be routed (in unicast or
multicast manner) to input field(s), provided the types of
output and input fields are compatible.
3. Implementing 3D-models using JavaBeans
Now we consider the description of 3D-model, its
behavior and visualization by means of JavaBeanscomponents. We decribe the implementation principles
and discuss their advantages and disadvantages.
3D Modeling by means of JavaBeans
2
In the implementation under discussion, each node type is
implementaed as JavaBean-component to be instantiable
in standard BeanBox container (e.g. the one from
BDK1.1 [5]). Named field of the node corresponds to the
JavaBean property having the same name and the proper
value type. The properties have correspondent setters
and/or getters and are described using JavaBean
PropertyDescriptors (or IndexedPropertyDescriptors) that
standard JavaBeans introspection provides. The event
passing and propagation is supported by implementing
eventOut(s)
as
bound
properties,
generating
PropertyChangeEvent(s). The Route notion of VRML is
implemented as property change event adaptor.
Doing that way, we diverge from VRML rules slightly
(providing Java API, that is different from EAI and SAI
mentioned above), but we get some useful advantages: no
problems with using graph nodes in Java programming
and ability to use the whole JavaBeans-component related
tools and frameworks (the BeanBox-like instruments). In
particular, it allows for universal implementation of
VRML-files parser, based on JavaBeans-components
abilities. Moreover, we do not impose limitations on
usable node types set and their field types (in contrast
with VRML). BeanBox-like container is readily able to
play a role of a visual tool for modeling, debugging and
testing 3D-models with their visual presentations.
Component-based approach helps to optimize results
deployment by providing acually used components only
(thus minimizing applet size).
A disadvantage of the approach comes from a static
nature of JavaBeans component model, where all
components must be Java classes (created using
compilation or bytecodes generation and loadable by
JVM class loader). There are ways to enhance the
component model so that it becomes possible to define
composed component types declaratively and in objectoriented manner, but detailed discusion of these issues are
beyond the scope of the this paper, where we intentionally
deal with standard JavaBeans component model only.
The object graph of the model consisting from instances
of the correspondent component types, can be built
programmatically, visually (by means of BeanBox-like
container), or it can be read from its declrative
description. Since we deal with serialization and
deserialization of the object graph, all correspondent
means, found in Java, can be used (base Java serialization
and deserialization, XML encoding and decoding, etc.).
We can use JavaBeans-related way to read VRML files,
that makes it possible to import existing VRML-defined
models or use ones exported from 3DSMax, the main 3Ddesigners tool, having VRML export features.
4. Parser for VRML subset
There are various ways to deserialize a model into
JavaBeans-components instances graph from its
declarative description (e.g. from VRML-file). The
simpliest way is to implement correspondent method in
each JavaBean component, but it requires predefined
interafce implementation, that is a limitation by itself and
increases the size of each component implementation.
Starting from JDK 1.4, objects composed from JavaBeans
components instances can be serialized/deserialized with
XMLEncoder/XMLDecoder without having to implement
special methods in the components themselves [14]. That
mechanism (as a whole JavaBeans component model) is
based on reflection features and expects that components
provide getters (for serialization) and setters (for
deserialization) for all the properties of the components.
XMLDecoder expects that XML-file to be read contains
encoded sequence of actions to be pereformed for having
deserialized object in memory. XML-file in that case is
much more verbose than VRML-encoded file, since the
latter contains not the actions to do, but the resulting state
of the graph.
To read the model graph, consisting of JavaBeans
compolnent instances, from a VRML-file we use another
universal way to implement VRML subset parser. The
parser is managed by the sourse VRML text and by the
structure of the JavaBeans components. Sourse text is
read to get a node type name, find a correspondent
JavaBean component and instantiate it. Then, the loop of
reading name-value pairs in the node declaration scope is
performed. Each name is treated as a propertyName,
having a property value type from the correspondent
JavaBean’s property descriptor. The value for the
property name is read as the value of that type, and is
used as the correspondent property setter’s parameter.
That means – the value reading is controlled by the
correspondent property value type; array values (for
indexed properties) are read by the loop, that knows
elements type for the indexed property.
Values of known property types are read:

by getting primitive Java types values from strings;

by reding values to be used as parameters to call a
constructor that returns the value to be set for a
property (and each value is read by recursive usage
of the procedure);

by recursive usage of the whole procedure written
above, in case the property value has the type of
JavaBean component representing a graph node.
The parser maintains a table of named graph nodes (to
support DEF/USE VRML semantics similar to the idref
construct of XML) used to implement sharing of the
named component instances in multiple contexts, and
creates ROUTE objects as property change events
adaptors.
This parser organization is universal enough (it uses
nothing except standard JavaBeans related metainformation), is compact, and serves for reading any
DAG composable from extendable set of JavaBeans
components instances.
5. Model and its behavior
The model graph is represented by the instance of
container, that encapsulates JavaBean-components
instances implementing, in particular, VRML nodes. We
use two kinds of containers (that are JavaBeans
components by themselves). SpaceContainer defines 3Dspace with its coordinate system (and it is inherited from
JavaBean Transform that corresponds to theTransform
node of VRML). ActiveSpaceContainer adds a time
related functionality to the SpaceContainer notion (it
defines dynamics of the model behavior in its separate
thread of control). For instance, the thread is used to
support VRML TimeSensors used in the model to
implement time based behavior (animation). It serves as
notion of 3Dspace-time).
Usually VRML-browser implementations are based on
sequential architecture, having a loop that consists of
event-cascade execution (forced initially by some sensors
in the model), updating state of the model graph and
traversing the graph (may be mutiple times) to render it
for 3D visualization. Each traversing pass builds stack
that contains context-related information that is needed
for calculations (e.g. for 3D-rendering).
When implementing a model by JavaBeans components,
we use explicit context tree that is built for the model
graph nodes. In a working model, each model graph node
has its contexts that are organized into context trees. The
context tree is rooted from the container instance and
reflects all the model graph topology changes, being in
correspondence with the graph. This approach helps to
optimize time needed to build a stack with related
context-dependent information while traversing the graph
on each pass (by cost of some memory expenses that
seems to be reasonable for Java implementation).
Moreover, the context tree has its natural geometry
interpretation: vertexes of triangles in 3D-surface are all
contexts of points defining the surface (neighboring
triangles share common points). Each context-tree node
has a reference to the graph node (the one whose context
it represents), a reference to its parent context and a set of
references to its child contexts, if any.
In the current component library implementation, to build
the context-tree for the given DAG, each component, that
expects context-related feaatures, can be asked to create
its context instance (for a given parent context). Each
context-tree node (an object of type inherited from base
NodeContext) binds the graph node context with its
parent and child contexts. The reference used for binding
can be “sensitive reference”: when it refer to an object
that can change its state, the reference gets notification on
that change (and thus takes part in property change events
propagation, intiated from an event cascade used to
support the model behavior in a model graph).
Concrete NodeContext implementations for a base
components are defined by the components specifics. For
example, Transform component (corresponding to the
Workshop on computer science and information technologies CSIT’2010, Moscow – Saint-Petersburg, Russia, 2010
3
Transform
VRML
node)
has
correspondent
TransformContext, and its instance in the context-tree
contains coordinates transformation matrix relative to the
root (world) coordinate system. Similar correspondent
context types are provided by all components that expect
their behavior and/or visualization dependent on contextdependent data (that otherwaise are to be collected while
traversing the model graph). On other hand, context
independent components can omit their participation in
context-tree or just limit themselves with the base
functionality of the NodeContext. The presence of the
context-tree helps to control model graph acyclicity
requirement when the model graph topology is changing
dynamically (with correspondent corrections of the
context-tree).
The model behavior is supported by event-driven
calculations in the model graph nodes, implemented as
JavaBeans-component instances, that accept and
propagate property change events along established event
routes. Initial stimulus for the event cascade propagation
is an instance of some sensor component, generated the
initial event. Event propagation is implemented by
binding properties of component instances, and exit from
the event cascade execution is controlled by standard
property change events propagation rules for JavaBeans
components (new event is generated only when the
property value changes). All JavaBeans-components for a
model graph nodes are implemented to be thread-safe;
synchronized accessor methods are used for all their
properties. ActiveSpaceContainer instance has its own
thread, that can be started to represent separate time flow
in the (3D) space of the container. An object of a model
can be used not only in different contexts of a given
container instance, but in different container instances as
well (may be, having their own threads of control).
Thread safe implementation ensures correct model
behavior and visualization under all circumstances.
6. Model visualization
The root of the context-tree for a scene graph is the
context of the root container (scene graph container). This
context-tree represents the instance of the whole model
with its behavior in the container instance in accordabce
with event routing graph. Each context-tree can provide
its view for further use, rendering and visualization. So, a
kind of model-view-controller approach is applied for
3D-modeling and visualization.
To depict 3D-view on a screen JavaBean Viewer is used.
Different kind of viewers can be used in componentbased manner (as different TV sets can be used to see TV
channels). Currenltly, we use Viewer component
implementation
in
pure
Java
(while
other
implementations, based on OpenGL or DyrectX, are also
possible). The Viewer component is java.awt –
component, that can be used in Java application GUI
and/or in applets. Each Viewer instance has the camera
object, connected with it, and there are rules to bind
3D Modeling by means of JavaBeans
4
VRML Viewpoint instance with the camera, that extend
VRML rules, aimed for that purpose, since VRML cannot
support multiple views on the scene. Each Viewer
instance has its own behavior (implemented in separate
thread) that can be separately turned on and off (like real
TV set). To link the model with the viewer, the latter
must be given a reference to the former. Having a
reference to the model container instance, the Viewer
instance creates its own view on the model instance. The
view in the Viewer is implemented as a tree of views for
the context-tree nodes (each veiw in the view-tree is
inherited from NodeContextVeiw class). But the root of
the view-tree in the Viewer instance is bound with
Viewpoint context selected (3D-view calculations are
performed relative to the camera position, that is defined
by Viewpoint data).
Building the view-tree (SpaceContainerContextView) is
similar to the context-tree creation for the container
content. The view tree nodes are instantiated by
correspondent graph node context classes, and each view
has a reference to its creator, the node graph context.
Naming convention is used in the implementation: if
Node is model graph component name, then its context
type is NodeContext and the type of its view in the viewtree is NodeContextView. In this terms, the root of the
view tree is always represented by the object of type
ViewpointContextView.
Each Viewer instance behavior, that is aimed to provide
correspondent view calculations, rendering and
visualization of the model, plays a role of data consumer
from context-tree, while the model behavior (in the model
graph container instance) is working as new data
producer. The involved threads synchronization is
organized accordingly.
JavaBean-component Viewer performs calculations
needed for 3D-renedering on its own view-tree, that is
updated upon change notifications signalled from
context-tree elements (that are notified themselves when
properties of the model graph node instances are
changed). Rendering then is performed using the updated
view-tree. Different viewer component implementations
can be used and work in parallel (like different TV-sets
can show movies).
There is another component (invisible viewer) that can
produce rendered images as pixels arrays in memory.
This result of this rendering can be utilised as the texture
used in the model itself (e.g. to implement mirrows).
Component-based approach helps to extend the
nomenclature of Viewer components available, adding
JavaBeans with different rendering implementations (just
like designing different TV-set devices having different
internal structure and quality requirements).
The component-based approach supports different usage
scenarios for existing components and helps to implement
these scenarios visually in the standard JavaBeanscomponents container. Below we illustrate the
components usage in BeanBox environment from the
BDK.
7. An example
JavaBeans-components library created can be used to
build 3D-models with their visualizations directly in
standard BeanBox tool.
Fig 1. Three container and four Viewer instances
The example on Fig. 1 shows the BeanBox that contains
three ActiveSpaceContainer instances, each with its own
Start-button. The first instance contains loaded VRMLfile with the butterfly model (geometry and behavior).
This instance is bound with the two Viewer instances
(screens on the left), that depict the butterfly model
behavior from different viewpoints (in parallel).
The second container instance holds VRML-defined
model of the flower with its behavior (the flower blooms
periodically). This model is visualized on the top right
Viewer instance bound to it.
Finally, the third container instance is composed from the
first and the second container instances themselves. The
behavior of the third container instance is achieved as
aggregated behaviors of the first and the second. We can
see the rendered results of this composed model on the
forth screen (the bottom right Viewer instance), where the
butterfly and the flower models are visualized together.
All manipulations needed to build all this 3D-models and
their visualizations were done visually and interactively
by means of standard JavaBeans tool, the BeanBox from
BDK.
8. Conclusion
Component-oriented programming is the progressive
direction of software engineering [15. 16, 17], that helps
to move from line-by-line coding to industrial software
development way and to establish new markets of
software components, like it was done in hardware
engineering areas. Developing new component models
and their standardization are of great importance on that
way.
Component-oriented programming is about building
software systems from prebuilt program components.
There are two main activities invilved: first is reusable
software components development, and second is
developing software systems using the existing reusable
components. The JavaBeans component model approach
corresponds to this idelogy in general. But JavaBeans
component model does not support building new
components from preexeisting ones in a flexible, dynamic
way: new components come only from compilation
and/or bytecode generation. The BDK cannot populate its
toolbox (a set of the components available) without
having to load a set of compiled JavaBeans
implementation classes.
On other hand, VRML expects the ability to define new,
user defined node types, using PROTO (and
EXTERNPROTO) constructs. At the same time,
semantics of that constructs does not correspond to some
principles of class-based object-oriented programming.
There were some attempts to evolve VRML in that
direction in the literature [18, 19] from the very
beginning, but these attempts still need to be continued.
In this paper we have excluded these issues from our
discussion, and that is why we deal with VRML subset so
far in this work with JavaBeans components.
To support dynamic abilities for composed component
types definition (without the need to perform compilation
or bytecode generation in all cases) having a set of
predefined reusable components, some improvements to
JavaBeans component model is needed, that extend its
abilities for composition/decomposition. Correspondent
improvements are to be done for containers and tools that
help to manipulate components, as well.Research and
development in that direction are subjects of the future
work.
References
1. Programming Community Index for June2010.
http://www.tiobe.com/index.php/content/paperinfo/tpc
i/index.html
2. Java3D. https://java3d.dev.java.net/
3. ISO/IEC 14772-1:1997 and ISO/IEC 14772-2:2004
Virtual Reality Modeling Language (VRML),
http://www.web3d.org/x3d/specifications/vrml/
4. Sun Microsystems. JavaBeans Specification v1.0.1,
July 1997.
http://java.sun.com/javase/technologies/desktop/javab
eans/docs/spec.html
5. Bean Development Kit. http://life.csu.edu.au/javatut/javabeans/index.html
6. X3D Specification.
http://www.web3d.org/x3d/specifications/
7. Mark Pesce. VRML-Browsing and
Cyberspace, New Riders Publishing, 1995.
Building
8. Xj3D. http://www.xj3d.org/
Workshop on computer science and information technologies CSIT’2010, Moscow – Saint-Petersburg, Russia, 2010
5
9. BS Contact J.
http://www.bitmanagement.de/en/products/interactive3d-clients/bs-contact-j
10. Demicron WireFusion. http://www.demicron.com/
11. JavaFX. http://www.javafx.com/
12. Weaver, James L., JavaFX Script: Dynamic Java
Scripting for Rich Internet/Client-side Applications,
Apress, 2007.
13. 3D with JavaFX.
http://learnjavafx.typepad.com/weblog/3d-withjavafx/
14. Long Term Persistence of JavaBeans Components:
XML Schema.
http://java.sun.com/products/jfc/tsc/articles/persistenc
e3/
15. Szyperski, C., Component Software - Beyond ObjectOriented Programming. Reading, Massachusetts:
Addison-Wesley, 1998.
16. Clemens Szyperski,Dominik Gruntz,Stephan Murer.
Component
software: beyond object-oriented
programming. ACM Press, Second Edition, 2002.
17. Wang,
Andy
Ju
An.,
Component-oriented
programming / Andy Ju An Wang & Kai Qian. John
Wiley & Sons, Inc., Hoboken, New Jersey, 2005.
18. Curtis Beeson. An Object-Oriented Approach To
VRML Development. Silicon Graphics Inc.
19. Stephan Diehl. VRML++: A Language for ObjectOriented Virtual-RealityModels, Proceedings of the
24th International Conference on Technology of
Object-Oriented Languages and Systems TOOLS
Asia, Bejing, 1997.
3D Modeling by means of JavaBeans
6