NAVER Framework
From IMRC Wiki
NAVERLIB is a microkernel architecture framework in the distributed network environment. NAVERLIB provides libraries for a variety of interactions, interface, and virtual contents that can be composed in the virtual reality environment. Scene-graphs, interactions, and scenarios can be written by the XML based NAVERLIB scripting language.
Contents |
Quick View of NAVER Library
NAVER is a library which provides functionalities for creating virtual contents, a variety of interactions and simulations. Originally, it was designed for providing a base platform for VR application development. Recently, it has been extended not only to support VR but also to work with Augmented Reality (AR) and Ubiquitous Computing (UC) environment. NAVER library is built based on the various libraries.
MySQL database is used to manage the object state used in the collaborative application and libMySQL provides functionality for accessing the MySQL database. For managing the peripheral interaction devices, such as joystick, tracker, wand, VRPN is used. It provides a network-transparent interface between the application and the physical devices. The current version of NAVER uses OpenSceneGraph as the main visual graphics rendering tool. For managing an AR application, it uses OSGART, a library which combined ARToolkit tracking library and OpenScenegraph to simplify the development of AR applications. In order to support the interaction with smart physical objects in the UC environment, CAIM is used. It is responsible for collecting the object status and sending the control message to the smart objects. NAVER also provides an access to the Virtual Physics library which enables the simulation of the physics law in the virtual environment.
NAVER Modules
NAVER consists of several independent modules which are configurable through the XML descriptions. All NAVER modules are in Dynamic Link Library (DLL) and Library (LIB) format. The summary of NAVER modules are shown in Table 1. Besides those modules there are also several related applications which communicate with NAVER modules (see Table 2).
| NAVER Module | Features |
|---|---|
| libnv | NAVER kernel contains the basic classes and functionalities of NAVER modules. |
| nvmASVF | Create a stereoscopic view |
| nvmCAIM | Communicate with the CAIM to get and to change the smart object states. |
| nvmDisplay | Synchronize the multi display systems. |
| nvmLoader | Load a model for composing a scenegraph. |
| nvmObjectClient | Communicate with the Object Server to synchronize the object states across various interaction spaces. |
| nvmOSGART | Manage the vision tracking of AR marker to properly align the virtual objects on top of the real image. |
| nvmStreaming | Stream an image from the Network camera or the Avatar Server. |
| nvmVirtualPhysics | Simulate the physics law in the virtual environment. |
| nvmVRPNClient | Communicate with the VRPN Server to get/send the values from/to the peripheral interaction device. |
| Application Name | Features |
|---|---|
| nvView | Executable file which is used to run the NAVER configuration file.
Usage: nvView.exe XMLConfiguration.xml |
| Avatar Server | Reconstruct 3D video avatar using the visual hull technique. |
| CAIM | Collect the object states and control the smart objects. |
| Object Server | Synchronize the objects in the different interaction spaces.
Usage: ObjectServer.exe objectServer.conf |
| VRPN Server | Connect to the peripheral interaction devices.
Usage: VRPNServer.exe (implicitly it will read vrpn configuration file (vrpn.conf)) |
Extending NAVER Library
As mentioned earlier, libnv contains the basic classes and functionalities of the NAVER modules. Hence, every NAVER module is derived from nvModule class which has been defined in libnv library. NAVER is designed to be extensible which enables the developer to add new module to support a specific application scenario.
Creating a New NAVER Module
In order to define a new module, basically we need to create a new class derived from existing class nvModule and implement some virtual functions. Figure below shows the basic example for defining a new module. Besides implementing the virtual functions, new function could also be added e.g. specificFunction().
In order to produce both DLL and LIB file to set the Project setting properly (NV_LIBRARY to the Preprocessor Definitions and set the Import Library field). Besides those settings, in the source code, it is needed to add several lines to export the new class so that it can be accessed from outside.
Registering Field for Routing
NAVER module can communicate each other through the router mechanism. As previously mentioned, each module needs to register the field before it can be used in the router. Here is the example for defining a field on the header file. On the initialization, this field will be initialized using the corresponding constructor, for example, registering the container field for data type float[3]. If during the interaction, this module is responsible for updating the field values and sending these values to the other modules, it is important to call sendEvent() function in the interaction loop. Otherwise, this module will never send the values to other modules. In the XML configuration file, this field can be referred using this identifier “moduleID:moduleID.newField”.
Preparing Data Field for Multi-Cluster Synchronization
To synchronize the data among multi-clusters system, a few steps are needed. For example, we would like to share the transformation matrix oh each nodes in the scenegraph. First, we define the variable to store the data on the header file (e.g. listNodes[i]->nodeMat). Next, we initialize the shared data using packData() function. In this example, type of data that are shared is osg::Matrix. Then, we implement the virtual function syncCluster(), this function is only called by the MASTER cluster. Basically, this function will update the shared data and the SLAVE clusters will receive the update data and apply those update.
Configuring NAVER Modules
Here we give examples of NAVER configuration.
Basic XML Configuration for NAVER
Here we shows the template for NAVER configuration. Basically, we need to define <viewer> and its properties, such as initial camera position and orientation, viewport, field of view, stereo, etc. More detailed about the XML tags and attributes could be found in the Reference Manual.
XML Configuration Example for nvmVRPNClient
Figure below shows the example of XML configuration for the interaction devices.
For example, we want to create a virtual world which contains of several objects and we want to control the movement of the virtual object (e.g. a ball) using a joystick. In order to achieve that, first we create a viewer. Next, we create the scenegraph using <nvmLoader> and then we configure the interaction device used to control the virtual ball (e.g. a joystick). The Joystick is connected to the VRPN Server which might be located in another PC. In the configuration file, the name and the location of the Joystick are defined. Using a router, we can route the values from the joystick inputs to the ball position.
XML Configuration Example for nvmOSGART
Figure below shows the example of XML configuration for creating an AR application. nvmOSGART requires an additional configuration file for the marker data and the camera data. These files are same as the files used for configuring the ARToolkit. More detailed explanation about the marker and camera configuration file could be found in the ARToolkit documentation. Next, we need to define the default marker. All nodes available in the scenegraph will be linked to the default marker unless they are explicitly linked to the specific marker or they are defined in the <IgnoreModel>. Using <ARMarker> we can link a model to the specific marker. The nodes which are defined in the <OcclusionModel> will only be rendered on the depth buffer. This is used to create the occlusion effect (the real object occludes the virtual object). Finally, we send the marker position to the ball position using a router.
Running NAVER on a multi-cluster system (e.g. CAVE like environment)
NAVER is designed for being used in a single display system as well as in a multi-cluster system, such as CAVE (Cave Automatic Virtual Environment) environment or large surrounded projection screen. CAVE is an immersive virtual reality environment where projectors are directed to three, four, five or six of the walls of room-sized cube as shown in Figure XXX. In order to run NAVER in the CAVE-like environment, basically we need to install the same version of NAVER in all PC clusters. Next, we create an XML configuration for NAVER modules. After we have finished creating the configuration for all clusters, we are ready to load the XML files and run a NAVER application in CAVE. There are several things that need to be considered when we deal with a CAVE-like environment, such as state sharing among the clusters, stereo vision and asymmetric view frustum (ASVF).
- State sharing : in order to share the state among CAVE clusters, we use Master and Slave architecture with a hard-sync mechanism. One cluster will become a Master and be responsible for updating the data (e.g. camera position/orientation, object position/orientation) and send those update to the Slave clusters. Slave clusters will receive the update and apply those update.
- ASVF (optional): in the CAVE-like environment equipped with the head tracker, we can apply ASVF. This module is responsible for changing the view frustum depending on the user position. In every rendering frame, given the head tracker position, the new frustum is calculated and applied to the camera view.
- Stereo (optional): the CAVE-like environment is usually equipped with the emitter. Therefore, we can have a stereoscopic view in CAVE. In order to use stereo, we need to set the stereo ‘on’ on the viewer setting and then we can also set the eye separation.
NAVER Installation
There are several steps needed to configure the system in order to make it properly work with NAVER.
1. After finishing downloading the NAVER library, unzip the file to the directory of your choice. As an example, the file could be unzipped under the C drive.
2. Once NAVER folder is created, next is setting the environment varibales. Three variables are needed to be added to the system in order to be able to compile and run NAVER.
NAVER_INC_PATH contains the folder's name of the NAVER include files.
NAVER_LIB_PATH contains the folder's name of the NAVER library files.
NAVER_BIN_PATH contains the folder's name of the NAVER binary files.
As an example, those variables will have values as follow:
NAVER_INC_PATH = "C:\NAVER\contrib\include; C:\NAVER\include"
NAVER_LIB_PATH = "C:\NAVER\contrib\lib; C:\NAVER\lib"
NAVER_BIN_PATH = "C:\NAVER\contrib\bin; C:\NAVER\bin"
The values can be changed depending on where the NAVER folder is.
Next, edit the environment variables PATH. Add this values : %NAVER_BIN_PATH% to the PATH.
(In several computers, the order of the environment variable values could be matter. If it is the case, try to put the % NAVER_BIN_PATH% as the first value of variable PATH.)
3. In order to test the NAVER instalation, you can simply follow this step.
a. Go to the ..\NAVER\bin folder. b. Run nvView.exe, with an argument simple.xml. As the result you will see 3D models loaded on the screen.
