One way to craft architecture for virtual reality system is to rely on basic server client architecture where server is running an environment simulation and clients are user interfaces to the simulation.
Essentially client consists of user interface framework (3D rendering engine, 3D sound engine, windows, panels, and widgets), virtual reality model (scene graph and media caches), session management (state machine and session data pool), command interface (commanding avatar), state synchronizer (synchronizing server virtual reality model) and network engine. One of the key design challenges for client is that the user should experience smoothly evolving and plausible virtual reality despite of network and server lag. Even writing stand alone 3D games with smooth game play is not easy. Consequently clients are often written with C++ (no garbage collection lag) and have only one executing thread (no unpredictable short thread stalls). Exceptions to this rule are long lasting and unpredictable operations like hard drive access and network transmission which should be executed in a dedicated thread. Another good design principle for real time applications is “keep it simple (s)” and if possible reserve required data structures at initialization phase (no memory leaks at runtime). If one considers client purely as a user interface it is possible to concentrate on rendering engine, UI-framework and network engine without creating overtly complex system.
Virtual reality server has quite a few roles to fulfill: physics engine, rule engine, artificial intelligence, virtual reality object model, model persistency, simulation control, server management and network connectivity. Network connectivity can be further divided to network engine, command processor, state synchronizer, session management, media sharing and IAM (identity and access management). Many of these roles are clearly separated and it is tempting to divide them to several separate server applications. However complexity tends to cause problems. Heterogeneous distribution is harder to administrate and is more prone to failures than homogenous server cluster with load balancing. One good way to do heterogeneous distribution is to divide real time and non real time functionality to separate servers. Another way is to distinguish between high trust and medium trust services thus separating key services to trusted parties and leaving the bulk computing load to less secure servers. These rules suggest a threefold server division: virtual reality server (bulk computing), identity server(s) (high trust and virtual reality integration services) and file server(s).
Virtual reality server is a near real time simulation application running the virtual environment simulation. The core components are virtual reality object model (simulation state), physics engine (provides elementary physics), rule engine (scripted object interaction and object internal functionality), artificial intelligence (scripted AI-functionality) and simulation control (coordinates simulation execution and rule execution stack). Virtual reality server could be implemented with C++ (high performance) or .NET/Java (higher level language providing cleaner code base). The most common way of load balancing between virtual reality servers is spatial division (each server simulates separate volume).
Identity servers are important building block for global virtual reality where avatars and other objects can traverse between servers. They can be compared to DNS network in architectural sense. Identity servers govern both user and machine identities. They may also govern object identities which are in transit from server to server. Identity information in this context consists of identification, authentication, role, category, statistics and location information. Identity servers need not be virtual reality specific solutions but existing identity governing standards and systems can be utilized.
File servers are version aware file repositories providing all shared files for the virtual reality system: client binaries, server binaries and media files. Existing versioned file sharing frameworks can be utilized without additional requirements.
System components like clients and servers should be relatively easy to develop and integrate. Such global open virtual reality network requires that all system components converse with each other utilizing well defined protocols.
It has been couple of weeks since I bought my first virtual reality gear. I expected another interesting but useless gadget soon to be abandoned to the graveyard of past interests. True enough the clerk at shop greeted SpaceNavigator order with 'Oh you gonna buy one of those weirdo space buttons!'. Right... Well it was too late to back down. I bought my new toy with meager 60 EUR which I secretly considered real bargain compared to any other Virtual Reality hardware out there. The navigator weighted promisingly heavy on my palm...
At home the installation was smooth with no problems what so ever. First things first as they say. I went and downloaded Google Earth which is the demo tool in the marketing videos. I had some previous experience with Google Earth but it had seemed to be a bit unintuitive to use as familiar first person shooter controls (WASD + Mouse Look) were not available. You could zoom in and rotate the globe nicely enough but it did not feel like flying around. When I started Google Earth with my SpaceNavigator I did not know what to expect. First experience was that I could really fast get good grip about how to rotate around and move. The only problem was that the actual movement was frustratingly slow. I went to SpaceNavigator Control Panel and changed the overall speed to maximum. Even with highest speed setting Space Navigator provided excellent accuracy in all axes. Immediately I understood what SpaceNavigator and Google Earth where about. I finally felt in control of my orientation and place in the virtual environment. I had to find some legendary mountain ranges and fly in the canyons. Google Earths beautiful on demand data loading caused some delays and for some reason Google Earth hanged on my computer regularly after certain amount of roaming around. Despite these small but irritating problems I felt like babbling about SpaceNavigator to anybody wishing to listen.
Another major application for SpaceNavigator would be different modeling tools. I figured to try it on Google SketchUp as it is free and easy to use. SpaceNavigator started to work with it immediately, though I had to change the speed from the control panel back to the lowest setting. Even then the overall feeling of the SpaceNavigator with SketchUp left me with nagging suspicion that there was something wrong with the rotations and that the relative speed between rotation and translation was not tuned properly. While only rotating the scene it seemed to regularly translate to some direction or another rendering the rotational functionality around Y-axis pretty much useless. It is possible that I did not really know how to use SpaceNavigator with SketchUp as I am not very familiar with modeling and the tools related.
After these mind altering experiments I finally admitted to myself what was the real application I had subconsciously intended the SpaceNavigator for. I started to look for the SpaceNavigator in the joysticks section. I am playing several 3d games with joystick support and most pressing need is in the bf2142 vehicle flying section as my joystick is big and clunky which tended to get me killed when I tried to switch to it from keyboard and mouse combination. Unfortunately there was no manufacturer provided joystick driver for SpaceNavigator so after some searching I found the following driver from the support site:
http://www.3dconnexion.com/forum/viewtopic.php?t=336
The joystick driver was slightly challenging to install and configure. One would recommend it for people with decent skills with drivers. After installation I got it running easily for bf2142 but for my disappointment the driver did not provide enough flexibility on how movement in given axis is mapped to the 360 degree scale of joy-axis. Due to this I could not really get maximal accelerations using the SpaceNavigator. I added an improved driver to my wish list.
All in all I would rank SpaceNavigator as a must have gadget for anyone with interest in 3D environments. The device seems to be of excellent quality, affordable and with improved drivers the possibilities are limitless. Cheers to 3Dconnexion.
One way to define a system is to list the requirements.
Functional requirements:
Nonfunctional requirements:
Moving from Web 2.0 world to 3D environments will give us new dimension which in turn brings expectation of presence and interaction. When I browse the web I don't mind not experiencing the other browsers. Consider the situation with three dimensional environments. Empty corridors are spooky especially if you know you are hopping inside popular sites. This analogy will bring interesting problems on traffic hour when places get really crowded.
Messing around in three dimensional environments certainly gives you a lot of new things to do but the old problem of good user interfaces remain as you want to use some tool more complex than a lever. One would expect that we don’t ditch the good old solutions like Web 2.0 pages on this instance but rather wrap the old pages on surfaces. Closer look to the interface just pops it in your personal HUD as a semi transparent window.
The bloom of the 3d web is still behind a barrier. The analogy for HTML exists in VRML and X3D but the problem is that the 3D environment has brought new requirements which are not yet incorporated in the standards. For example the ongoing discussion between browser and server about avatar locations, appearances and emotes are blank points. The protocol extensions do not need nor should be complex. Players just need to agree on it and write it down.
These thoughts are comments to interesting post in Susan Wu's Blog
