Three-dimensional Beans – Creating Web Content Using ... - CiteSeerX

Three-dimensional Beans – Creating Web Content Using 3D Components In A 3D Authoring Environment Ralf Dörner, Paul Grimm Fraunhofer Applications Center for Computer Graphics

of 3D content does not lie in the graphics performance of the hardware or dedicated 3D formats but in the complex and effort consuming way an author has to create a three-dimensional scene. Especially the description of the behaviors of the objects in the scene and their connection to the geometric representation proves to be difficult; it can be seldom performed at task level. Furthermore, it is not easy to reuse parts from already created 3D content that are more complex than the sole geometry. In 2D one solution is the well-known concept of components [6]. Components are characterized by reusability, standardization of interfaces and minimal communication between components. Components are often used in frameworks together with specific authoring tools that allow the composition of components without knowing details of their internal implementation. The standardization of interfaces guarantees that components fit together when combined in a specific application. There are component frameworks available today like COM [7] or OpenStep [8], in our context of WWW based applications the Java Beans [9] component architecture is of special interest as it can be used in Applets that may be executed in WWW browsers. The idea discussed in this paper is the extension of this 2D Bean components concept to the third dimension. Unfortunately, the step from 2D to 3D is not straightforward. First, it needs to be defined how the architecture of a 3D Bean looks like and which additional interfaces need to be specified in a way that it can be connected to an other 3D Bean as well as a conventional Bean. In contrast to a 2D Bean it is questionable whether a 3D Bean has one representation in 3D and an additional 2D representation that can be used for combining it with other Beans or whether both are united in one representation. Second, the Bean authoring environment has to be adapted accordingly. In 3D more complex relationships between Beans should be definable on a geometrical level (e.g. attaching objects like the single limbs of a human figure are attached) and on a semantic level (e.g. exchanging events, sharing behaviors, defining hierarchies). The authoring environment should administrate these relationships and should show the effect of changing them immediately. Besides, the user interaction in a three-dimensional authoring environment is also more multifaceted and the visualization of the Bean structure has to take the usual problems like occlusion into account that stem from the projection of the 3D scene to a 2D output media. In this paper a concept of 3D Beans and their authoring environment that addresses these issues is suggested and its advantages are discussed.

ABSTRACT This paper deals with the question how the component idea can be transferred to the authoring of 3D content for the WWW. The concept of 3D Beans and their according authoring environment is presented. In addition, an implementation of this concept using Java3D and Java Beans is described. Advantages of the concept are discussed and illustrated with an application example from the area of computer-based training. Major advantages of the 3D Beans concept are on the one hand that 3D content can be created in a virtual environment more directly and efficiently using prefabricated components that fit together. Especially, as the author is supported by a Bean authoring environment that itself uses information from the 3D Beans. On the other hand, a 3D authoring environment offers more degrees of freedom for authoring component-based applications. CR Categories and Subject Descriptors: H.5.2 [Information Systems]: User Interfaces; I.3.6 [Computer Graphics]: Methodologies and Techniques, D.2.3 [Software Engineering]: Reusable Software. Additional Keywords: Authoring of 3D Web Content, 3D Components, Java3D, Java Beans

1. INTRODUCTION Three-dimensional content is one principal distinguishing feature of WWW based presentations in contrast to traditional print media. Advances in graphics hardware and the fact that 3D standards for the Web like VRML97 [1] emerged made it possible to use 3D content in the Web for several applications like the usage of avatars in virtual chat rooms [2], the visualization of data in 3D [3], three-dimensional user interfaces for information query [4] or virtual environments for training purposes [5]. However, one main obstacle for a widespread usage ________________________________

{doerner, pgrimm}@agc.fhg.de Fraunhofer Applications Center for Computer Graphics Varrentrappstraße 40-42, D60486 Frankfurt / Main, Germany

Permission to make digital or hard copies of part of all of this work or personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or a fee.

The paper is organized as follows: In section 3 the concept of 3D Beans and an according authoring environment is presented. An implementation of this concept using Java3D [10] is described in section 4. Section 5 deals with the applications of 3D Beans and discusses their advantages and

VRML 2000, Monterey, CA USA © ACM 2000 1-58113-211-5/00/02 … $5.00

69

disadvantages. Finally, section 6 contains a summary and issues for future work. We start in section 2 with some background, a description of an application example and how it would be implemented with traditional methods.

together in a virtual environment. The trainees are represented as avatars as well as computer players (that may be modeled as agents). It is possible to navigate in the virtual environment and to interact with the avatars or certain objects like doors, switches or telephones. The purpose of such a training could be to instruct people how to act as a team and how to communicate in emergency situations.

2. BACKGROUND Java Beans are regular Java classes that adhere to a certain naming and parameter convention (e.g. each class has constructors with no parameters, the names of methods that modify the state of an attribute are build with the syllable “set” followed by the attributes name). This allows the introspection of Java Beans from outside, especially from Bean authoring tools. Java Beans use an event listener and registration mechanism to connect two Beans mapping the occurrence of an event in one Bean to the triggering of a method in the other Bean. Serving as Bean authoring environment there are several tools available today, the first one was the Beanbox that is distributed with the Bean Development Kit BDK. This Beanbox consists of a tool window where each Bean is shown that is stored as a Java archive file in a certain directory. Using a drag and drop metaphor Beans can be integrated in the main window, where the Bean is shown in a 2D representation. A so-called property window is used for customizing the Bean. Beans can be connected graphically by clicking on the Beans in the sense that the Beanbox automatically registers one Bean as an event listener of an other Bean. Java Beans themselves do not need to have any certain dimension, i.e. they may be implementing a definite functionality that has no graphical interface at all or they may have a 2D representation. Three-dimensional representations are not common today. In order to integrate the third dimension there are several possibilities. For instance, one can use a Bean with no graphical representation and can loosely connect it with a 3D scene by exchanging events. A more elegant way is to use the Java3D application interface that allows a tight connection of the Bean concepts with 3D and an encapsulation of behavior and geometry in one component. Java3D is a standardized extension of Java that provides according classes for building up a scene graph, defining lighting conditions, view platforms, user interaction with 3D objects, geometry and material properties and other 3D related issues. For the later discussion we need to know that in the Java3D scene graph there are several node types distinguished. Leaf nodes contain shapes, background, lights and behaviors while internal nodes may be specific nodes (like virtual universe or locale which determine the coordinate system) or group nodes. A transform group node defines a geometrical transformation for all leaf nodes in its sub-graph. A branch group node serves as the root for a sub-graph that may be inserted dynamically while an application is running. After the insertion of the branch group the sub scene graph is said to be live. It can be compiled to an optimized version of the scene graph representation, however, then it has to be specified by the usage of so-called capabilities what may change dynamically in the scene graph after compilation. A typical Java3D scene graph is depicted in Figure 1. In this paper we would like to discuss how to use the concepts that are implemented in Java3D and Java Beans for authoring 3D applications for the World Wide Web. For example, let us think of a distributed training scenario where the trainees work

Virtua l U n ive rs e

BG B e ha vio r N o de B

TG

S G e om e try

Tra n sfo rm G ro u p

O th e r O b jects

S h ap e3 D A p pe aran ce

Figure 1: A Java3D scene graph How could an application like this be implemented on the WWW with traditional methods? As Internet browsers do not support the presentation of 3D content internally a plug-in is needed. Plug-ins like video players (for example Quick Time VR [11]) or multimedia players (like Shockwave [12]) are not suited because they do not provide the free navigation and interaction facilities needed and it is hard to implement complex behavior (e.g. the behavior of the agents mentioned above) with the according authoring tools. Macromedia Director, the authoring environment for producing content for Shockwave, for instance, offers the scripting language Lingo, but this is not a full-featured programming language. As an alternative VRML plug-ins could be used and the behavior could be programmed using Java. This implies that geometry has to be modeled and integrated to a VRML scene graph. In parallel, the behaviors need to be programmed in Java and finally the VRML world and the Java code have to be integrated either using the Java scripting interface JSAI or the external authoring interface EAI. To perform these tasks is difficult for an author because Several formats are used (Java, VRML) • Several authoring tools are used (Geometry modeler, • scene editor / VRML authoring environments, Java integrated development environments / text editors) that provide different views of the training scenario to be modeled (a geometrical view vs. a semantic view). Finding interrelations between these two views are difficult for an author Existing authoring environments are weak in • supporting the author in the task of interfacing the behavior and the geometric representation with JSAI or EAI It is hard to use pre-defined components in building an • application like this. On the VRML side existing geometries can be used, on the Java side the Java

70

Beans concept can be applied. However, it is not possible to use a component that spans from the geometrical side to the behavior side during the authoring of the scenario as its parts are spread over different formats and different authoring tools. As a consequence the author needs to have in-depth knowledge and programming skills. The authors needed for creating high quality training scenarios, however, would be trainers with domain knowledge and a background in didactics and pedagogic that seldom have the modeling and programming skills mentioned above. In addition, it is difficult for the trainer to modify or adapt a training scenario to the trainees’ individual needs. Beside being costly and time consuming the difficulties with authoring may lead to problems as in our example emergency procedures can be confidential and it is not possible to assign the authoring tasks to third party 3D content developers. Problems as illustrated by our application example are typical for 3D content creation for the WWW and are our motivation for investigating the concepts presented in the next section.

integrated in the 3D Beanbox, in particular the 3D Beanbox has to administrate and connect the graphic representation of the 3D Beans and has to ensure that the 3D Beans behavior can be executed making an interaction between different 3D Beans and an application author possible. Conceiving the architecture for 3D Beans there are two alternatives possible how to add a graphical three-dimensional representation to a Bean. The first alternative is to add a 3D geometry description to the code of a component. This is not sufficient as then it is impossible to create new 3D Beans by just combining existing 3D Beans. Therefore, the second alternative is to use a kind of visual container that contains a whole scene graph with the possibility to extend this scene graphs with visual containers from other 3D Beans. As a consequence each 3D Bean has two interfaces: the traditional component interface (ensures compatibility with the traditional components) and an additional interface that makes the scene graph encapsulated in the Bean available for the 3D Beanbox. A 2D representation generator is conceived that makes a two-dimensional representation of the 3D Bean available for 2D authoring environments. In order to have a convenient interface between behavior and visual appearance description we distinguish in our concept between task-level behavior that has no direct effect on the graphical representation of the 3D Bean entity and guidancelevel behavior that is directly connected with the according scene graph elements and is part of the visual container. A scheduler instance is necessary to dispatch events and enable communication between the two behavior parts. As an author may wish to modify or exchange parts of the scene graph (e.g. when visually highlighting a certain part) a geometry controller has been conceived that makes these kind of actions available for the task-level behavior and also for other components that can access this functionality via the traditional interface. To summarize, the architecture of a 3D Bean is depicted in Figure 2.

3. CONCEPTS In this section a concept of 3D Beans and an according authoring environment (that we call the 3D Beanbox) is presented. First, let us shortly give an overview of the requirements the concept has to fulfill. In analyzing the requirements it is necessary to distinguish two kinds of authors: the Bean author who creates a Bean and puts it in a 3D Bean library and the application author that uses the 3D Beans in order to build an application with the 3D Beanbox. Naturally, the Bean author is more concerned with the Beans’ internal structure and it may be assumed that she has more programming skills than the application author. Ease of use and ease of integration of the graphics part of a Bean is an important requirement with regard to the Bean author. This means that access from the Bean code describing its behavior and communication facilities to its graphics part and vice versa has to be simple. A 3D Bean has a stronger requirement concerning its graphics part, as it is more complex than in the 2D case, e.g. multipart geometries assembled together in a hierarchy, transformations, rendering attributes like shininess, animation behaviors have to be represented in the 3D Bean and administrated. A 3D Bean should have the full functionality of a conventional Bean. This means, that especially the introspection and customization mechanism of a 3D Bean should be not different from non-3D Beans in order to use them together in the same application. Also the 3D Beanbox has to provide a way to represent non-3D Beans. For the reverse case, i.e. the usage of 3D Beans in a 2D-component authoring environment, the 3D Bean has to provide a two-dimensional representation of its visual appearance, nevertheless the direct execution of the 3D Bean in a 2D authoring environment is restricted. For the 3D Beanbox (similar to the 3D Bean) the requirements concerning its graphics parts are stronger than in the 2D case. The 3D Beanbox has to provide ways for geometrically importing, positioning and orienting 3D Beans. However, there is another level where a user wants to interact with the 3D Beans: the semantic level. There should be the same features for customization and event handling, which are used in conventional component authoring environments. This has to be

Ad ditio na l 3 D In te rface

C o m p on e ntIn te rfa ce 2 D -R ep re se ntatio n G ene ra tor Sc he d ule r

Task -level Be ha v ior

G eo m etryC o ntroller

Vis ua lC o nta ine r

Sc en e g rap h + G uida n ce le vel Be havior

Figure 2: The architecture of a 3D Bean The architecture of a 3D Beanbox comprises the following entities in addition to the ones of a traditional component authoring environment: A 3D Beanbox scene graph •

71

• • • • •

be done in two ways. The first and simpler way is to define only a position and orientation of a 3D Bean. A second way is to attach it to an existing 3D Bean and describe the position and the orientation relative to this existing Bean.

A 3D Bean loader that inserts 3D Beans at a suitable position in the Beanbox scenegraph A non-3D Bean loader that equips a traditional Bean with a default 3D representation (e.g. a box with the 2D interface mapped on one side) A controller that switches between geometric editing and semantic editing (event handling, method invocations, property sheets) and according editors A scene graph controller instance that manipulates the Beanbox scene graph and allows grouping, attaching and detaching of 3D Beans with each other An application writer that extracts the current scene graph together with the necessary Bean classes in order to build up the application.

BG

TG

B

S A p pe aran ce

G e om e try

4. IMPLEMENTATION Our implementation of the presented concept is based on Java3D. Thus it has to be possible to add a 3D Bean container to a Java3D scene graph. With regards to the 3D Beanbox concept, it is important that this insertion is possible during runtime of the 3D Beanbox. Since Java3D BranchGroups are the only container node type, which can be added to an existing scene graph at runtime, the external interface of a 3D Bean will be a BranchGroup. For importing a 3D Bean into a 3D Beanbox it is necessary to define an interface, in order to access to the BranchGroup of the Bean:

Figure 3: Example scene graph of a 3D Bean Let us examine how the easier case is implemented. Here it is necessary that the Beanbox include a TransformGroup into the scene graph above of the new Bean. This TransformGroup is used for the scaling, translation and the rotation to the correct size, position and orientation. In addition to this the Beanbox will put three mouse behaviors to the TransformGroup to allow a interactive scaling, translation and rotation.

public interface bean3d { public void getBranchGroup(); }

O th e r O b je cts BG

In a 3D Bean the geometry and the appearance need to be defined first. With the geometry loaders that can be found at the Java3D FAQ [13] many available three-dimensional data formats can be imported and are represented as leafs in the scene graph. Since the author of a 3D Bean is responsible for the integration of a geometry, there are no access problems to access the 3D geometry from the component code implementing the nongeometry related behavior descriptions. Vice versa, e.g. within a behavior node, there has to be a reference to the component code. A possible configuration is shown in figure 3.

TG B BG BG B

TG TG

B

S BG

It is necessary to set within the scene graph’s hierarchy a TransformGroup above of the BranchGroup in order to position and orient a 3D Bean. The integration of a behavior node could be necessary if an animation within a 3D Bean or an interaction of a user with the 3D Bean is desired. The 3D Beanbox is a visual container for using 3D Beans. This means it defines a universe and a view platform, so that the scene graph, in which all 3D Beans are included, will be displayed. By importing a Bean into the 3D Beanbox, a condition like

G e o m e try

A pp ea ran ce

B

TG

S G e o m e try

A pp ea ran ce

Figure 4: Example scene graph of a 3D Beanbox

if importBean instanceof bean3d

This description fits for the second way, too. But the position in the scene graph, where the new BranchGroup is put is different. In this case the position in the scene graph´s hierarchy is the BranchGroup of that 3D Bean, to which the new Bean is detached.

decides whether a 3D Bean geometry or a default threedimensional representation is selected. For authoring a scene it is necessary to allow a translation and rotation of the imported 3D Bean to enable a correct positioning. Including a 3D Bean could

72

has. If the cube is transformed the same holds for the cylinder. If no button is pushed the author can interact with the 3D scene in the same manner, as the user would do with the according final application.

In general, within a Beanbox´s scene graph every Bean is a child of a TransformGroup. Because of the circumstances that it is not possible to add a TransformGroup to a live scene graph it is necessary to include a superior BranchGroup to this described structure. Additionally the Beanbox adds a special BeanBehavior to every Beans BranchGroup, which receives all mouse events. This behavior is essential for the Beanbox to react on the user interaction, e.g. this is used to react on a mouse click that selects a Bean. Like traditional Beans the code of a 3D Bean is stored in one Java archive file. In order to load the classes into the 3D Beanbox a specific class loader needs to be implemented.

5. RESULTS AND APPLICATIONS In this section we want to illustrate first on a simple example use case how an author interacts with the prototype 3D Beanbox implementation that has been described in section 4. After starting the Beanbox a window with an empty virtual world is shown. Clicking on the background of this world an “Add Bean” dialogue opens where the Beans available can be selected. We insert a 3D Bean representing a blue box in the empty world that is now shown in the main window (see Figure 5).

Figure 6: Connecting 3D Beans in the 3D Beanbox The concepts and implementations described and illustrated with the simple example above have been developed in the context of the European Commission sponsored ETOILE project (Environment for Team, Organizational and Individual Learning in Emergencies) that deals with a distributed training scenario that was described as an example in section 2. There are training scenarios produced for the emergency of a fire in a tunnel of the Metro in Bilbao, as well as for training emergencies in a nuclear power plant in Spain with focus on communication training between several authorities and on-site staff that can be done location independent via the Internet. Here a significant simplification of the authoring process can be achieved using 3D Beans. It is possible, for example, to put an agent that plays a certain role in the emergency scenario in the virtual environment and locate it at an initial position without having to deal with the problems to also integrate the underlying behavior in the scene. The author only uses one authoring tool and is not faced with format conversions or integration problems. It is possible to use one 3D Bean that represent the behavior of a training participant, e.g. a Metro passenger, several times with different geometries. A telephone component shows that it is possible to integrate 3D Beans with 2D Beans. In our application example, a telephone is modeled as a 3D Bean. It provides features that it may be clicked, that it may ring or that it automatically connects to the underlying Infobus communication infrastructure [9]. A 2D Bean is implemented to provide a dialing help (by just showing 10 buttons labeled with digits) that can be used by a trainee when she clicks on the 3D telephone representation. This 2D Bean can be integrated with the described functionality in the 3D telephone Bean using the mechanisms described above. The scenario author can equip a work place with the correct number of telephones by just inserting and locating the according numbers of telephone Beans and editing their properties (e.g. the telephone number). As the components are running in the 3D Beans authoring environment he can immediately test whether the telephones work as expected (e.g. whether he made a mistake when he assign numbers to telephones).

Figure 5: A simple example with the 3D Beanbox prototype. Clicking on the cube instead of the background (with button pushed) opens the “Add Bean” dialogue once again, however, now the inserted Bean, in our example a cylinder, is inserted in the virtual world in way that it is attached to the cube. Clicking on the cube once again with the button pushed brings us to the position mode where we now can move the cube with the mouse. The cylinder attached is moved automatically. If we want to insert an other cube that should not be attached to any other existing object, we click on the background with button pushed and select it from the “Add Bean” dialogue as already described. In order to achieve the behavior that the cylinder changes its rotation if the second cube is rotated (i.e. we want to connect 3D Beans with events) we click with the mouse on the cylinder and then on the cube with the button pushed. A dialogue window pops up and we select the transform property (see Fig. 6). After this, the cylinder has the same orientation as the cube

73

6. SUMMARY AND FUTURE WORK

8. REFERENCES

In this paper a concept has been presented that shows how the component idea can be transferred to authoring of 3D content for the WWW with the goal to make 3D authoring more efficient and easier. The concept comprises the architecture of 3D Bean components itself as well as the architecture of an integrated authoring system that makes use of the information provided in the 3D Beans and can immediately execute the Beans inserted. The concept has been implemented using Java Beans and Java3D technology. The major advantages of the 3D Beans concept are on the one hand that 3D content can be created in a virtual environment more directly and efficiently using pre-fabricated components that fit together and can be customized on the fly. Especially, as the author is supported by a Bean authoring environment that itself uses information from the 3D Beans and can already execute them during authoring. On the other hand, a 3D authoring environment offers more degrees of freedom for creating component-based applications.

[1] The Virtual Reality Modeling Language Specification, ISO/IEC DIS 14772-1:1997, http://www.web3d.org/Specifications

As future work we see that the functionality of the Java Bean authoring environment can be enhanced. For instance, it is possible to link it to a database where not only 3D Beans are stored but also geometries without behaviors for the background and textures. The authoring environment could be equipped with all features of a 3D scene editor like texture mapping or lighting specification. Also an authoring environment for building up the 3D Beans themselves from ground up including an animation system from guidance level to task level would be a fruitful complementary effort to the work described in this paper.

[6] M. D. Ellroy: Mass produced software components. In P. Naur, B. Randall (Eds.), Software Engineering: Report on a conference by the NATO science committee, NATO scientific affairs division, 1968

[2] B. Jung, J.-T. Milde: An open virtual environment for autonomous agents using VRML and Java. Proceedings of VRML’99, ACM Press, 1999 [3] S. Djurcilov, A. Pang: Visualization Products On-Demand Through the Web. Proceedings of VRML’98, ACM Press, 1998 [4] I. Soetebier, R. Dörner, N. Braun: Seamless Integration of Databases in VR for Constructing Virtual Environments. In: Computer Graphics Forum, Vol.18 (1999) Nr.3, Elsevier Science, 1999 [5] D. W. Fellner, A. Hopp: VR-LAB-a distributed multi-user environment for educational purposes and presentations. Proceedings of VRML’99, ACM Press, 1999

[7] Microsoft COM http://www.microsoft.com/com/

Description.

[8] N. K. Craighill: OpenStep for Enterprises. Wiley & Sons, 1996 [9] Java Beans Homepage http://www.sun.com/beans [10] S. Sowizral, K. Rushforth, M. Deering: Java 3d Api Specification (Java Series), Addison-Wesley, 1997

7. ACKNOWLEDGEMENTS

[11] Quicktime VR Homepage http://www.apple.com/quicktime/

The research in this paper has been partly funded by the European Commission under the ESPRIT Program (Project ETOILE, EU ESPRIT Project No. 29086). Our thanks to all ETOILE project partners.

[12] Shockwave and Macromedia http://www.macromedia.com [13] Java3D FAQ http://havefun.ncsa.uiuc.edu/Java3D/

74

Director

Homepage Homepage

Citation: Dörner, Ralf; Grimm, Paul: Three-dimensional Beans - Creating Web Content Using 3D Components In A 3D Authoring Environment. In: Spencer, Stephen N.; ACM SIGGRAPH u.a.: Web3D - VRML 2000. Proceedings : Fifth Symposium on the Virtual Reality Modeling Language. New York : ACM Press, 2000, S.69-74