EnCIMA: A Graphics Engine for the Development ofMultimedia and Virtual Reality Applications

Silvano Maneck Malfatti †malfatti@lncc.br

Selan Rodrigues dos Santos ‡selan@dimap.ufrn.br

Luciane Machado Fraga †lmfraga@lncc.br

Claudia Marcela Justel §cjustel@de9.ime.eb.br

Jauvane Cavalvante de Oliveira †jauvane@lncc.br

† Laboratorio Nacional de Computacao Cientıfica

Laboratorio ACiMA, Av. Getulio Vargas, 333 25651-075 Petropolis, RJ, Brazil

§ Instituto Militar de Engenharia

Secao de Engenharia de Computacao SE/8, Praca General Tiburcio, 80 22290-270 Rio de Janeiro, RJ, Brazil

‡ Universidade Federal do Rio Grande do Norte

Departamento de Informatica e Matematica Aplicada, Campus Universitario, s/n 59072-970 Natal, RN, Brazil

Abstract

This work presents the features of a flexible realtime 3Dgraphics engine aimed at the development of multimediaapplications and collaborative virtual environments. Theengine, called EnCIMA (Engine for Collaborative and Im-mersive Multimedia Applications), enables a quick devel-opment process of applications by providing a high level in-terface, which has been implemented using the C++ object-oriented programming paradigm. The main features of theproposed engine are the support to scene management, abil-ity to load static and animated 3D models, particle systemeffects, network connection management to support collab-oration, and collision detection. In addition, the enginesupports several specialized interaction devices such as 3Dmice, haptic devices, 3D motion trackers, data-gloves, andjoysticks with and without force feedback. The engine alsoenables the developer to choose the way the scene shouldbe rendered to, i.e. using standard display devices, stere-oscopy, or even several simultaneous projection for spa-tially immersive devices.

1 Introduction

Virtual reality (VR) applications aims to enable user toexperience the sense of presence — casually defined as thefeeling of being “in” a virtual environment — which is re-alized through factors such as immersion, involvement, and

interaction [8, 3]. Allowing the user to experience a virtualenvironment (VE) through simultaneous and coordinatedsensory stimuli is the basic mechanism VR uses to affordpresence. This is accomplished with special interaction de-vices (e.g. spatially immersive devices, head/face mounteddisplays, data gloves, haptic devices, trackers, etc.). Conse-quently, the process of designing a VR application is not aneasy task, specially if the application is built directly on agraphics application programming interface (API). This sit-uation requires the developer to be able to handle all the re-sources necessary to make the application work as intended.

To make things easier, in the early 90s the concept of“engine” was put forward in the game industry. In gen-eral terms, an engine is a middleware, i.e. a group of libraryfunctions that abstract most of the low level implementa-tion details by providing the developer with a high levelprogramming interface [6]. These functions are organizedin groups with specific functionality such as resource man-agement, networked communication, 2D and 3D rendering,collision detection and response, audio rendering, physicssimulation, and scene management [4]. As a result, the de-velopers are able to generate applications that are indepen-dent of third-party APIs, provided that the programming isdone through the high-level engine’s functionality. In addi-tion, this approach supports platform-independent VR ap-plications and speeds up the overall development process.

The success of this idea was responsible for makingsome VR application in areas like medical simulation, mil-itary training, education, art and entertainment, to adoptgame engines as their basic development toolkit [13]. How-

1

ever, the use of game engines to develop VR applicationshas a major limitation: because engines usually supportsonly traditional interaction devices — i.e mice, keyboards,and joysticks — the type of virtual environment that can begenerated is restricted to desktop VR [15].

According to Maia [9], another issue is that the resourcesof a game engine are targeted at supporting game relatedfeatures. To obtain a general purpose game engine it wouldbe necessary to re-design it entirely.

For this reason, there have been an effort towards devel-oping engines specialized for VR applications. The workdone by Pinho [12] showed that VR engines should providespecial features such as support to a wide range of specialinteraction devices, various 3D model loaders, schemes formanagement and optimization of 3D graphics environment,multi-platform support, and multi-screen display capability.

This paper presents a VR engine aimed at assisting thedevelopment of VR applications, which supports the afore-mentioned features in addition to the graphics resourcesavailable in tools used in game design. Our motivation wasto design an engine that would afford a quick developmentprocess of applications with various types of interaction de-vices, and to provide a more engaging environment withanimated characters, better lighting, particle systems, ter-rain modelling, collision detection, etc. It is worth mention-ing that our engine also supports specialized display devicessuch as CAVE-like systems.

This work is organized as follows, Section 2 presentssome background on the usual components of an engine ar-chitecture. In Section 3 we present a few examples of sim-ilar graphics engines, focusing on their features, whereas inSection 4 we delve into the EnCIMA’s architecture, explor-ing some of its features and functions. Section 5 describestwo test applications developed with our engine. Finally, inSection 6 we present some conclusions and future work.

2 Graphics Engine Architecture

A graphics engine is a key component in a VR applica-tion, being responsible for performing important tasks suchas accessing input devices, resource management, updatingcomponents of the virtual environment, rendering the 3Dscene and presenting the final result through display devices[3].

A traditional way of designing an engine architecture isto organize its functionality in layers. Maia in [7] defineda generic structure for engines, which is composed of threelayers, as shown in Figure 1. These layers are organizedinto modules with a strict hierarchical dependency.

Figure 1: Generic architecture of a game engine.

2.1 The Sub-systems Layer

The sub-systems layer is composed of several modulesthat offer specific services to the core which, in turn, trans-forms them in high-level actions for the application. There-fore, every module of this layer is characterized by theapplication domain it is target for, the tasks assigned tothe module, and the technology employed to execute thesetasks.

Consider, for instance, the Input module which is re-sponsible for recognizing the interaction devices pluggedinto the application. The input module’s main attribution isto receive user action entered through devices like mouse,keyboard, joystick, data gloves, and position tracking sys-tems. For that purpose, the input module must provide func-tions that recognize buttons being pushed, requests for up-dating cursor position, understand tracker orientation andpositioning in terms of VE’s coordinate system, etc.

For this reason, every module in the sub-systems layerrepresents and interface between the core and APIs or lowlevel driver that can have direct access to the underlyingoperational system. Figure 2 shows an example of a sub-systems layer composed of three modules with specific re-sponsibilities.

Figure 2: Example of a graphics engine’s sub-systems layer.

2.2 The Core Layer

The core is responsible for providing the link betweenthe application layer and the engine’s available sub-systems.

Johnston [5] defines the core as the engine’s central com-ponent or server, responsible for invoking the appropriatefunctions with the right parameters in response to eventsgenerated by the user or the environment. Therefore, allmodules from the sub-systems layer must register with thecore, so that the core is able to initiate each registered mod-ule and coordinate the interaction and data exchange among

2

the engine’s components.Similarly to the sub-systems layer, the core is also orga-

nized into several modules, each of which having specificresponsibilities that are fundamental for the engine’s properfunctioning. These responsibilities may include access tothe local file system, resource management, mathematicscore library, activity log, and the specification of the ma-nipulation interface between objects from the VE and theassociated devices. Figure 3 presents an example of a corewith six modules.

Figure 3: Example of a core layer comprised by six modules.

2.3 The Application Layer

The application is the target software that has been builton the functionality offered by the core. It is the applicationdesigner’s responsibility to specify how the VE is supposedto look like, load and position all 3D models, set up sensorsto trigger the appropriated animation and visual effects, aswell as to define the VE’s response based on either the en-gine’s state machine or user interaction.

The usual strategy employed by VR application develop-ers when they want to create a new VE is to derive throughinheritance the engine’s classes that offer support to sceneresources. In doing so, the developer has access to high-level methods that encapsulate the functionality availablewithin each of the various core’s modules.

3 Related Work

In this section we review three academic VR engines,focusing on their main features and underlining motivation.We wanted to understand the functional aspects of the se-lected engines and how easily they can be employed to buildVR applications.

3.1 enJine

The enJine is an open source graphics engine developedentirely on Java and Java3D API. Consequently, one of themain features is the platform independency and the object-oriented paradigm, both inherent to Java applications [10].

The underlining motivation for enJine was to provide atool with educational purposes, supporting the teaching of

game programming, VR applications, and other computerrelated concepts such as software engineering and computergraphics.

The VR aspects of the enJine benefited from the Java 3Dinherent features which affords, with a few lines of code,access to unconventional display devices such as head/facemounted displays, stereo rendering, and multi-screen pro-jection. Despite the existence of comprehensive documen-tation and the facility in developing VR application, we be-lieve enJine to have one noticeable limitation: it only sup-ports the so-called traditional interaction devices, i.e. mice,keyboards, and joysticks.

3.2 SmallVR

SmallVR is a toolkit that supports the development ofVR applications [12]. The conception of SmallVR wasdriven by the necessity of an educational tool that couldbe used in the practical lessons of Virtual Reality modules.SmallVR strongest advantage is to afford a fast develop-ment process of VR applications. This is accomplishedbecause SmallVR provides all the basic core functionality,therefore the students do not need to program neither graph-ics device control nor functions to load 3D object models.

The third-party libraries used by SmallVR architectureare GLUT and OpenGL [14]. As a result, it is possible forthe developer to keep utilizing the basic structure of GLUTprograms, and still add objects and program actions with-out having to surrender the application’s execution control.Other features of SmallVR are the support to scene graph,loaders for popular 3D model formats such as Wavefront’sOBJ and Autodesk’s 3DS, the implementation of renderingacceleration algorithms such as view frustum culling, col-lision detection, the existence of drivers to support motiontracking devices and head/face mounted displays.

Although SmallVR offers a range of valuable featuresand proper documentation, the toolkit does not provideother important graphics resources such as support for ani-mated 3D models, shadow casting, particle systems, as wellas audio rendering — all these features are left to the devel-oper to program.

3.3 CGE

The CGE, CRAb Graphics Engine, is one of the mostcomplete academic VR engines available. CGE was devel-oped based on the CRAbGE framework, proposed by Maia[7].

CGE is an open source, platform-independent enginewhose rendering system is done with the OpenGL API. Oneof the hallmark features of the CGE is a highly customiz-able interface, via scripts and plugins. In terms of graphics

3

resources, CGE provides several scene rendering accelera-tion techniques such as hierarchical frustum culling, level-of-detail (LOD), billboards, and particle systems.

Furthermore, CGE also supports collision detection, spa-tialized sound, the loading of static and animated 3D modelssuch as 3DS and MD2, and accepts some types of specialinteraction devices like positioning tracker and dataglove.However, CGE does not handle simultaneous and coordi-nated renderings for multi-projection spatially immersivedevices, like the CAVE system, nor provide support for hap-tic devices.

4 The EnCIMA Engine

The EnCIMA engine was designed with the purpose ofenabling the developer to get his application running asquick and simple as possible, The engine offers a easy to useobject-oriented interface designed to minimize the effort re-quired to render 3D scenes, in such a high level that theapplication becomes independent of third-party 3D graph-ics rendering API (e.g. Direct3D or OpenGL). For that rea-son, the developer does not need to have previous or specificknowledge on how to program a given API nor the interac-tion with special input/output devices.

In terms of graphics resources, EnCIMA provides theloading of both static and animated 3D models, the proce-dural generation or loading of terrain meshes, environmenteffects such as skydome, sprites, static and animated bill-boards, and particle system effects.

The engine also provides high-level functions to con-trol 2D and 3D audio playback, and access to spatializedsound that can be affected by a series of dynamic simulationeffects such as Doppler, environment volume, attenuation,and movement of the sound’s source location.

Additionally, the engine supports 3D and 2D input de-vices. Figure 4, for instance, shows a variety of deviceshandled by the engine: 3D mice, data gloves, tracking sys-tems, joysticks (with or without force feedback), and Sens-able’s Phantom.

The EnCIMA’s architecture (show in Figure 5) follows amulti-layer design that integrates the tradition componentsmentioned in Section 2: sub-systems, core, and application.In the coming subsections we describe in more details eachof the EnCIMA’s three layers.

4.1 The Sub-systems Layer

The sub-systems layer integrates well-known APIs, andproprietary drivers that communicate directly with theWindows-based operational system. EnCIMA renders us-ing OpenGL API, whereas the audio is handled by DirectX.The graphics user interface, interaction devices driver, andnetwork connection are all handled by native Windows API.

Figure 4: Example of devices supported by the EnCIMA en-gine: data glove, 3D mouse, and 3D tracker.

4.2 The Core Layer

The core layer is composed by a set of manager modules.Each manager is defined as a class whose main attribution isto communicate with the sub-systems and offer services tothe application layer. Figure 5 presents the seven modulesthat form the EnCIMA’s core layer. The next subsectionsdescribe the functionality of all seven modules.

4.2.1 Graphics Manager

The graphics manager is responsible for the allocation ofgraphics resources, the loading of several image formats(including support to transparency), texturing, and the abil-ity to capture screenshots. The singleton graphics man-ager is available to all classes that require any image re-lated action, for instance texture loading, heads up dis-plays (HUDs), terrain generation, and particle systems (e.g.fire, smoke, etc.). The graphics manager is an importantmodule because it manages and shares graphics resources,assigning them unique identifiers. All the subsequent re-quests for the same graphics resource are sent to the graph-ics manager, which answers back with a reference to therequested resource. This simple approach avoids mem-ory waste and optimize its usage and access. The codeshown in Code 1 presents the LoadImage method ofthe GraphicsManager that is responsible for the imageloading process.

The graphics manager employs a reference countingscheme, which decrements the counting when a resourceis released and increases it when the resource is requested.When the counting reaches zero the graphics resource is fi-nally freed.

4.2.2 Time Manager

The time manager controls all timers used in animation andspecial effects. Its main task is to guarantee that timers have

4

Figure 5: The EnCIMA’s architecture.

Code 1 GraphicsManager’s method to load images.

CVRImage*CVRGraphicsManager::LoadImage( char* fileName,

bool transparency ) {

// Verify whether the image has already been loaded.for ( i n t iIndex=0;iIndex<( i n t)vImages.size();iIndex++){

for (strcmp(fileName,vImages[iIndex]->GetImageName())== 0) {

vImages[ iIndex ]->iReferences++;return vImages[ iIndex ];

}}

// Not loaded yet, thus we create a new one.CRVImage* pNewImage = new CRVImage;

i f ( pNewImage ) {pNewImage->LoadImage( fileName, transparency );i f ( pNewImage->GetImageData() ) {

vImages.push_back( pNewImage );return pNewImage;

}}

// Image not found.delete pNewImage;return NULL;

}

a consistent temporal behavior in machines with variousprocessing capacities. The main advantage in centralizingtime management is that the low level function that retrievesthe system time is called only once every frame and used toupdate all registered timers.

4.2.3 Input Manager

The input manager communicates with every input devicesupported by the engine. This module detects, initiates, anduniquely identifies all input devices plugged into the appli-cation. The Code 2 snippet shows the usage of the input

manager to initiate and obtain the angles from one of the3D positioning tracker’s sensors.

Code 2 Establishing communication with 3D positioningtracker through the input manager.

void SceneTest::Init() {

// Creates a 2D bitmap font.fAngle = 0.0f;Font = CreateFont2D( "EnCIMA", 30, true );Font->SetColor( 1.f, 0.f, 0.f );Font->SetPosX( 50.f );Font->SetPosY( 50.f );

// Initialize the tracker.pManager->cInputManager.cTracker.Init();

// Get the angle with Y axis from sensor 1.fAngle=pManager->cInputManager.cTracker.GetAngleY(1);

}

4.2.4 Sound Manager

The sound manager coordinates the loading of 2D and 3Dsounds, allowing the application to set up various sound pa-rameters such as volume, 3D position, area of influence, andattenuation.

4.2.5 Network Manager

The net manager is responsible for establishing networkconnections between servers and clients, for collaborativeapplications. The data exchange follows a multicast-basedclient-server model. This means that every server is respon-sible for both managing groups of client applications anddelivering modifications to all the participants of a givengroup.

5

4.2.6 Interface Manager

The interface manager is responsible for handling every de-tail related to the display device utilized by the application.For traditional displays, it is possible to set window size,position, background color, stereoscopic rendering, graph-ics resolution, and fullscreen mode.

4.2.7 Collision Manager

Collision detection avoids virtual objects to penetrate oneanother. A pre-stage in collision detection is to identify themoment that objects get close enough to be considered forcollision tests [16]. The collision manager is responsiblefor identifying potential colliding objects and perform in-tersection tests for collision determination.

EnCIMA applies the sphere-trees technique to performcollision detection. This technique approximates the geom-etry of objects with an hierarchy of spheres. Every objectin a scene is involved in a sphere, therefore sphere inter-section tests are done to check for collision among objects.The advantage of working through an hierarchy of spheresis that an entire sub-tree (of spheres) can be readily elimi-nated from the collision detection process by simply testingif the root sphere (the one that bounds all its children) doesnot intersect with the target object’s sphere.

The sphere primitive is often the preferable choice ofbounding volume, the reasons being: i) it is procedurallyand mathematically simple to construct a sphere, ii) spheresare invariant under rotations, and iii) the calculation of in-tersection between spheres is simple an computationally in-expensive.

We have employed the Sphere-Tree Construction Toolkit[2] to generate the sphere-tree of the objects in a scene. Thesphere-tree generation is done in a pre-processing step, inwhich the created trees are stored in files. Later, the en-gine loads and positions them on the corresponding object’ssurface. Figure 6 illustrates an example of the sphere-treecorresponding to a scalpel model.

Figure 6: Sphere-tree of a scalpel model, generated with theSphere-Tree Construction Toolkit.

4.3 The Application Layer

The application layer is the starting point for any VR ap-plication developed on EnCIMA. Through this layer an ap-plication has access to all the engine’s functionality and re-sources. The class Scene, shown on the top of Figure 5, isthe realization of this layer. This class contains a high-levelmanager (Manager) that has a reference to every managerlocated in the core.

This centric approach facilitated the implementation ofthe Scene class where several high-level functions areavailable to the developer. The only requirement to start offan application is to derive through inheritance the Sceneclass and override the Init() and Execute() methods.The Init() method, as the name implies, initiates the ap-plication’s objects and resources and is called only once ina run, whereas the Execute() is called every frame andis responsible for the application loop that contains the ap-propriate sequence of actions. The class CVRScene han-dles all the other details, such as resource allocation, therendering of 2D and 3D objects, and the release of systemresources when the application finishes.

Other methods available in the Scene class are:

• CreateFont2D(): creates bitmap fonts to be usedas HUDs.

• CreateBillboard(): creates a textured polygonwhose front-face is always facing the virtual camera.This resource is specially useful in particle systems.

• CreateMd2(): loads a animated object in Md2 for-mat. This alleviates the developer’s burden of havingto program animation, since this can be done in a pre-stage, using specialized modelling and animation soft-ware.

• CreateObj(): loads an static object in Wavefront’sOBJ format. The object can be represented by a meshof triangles or n-sided polygons, associated to materialor texture. This is specially useful when loading pre-designed scenarios.

• CreateBmpTerrain(): generates a heightfield-based terrain from a greyscale bitmap image.

• LoadSound(): loads a 3D sound that can be posi-tioned anywhere within the VE.

• LoadMusic(): loads a 2D sound to be played re-gardless of the user’s location within the VE.

• CreateSkyBox(): creates a background for the en-vironment based on a texturized cube that encapsulatesthe entire VE.

• CreateSkyDome(): creates a background for theenvironment based on a texturized sphere the sur-rounds the entire VE.

In addition to the above mentioned functions, the

6

Table 1: Comparison of engine’s functionality.

VR ENGINES

FEATURE enJine SmallVR CGE EnCIMA

Network – – • •Collision detection • • • •Static models • • • •Animated models • – • •Terrain generation – – – •Particle system – – • •Standard Input device • • • •3D sound – – • •Tracker support – • • •Haptic device – – – •Dataglove – • • •3D Mouse – – – •Culling • • • •Partition Environment • – • –Portability • • • –Multi-screen projection – • – •

Obs: ‘•’ means feature supported.

Scene’s high-level manager grants access to all the core’smodules, thereby allowing direct use of important under-lying behavior when needed. Tables 1 summarizes a com-parison of functionalities provided by EnCIMA and the re-viewed engines of Section 3.

5 Case Study

In this section we present two case studies in which theEnCIMA engine has been successfully applied in order togenerate a VR application. The goal of the first application(shown in Figure 7) was to support navigation and explo-ration of an oil platform’s installations. Furthermore, theapplication simulates two types of situations: the executionof evacuation and rescue procedures in case of a serious ac-cident, and a training scenario for firefighters.

The environment for this application is represented, ba-sically, by a static 3D model of the oil platform in conjunc-tion with a skybox. The code fragment presented in Code 3shows the Init() method that instantiates the applicationresources. To create the simulation’s graphical interfacethe developer only needs to declare reference variables forthe objects needed and invoke the methods from both theScene class and the core’s modules to allocate resources.

The second application, called AVIDHa (Atlas VirtualInterativo Distribuıdo Haptico), is a human body 3D atlasfor anatomy study purpose. The system provides high defi-nition models of human body parts with photo-realistic tex-tures, as shown in Figure 8.

The application allows the anatomy student to flythrough and inside the human body. The flight control isdone with either 3D mouse or joystick. The student mayalso choose to investigate each system separately, change

(a)

(b)

Figure 7: The simulation of an oil platform: (a) overview, and(b) detail.

organ’s opacity to exam internal parts, or capture screen-shots for later examination.

In terms of performance for the AVIDHa application, theengine delivered a refresh rate of 30 frames per second, fora 3D models with 5.3 million polygons and 87.8 MBytes oftexture, running on a Intel Pentium D (3.0 GHz e 2.0 Gbytesof RAM) with a NVIDIA GeForce 8800 GTX.

In the next development phase of this application, we in-tend to enable students to use a phantom device to feel theorgan’s contours and haptic texture, as well as to providenetwork communication through a client-server model sothat the teacher would be able to control the students’ ac-tions.

6 Conclusion and Future Work

An overall subjective evaluation of the applications de-scribed in the case studies section showed us that the use of

7

Code 3 Initializing the oil platform simulation application.

void SceneTest::Init() {

// Creates a 2D bitmap font.fAngle = 0.0f;Font = CreateFont2D( "EnCIMA", 30, true );Font->SetColor( 1.f, 0.f, 0.f );Font->SetPosX( 50.f );Font->SetPosY( 50.f );

// Set the camera’s position.pManager->cView.SetPosition( -500, 90, 0 );pManager->cView.RotY( 5.f );pManager->cView.UpdateView( );

// Loads the platform model stored as an obj file.obj = this ->CreateObj("p40t.obj","objects\\", true);

// Loads sound.CVRListener* list = GetListener();CVRSound* sound = LoadSound("\\Sounds\\SANDSTRM.wav");sound->SetRepeat( -1 );sound->PlaySound( );sound->SetVolume( -800 );sound->SetMaxMin( 300, 100 );sound->SetPosition( -160, 30, 0 );

// Creates a skybox.skybox = CreateSkyBox( true );skybox->SetCenterBox( 0.f, 0.f, 0.f );skybox->SetBoxSize( 3000, 1000, 3000 );skybox->SetFrontTexture( "\\Images\\front.bmp" );skybox->SetBackTexture( "\\Images\\back.bmp" );skybox->SetLeftTexture( "\\Images\\left.bmp" );skybox->SetRightTexture( "\\Images\\right.bmp" );skybox->SetDownTexture( "\\Images\\water3.bmp" );skybox->SetUpTexture( "\\Images\\up.bmp" );skybox->SetDrawGround( true );skybox->SetFloorHeight( 400 );

}

EnCIMA engine speeded up the overall development pro-cess, even in situations that require the use of special inter-action devices, such as 3D mice, phantom, or CAVE.

The EnCIMA’s flexible API offers the basic elementsneeded by all visualization and simulation applications,without requiring the user to have any knowledge onOpenGL or DirectX libraries.

The next step is to work on the sub-systems layer in or-der to extend its support to other platforms besides Win-dows. This extension would not affect any of the previouslycreated applications, since EnCIMA’s application layer pro-vides a high-level, platform-independent API.

Finally, we will develop two new modules: one mod-ule to provide navigation aids (such as maps, signs, and au-tomatic camera control) that would help users to performwayfinding in complex virtual environments, and; anotherto afford object deformation, which is important in provid-ing a consistent visual and haptic feedback.

(a)

(b)

Figure 8: The AVIDHa application: (a) the interface is com-posed of user controls rendered as HUDs, and a 3D render-ing space in which the human body model is shown; in (b) weshow a detailed view of 3D models of human body parts.

7 Acknowledgement

The authors acknowledge financial support fromFundacao Carlos Chagas Filho de Amparo a Pesquisado Estado do Rio de Janeiro (FAPERJ, grant number170.332/2006), Rede Nacional de Ensino e Pesquisa (RNPGiga, number 2439), PCI/LNCC/MCT, and ConselhoNacional de Desenvolvimento Cientıfico e Tecnologico(CNPq, grant number 305106/2004-0).

References

[1] A. Bierbaum, C. Just, P. Hartling, K. Meinert, A. Baker, andC. Cruz-Neira. VR Juggler: A virtual platform for virtual

8

reality application development. In VR ’01: Proceedingsof the Virtual Reality 2001 Conference (VR’01), page 89,Washington, DC, USA, 2001. IEEE Computer Society.

[2] G. Bradshaw and C. O’Sullivan. Adaptive medial-axis ap-proximation for sphere-tree construction. ACM Transactionson Graphics, 23(1):1–26, 2004.

[3] G. C. Burdea and P. Coiffet. Virtual Reality Technology.Wiley-Interscience, second edition, 2003.

[4] K. C. Finney. 3D Game Programming All in One. CourseTechnology PTR Game Development Series, Andre LaMothed. Thomson Course Technology PTR, first edition, April2004.

[5] D. Johnston. 3d game engines as a new reality. In Proceed-ings of the 4th Annual CM316 Conference on MultimediaSystems, pages 1–8, Southampton University, UK, Novem-ber 2004. http://mms.ecs.soton.ac.uk/mms2004.

[6] M. Lewis and J. Jacobson. Game engines in scientificresearch - introduction. Communications of the ACM,45(1):27–31, 2002.

[7] J. G. R. Maia. CRAbGE: Uma arquitetura para motoresgrafico, flexıveis, expansıvel e portavel para aplicacoesde realidade virtual. Master’s thesis, Departamento deComputacao, Universidade Federal do Ceara, Marco 2005.

[8] J. G. R. Maia, J. B. Cavalcante Neto, H. O. O. Gomes, andC. A. Vidal. CRAbRender: Um sistema de renderizacaopara aplicacoes de rv. In Proceedings of the VII Symposiumon Virtual Reality, SVR2004, volume 1, pages 380–382, SaoPaulo, SP, 2004. SBC/Faculdades Senac.

[9] J. G. R. Maia, J. B. Cavalcante Neto, and C. A. Vidal.CRAbGE: Um motor grafico, customizavel, expansıvel eportavel para aplicacoes de realidade virtual. In Proceed-ings of the VI Symposium on Virtual Reality, SVR2003, vol-ume 1, pages 3–14, Ribeirao Preto, SP, 2003. SBC/Facul-dades COC.

[10] R. Nakamura, J. Bernardes, and R. Tori. enJine: Architec-ture and application of an open-source didactic game engine.In B. Feijo, A. Neves, E. Clua, L. Freire, G. Ramalho, andM. Walter, editors, Digital Proceedings of the V BrazilianSymposium on Computer Games and Digital Entertain-ment, pages 1–7, Last access: 22/11/2007, November 2006.http://www.cin.ufpe.br/˜sbgames/proceedings/files/enjine.pdf.

[11] W. Paper. Physics, gameplay and the physics processingunit. Technical report, AGEIA Technolgies Inc., 82, PionerWay, Mountain View, CA, USA, 2005.

[12] M. S. Pinho. SmallVR: Uma ferramenta orientada a obje-tos para o desenvolvimento de aplicacoes de realidade vir-tual. In Proceedings of the V Symposium on Virtual Reality,SVR2002, volume 1, pages 329–340, Fortaleza, CE, 2002.Porto Alegre: SBC.

[13] W. R. Sherman and A. B. Craig. Understanding Virtual Re-ality: Interface, Application, and Design. Morgan KaufmanPublishers, first edition, 2003.

[14] D. Shreiner, M. Woo, J. Neider, T. Davis, and A.R.B.OpenGL. OpenGL(R) Programming Guide: The OfficialGuide to Learning OpenGL(R), Version 2. Addison-WesleyProfessional, fifth edition, August 2005.

[15] B. Stang. Game engines: Features and possibilities. Techni-cal report, Institute of Informatics and Mathematical Mod-eling at The Technical University of Denmark, 2003.

[16] G. van den Bergen. Collision Detection in Interactive 3DEnvironments. The Morgan Kaufmann Series in Interactive3D Technology. Morgan Kaufmann, harcover edition, Octo-ber 2003.

9