Jinseok Seo, Deok-Nam Kim and Gerard Jounghyun Kim ... reasonably nice abstractions, and software reuse at the functional level is reasonable well practiced.
VR Object Reuse through Component Combination Jinseok Seo, Deok-Nam Kim and Gerard Jounghyun Kim Virtual Reality Laboratory Dept. of Computer Science and Engineering Pohang University of Science and Technology (POSTECH) San 31, Hyoja-dong, Pohang, Kyungbuk, Korea Email: {jsseo, dnkim, gkim}@postech.ac.kr
Abstract Code and object reuse is a big concern for fast and efficient Virtual Reality (VR) system development and continual maintenance. Many commercial and academic VR packages offer reasonably nice abstractions for various functionalities needed by general VR systems such as the scene management, device integration, performance monitoring and LOD, objectorientation support, event processing, etc. [3][7][12][13]. In other words, software reuse at the functional level is reasonably well practiced. Many geometric models in various file formats are easily found for reuse by public access on the WWW, and there even exist commercial web sites and companies selling reusable 3D models.
In practice, however,
these models are mostly used for static, incidental, and decorative objects, and rarely for the main “characters” that possess dynamic behavior.
This is because the main “character”
objects usually exhibit behaviors “incompatible” with, for instance, the way the geometric model (obtained from the library) is organized. Kim et al. have proposed a structured process for VR application development based on the idea of clear distinction between form, function and behavior (and their relations) in specifying VR objects [4].
This concept
naturally lends to a reuse method at the level of form, function and behavior (which could be objects themselves). That is, new objects can be created by extending existing objects or mixing and matching different forms, functions and behaviors. Therefore, such a method requires, for a given particular domain, that the domain analysis identify useful reusable “components” at this level and consider conditions (or compatibility) by which form, function or behavior can be combined later. This paper explores a method for designing VR objects through concurrent consideration of their form, function and behavior, and extending this idea to a component reuse method with more flexibility and significance.
1 Introduction Developing and maintaining virtual reality applications take much time and effort, and big part of it has to do with the continual need of trying out number of content alternatives and interaction methods, and therefore, introducing new objects. Many 3D graphic contents and virtual reality applications contain real life objects (e.g. human characters, creatures, animals, machines, furnitures, buildings, etc.) and interaction objects (e.g. rays, menus, virtual hands, etc.). While these objects may differ in their visual form for each application, they still share “similar” geometric structure, functionality and behavior (e.g. a desk lamp in one application would not be that different from another desk lamp in another application), and therefore, there seems much room for the usual notion of the “object” level reuse (with slight extension and modification). On the functional side, many commercial and academic VR packages already offer reasonably nice abstractions, and software reuse at the functional level is reasonable well practiced. With the help of these packages, one can develop systems without consideration of implementation details for the functionalities such as scene-graph construction, viewpoint control, device integration and so on. Many geometric models in various file formats are easily found for reuse by public access on the WWW and there even exist commercial web sites and companies selling 3D models.
In practice, however, these models are mostly used
for static, incidental, and decorative objects, and rarely for the main “characters” that possess dynamic behavior. This is because the main “character” objects usually exhibit behaviors “incompatible” with, for instance, the way the geometric model (obtained from the library) is organized.
Or, put it differently, the information regarding the relationships among these
geometric, functional or behavioral components is not available for effective reuse. The authors of this paper have previously proposed a structured process for VR application development, called “CLEVR (Concurrent and Level by Level Development of VR Systems)”, based on, among many, the idea of clear distinction between form, function and behavior (and their relations) in specifying VR objects [4][9]. In short, form refers to the outer appearance and physical attributes of a virtual object and its structure (for composite objects).
Function refers to primitive actions required for the virtual object to carry out high
level behaviors, while behavior refers to how a virtual object dynamically changes and use low level functions over some period of time.
Applying this old software engineering
principle of “separation of views” naturally lends to a reuse method at the level of form, function and behavior (which could be object themselves). That is, new objects can be created by extending existing objects or mixing and matching different forms, functions and
behaviors. Therefore, such a method requires, for a given particular domain, that the domain analysis identify useful reusable “components” at this level and consider conditions (or compatibility) by which form, function or behavior can be combined later.
This paper
explores a structured method for designing VR objects through concurrent consideration of their form, function and behavior, and extending this idea to a component composition reuse method that is more flexible (e.g. mutate new object), and have wider applicability (e.g. generate similar object) across different VR applications than just reusing at the whole object level. We illustrate our approach (and a supporting tool called the “CCTV (Component Combination Tool for VR)” by generating mutant/similar Pokemon [6] characters for building simple 3D games.
2 Related Work In the computer graphics and design research communities, the idea of explicitly representing form, behavior, and function and unifying them under a coherent object-oriented framework for construction of “moving” worlds has been proposed numerously over the years and such systems/tools have stated to appear [12][13][14]. systematic development method has emerged yet.
However, no formal framework or
In most cases, developments of real-time
graphics or animation programs, for instance, still proceeds by creating visual objects on computer-aided design (CAD) systems, then using low-level simulation programming constructs or libraries to add behavior [1][7][10][14].
Such software packages allow
relatively easy encoding of the functional/behavioral aspect of the virtual environment, by hiding and abstracting out low level details and providing easy-to-use API's for the programmers, and usually support object-oriented programming, communication with popular VR devices, and importing of various model file formats.
Simulation programs are written
(to fair amounts of detail), compiled, debugged, run, and modified. Such an unstructured development method often results in difficulties in maintaining and tuning such applications. Even with object-oriented graphics packages that are starting to appear in the market and research community [3][13][14], incremental development of graphics/animation applications is yet to be supported in full scale, because those packages focus on ease of programming rather than on ease of modeling. Yet, the popular use of these API’s represent the most prevalent form of software reuse in VR system design. Aside from abstractions for system-wide functionalities, reuse at the content or 3D component level is practiced only in a limited way, mostly in the form of importing prior geometric models. Information other than polygon data (e.g. structure, material, physical properties, etc.) is often
lost in the process due to differences in file formats. Even though a 3D model with the “right” structure is fortunately found with its internal information preserved, it is difficult to find reusable functional or behavioral models to go along with it, and for this reason, 3D models are reused mostly for static decoration objects (e.g. trees, household objects, etc.) or objects with very simple behavior (e.g. rotate, go forward, etc.).
Open Inventor [14]
provides a mechanism called the “Node Kits” for creating groupings of Inventor nodes, in other words, a reusable object description for various attributes with shape, material, motion hierarchy, interactive behavior, etc. While the Node Kit mechanism is good for reusing an abstracted group of nodes “as is”, its tightly coupled nature makes it difficult for users to adapt/modify it for a given application domain. Alice [1] also provides predefined set of functions applicable for any generic objects, that can be reused to create high-level behaviors. These functions, to be generic, however, are not tied to any particular geometric structure, thus, only very simple function/behavior can be reused in this way, in other words, complex functions can not be “combined” with other objects with similar structures.
3 CLEVR / PP-VoT In this section, we first briefly introduce CLEVR, a comprehensive structured methodology for specification or early design of VR systems, the basis of our component reuse method. Aside from the concurrent consideration, yet separate specification of form, function and behavior, CLEVR is also based on the idea of hierarchical and incremental development and simulation. These two major principles are applied to the overall spiral development process (see Figure 1) along which VR objects and the scenes they compose of are designed considering their realism, presence, behavioral correctness, performance, and even usability as early as possible.
Like any software, VR software should be developed in stages and in
an iterative manner and we believe that the earliest iterations will be focused on the usual aspects such as object and feature identification, gross system behavior, user task modeling, and general software architecture. Once this stage of specification matures, the next stage will involve more VR-related aspects, addressing particularly the performance issues as objects and computational modules identified in the first stage gets more refined. Incremental simulation/execution can be applied to validate and revise important object behaviors, predict the approximate performance and make further decisions for process distribution. Once the performance aspect has been treated to a certain degree, the third stage of iterations can address the issues such as improving presence and special effects.
Figure 1 The CLEVR’ CLEVR’s Spiral Model of VR System Development
We believe that, ideally, even a rapid prototyping process should more or less follow the same process in which abstractions and reusable components (at level of form, function and behavior) can be very helpful.
At least, it is quite clear that there exist many parameters to
consider other than just the correct system functionality in producing an acceptable VR software, and the usual notion of object-level library approach to reuse alone may not work very well, because the required system tuning must occur at a lower abstraction level.
For
instance, adjusting the LOD for tuning system performance actually amounts to selecting different behavior or geometric models.
In terms of reuse, it would be much more
economical to store a library of the “lower” level (i.e. form, function, behavior) objects1, hence called components 2 , rather than the higher level objects.
In addition, these
components can be mixed and matched to create entirely new objects, a useful feature in the view of the usual need for continual content updates. CCTV has been built to support the proposed reuse method and belongs to P-VoT (Postech– Virtual reality system develOpment Tools) that represents a collection of tools to support the
1
In this document, an object loosely refers to the usual computational construct, with data and operations
on the data, for describing or abstracting a virtual entity.
It is sometimes interchangeably used with the term
“component”. 2
In this document, a (reusable) component refers to any type of description that is used as a unit of reuse.
However, for a particular implementation, an object model can be used to represent a component.
CLEVR modeling approach.
Among the major functionalities included in P-VoT are the
ways to construct and represent information regarding the form, function, and behavior of a virtual object at different abstraction levels and coalesce them into an executable object oriented form, and to save them for later reuse.
For instance, we use Message Sequence
Diagrams (MSD) to construct various content scenarios specifying for important interactions among objects, and use it to help, complete the class diagram. Statecharts and Dataflow Diagrams (DFD) are used to represent object behaviors and functions respectively, and while a construct called the VOS is used to represent form related information [4].
Figure 2 shows
the modeling process to specify and validate components and merge them into a single object model (specified in the parenthesis are PiVoT tools or constructs used for that stage). CCTV is an environment in which a user can reuse, compose, mix-match, extend, modify these components (or objects) for application to other domains.
Figure 2 The Object Modeling Process in PP-VoT
4 Reuse Method in CLEVR 4.1 Domain Engineering / Component Definition For a carefully chosen domain, a process of domain engineering is carried out first to build a library and hierarchy of components. Domain Engineering is the activity of collecting, organizing, and storing past experience in building systems in a particular domain in the form
of reusable assets and means for reusing these assets when building new systems [2][11]. Thus, the major aim of Domain Engineering is to build reusable components for a family of similar systems.
In CLEVR, a VR component consists of form, function and behavior
models, and they are specified using the constructs called VOS (Visual Object Specification), script languages and Statecharts, respectively.
For later reuse (by selection, composition,
extension, modification and adaptation) in a rapid prototyping context, they are converted into an executable object form, and the resultant components are classified into two groups: spatial objects (objects with geometry and/or function/behavior) and functional objects (objects without any geometry, just function and behavior).
In other words, the component library
contains form, function, behavior objects plus some useful3 combinations of them.
That is,
the component library, L = L1 & L2, where, L1 is a set of form, function, behavior components respectively, and L2 " L1* (a language over L1). In addition to cache-ing these components, conditions (or compatibility) by which they can be combined must be explicitly represented for partially automating the combination process.
Each component, c
L1, may possess one or more conditions, cpi, that
determines its compatibility with other components for composition. That is, a necessary condition for a “composite” element o = c1c2c3 …ck
L1*, where ci
L1, to also be a
valid element of L2, all pj’s (compatibility conditions) of each ci must be resolved with respect to each other.
There are basically two types of compatibility conditions: one purely syntactic
and the other semantic [8].
Syntactic compatibility refers to the requirement that given two
components, ci and cj, their interfaces be syntactically well defined (i.e. existence of the right type/structure of arguments). For instance, for the functional model, “wave hand” to use a particular geometry, the corresponding geometric model must contain a data structure that represents a 3DOF kinematic chain.
If a given behavior component is specified using a
seemingly similar “wave hand” function that requires a boolean argument that indicates whether to wave the hand up and down or right and left, while the “wave hand” function in the library does not specify such detail, they are syntactically incompatible.
During
composition of components, syntactic constraints can be checked automatically. On the other hand, semantic constraints are conditions that require manual interpretation to be resolved (thus can not be completely be checked by simple data type compatibility).
3
We assume that the decision whether to abstract a particular component is made through the manual
process of domain engineering process.
For
instance, a mutual exclusion condition can be defined among two walking behaviors (e.g. “running can not be activated together with walking”), or two geometric components (e.g. “a car can not use cubes for its wheels”). This type of constraints is specified by user supplied predicate functions or by simply recording them in plain text. Figure 3 depicts the overall process of the reuse method in CLEVR.
Figure 3 Overall Process of Reuse Method in CLEVR
4.2 Reusing Components Given a component library, there are several ways to reuse the components to create a new application, namely, selection, composition, and extension/modification/adaptation as shown in Figure 3. The simplest form of reuse is of course simply selecting a component and applying it in the new application without any modification. Although not described in detail, to aid the search process for the right component, the component library must be organized and indexed using the vocabularies of the domain taxonomy and features. A more interesting approach to reuse is the composition: combining various form, function, behavior and/or composite components. The process is in fact same as constructing elements for L2, where L2 " L1* (a language over L1).
Most often, simple selection or composition is not
sufficient to apply the selected or composed component in the new application, that is, certain
customization might be needed.
CCTV allows the user to semi automatically cross check
component compatibility and, extend, modify and adapt the newly selected or composed component (or object) for application deployment.
Furthermore, these objects can be
visualized and executed for verification.
Figure 4 Snapshot of CCTV - Composing Composing different styles and parts of reusable forms, functions and behaviors to create a mutant animation character
(a) Figure 5
(b)
(a) A newly composed character tested in CCTV’ Simulation ion Environment. CCTV’s Simulat (b) The new character used in a Simple 3D game
5 Example: Mutant Pokemons in 3D Games We chose to engineer the domain of Pokemons [6] in hopes of reusing them in any 3D content and to highlight the merits of component composition. As already indicated, 3D contents most often require continual updates, e.g. changing characters, their capabilities, scenes, modifying the scenario, and so on. Therefore, our reuse approach is not only applicable to reusing old objects for different applications, but also useful for continuous upgrades of one
application. Figure 4 shows a snap shot of CCTV that shows a process of combining different styles of limbs, functions/behaviors to create a mutant Pokemon character.
Figure
5a shows the simulation environment for which the mutant object can be tested for its correctness.
Figure 6 Reusable Components in the domain of “Pokemon” Pokemon”
After some analysis, five functional components such as “Move”, “Rotate”, “Jump”, “Fire” and “Detect collision” were chosen to be abstracted as basic functions that most any Pokemons would require. We also defined five geometric components, which were “Body”, “Head”, “Arm”, “Leg”, and “Tail”, and several composite components were identified as well (e.g. “arms with swing behavior”) (See Figure 6).
Figure 5a shows a mutant (previously non
existent) Pokemon constructed using the reusable form, function and behavior components. The relative sizes of the limbs and appropriate behavioral parameters were adjusted for customization through using CCTV. An example compatibility check was made so that a walking behavior did not simultaneously activate the “raise right hand” and “raise left hand” functions.
A check was made to ensure that the swing arm behavior component was
compatible to the arm geometry/structure (a kinematic structure with upper link, lower link and an elbow joint). The completed object specification was translated into C++ code and WorldToolKit API’s. Figure 7 is part of the resultant code for defining the new character in a
different application (e.g. a simple 3D game, see Figure 5b).
Figure 7 Sample Generated Code
6 Conclusions and Future Works In this paper, we presented a reuse method for 3D content creation through both selecting from previously cached object specifications, and mixing and matching form, function and behavior components (previously regarded as sub-object level constructs).
The proposed
reuse method is in fact tied to the wider effort in creating a structured approach to VR system design that is based on the principle of separation of views, concurrent development of form, function, and behavior of virtual objects and hierarchical and incremental modeling.
The feature of mixing and matching form, function, and behavior
components requires specifying or documenting and checking inter-object compatibility conditions, and is a particularly useful feature for the nature of 3D contents that need to be upgraded and maintained on a frequently basis.
Our future plan is to continue to refine
the proposed structured development and reuse method and extend it to address the particular needs of VR systems such as multimodal interaction and usability, presence, and performance tuning.
7 References [1] Carnegie Mellon University, “Alice: Free, Easy, Interactive 3D Graphics for the WWW”, from the World Wide Web: http://www.alice.org, 2000. [2] Krzysztof Czarnecki and Ulrich W. Eisenecker, “Generative Programming: methods, tools, and applications”, Addison-Wesley, 2000. [3] Roger Hubbold et al., “GNU/MAVERIK: A micro kernel for large-scale virtual environments”, Proceedings of the ACM Symposium on Virtual Reality Software and Technology, 66-73, 1999. [4] G. Jounghyun Kim et al., “Software Engineering of Virtual World”. Proceedings of the ACM Symposium on Virtual Reality Software and Technology, 131-139, 1998. [5] Deok-Nam Kim, “Reusing VR objects by mixing and matching form, function and behavior”, Unpublished Master Thesis, Pohang Univ. of Science and Technology, January 2001. [6] Nintendo, “Pokemon World”, from the World Wide Web: http://www.pokemon.com, 2000. [7] Sense8 Corporation, “WorldToolKit Reference Manual”, 1999. [8] Jinseok Seo and Gerard Jounghyun Kim, “Levels of Detail (LOD) Engineering of VR Objects”, Proceedings of ACM Symposium on Virtual Reality Software and Technology, 104-110, 1999. [9] Jinseok Seo and Gerard Jounghyun Kim, “A Structured Approach to Virtual Reality System Design”, Submitted to Presence, 2001. [10] John Rohlf and James Helman, “IRIS Performer: A High Performance Multiprocessing Toolkit for Real-Time 3D Graphics”, Proceedings of the 21st annual conference on Computer graphics, 381-394, 1994. [11] Software Engineering Institute, “Model-Based Software Engineering”, from the World Wide Web: http://www.sei.cmu.edu/mbse/, 1997. [12] Duvvuru Sriram et al., “DICE: An Object-Oriented Programming Environment for Cooperative Engineering Design”, AI in Engineering Design Volume III, pp. 303-366, Academic Press, 1992. [13] Henry Sowizral, Kevin Rushforth, and Michael Deering, “The Java 3D API Specification, Second Edition”, Addison-Wesley, 2000. [14] Josie Wernecke, “The Inventor Mentor: Programming Object-Oriented 3D Graphics with Open Inventor”, Addison Wesley, 1994.
