A Design Tool


Constructing Virtual Worlds

Submitted in partial fulfilment of the

requirements for the degree of

Bachelor of Science (Honours)

of Rhodes University


Bernard Perchman

October 1994

Department of Computer Science

Rhodes University

P.O. Box 94




The cover background is a scan of the work Apples and Oranges, by Paul Cezanne, 1895-1900. Reference: ([CAVEN,1985], pg 404).


This report describes the construction of a Virtual Reality Editor, which was built from two different graphical modelling tools. The Editor environment is built from VR386, a real time renderer, whilst the calculation of motion is achieved through XAERO, a solid body modeller. These tools are dynamically linked over an Ethernet network.

The report covers the substantial research that was required in building the link. This research assessed the system components on a technical level, but also sought to bind the design of the Editor to current Virtual Reality principles.

The technique of distributing rendering and motion calculation lends itself to demanding and sophisticated applications of virtual reality, and a description of possible applications is given.

Key Words: Virtual Reality, Animation, Distributed Graphics, Constraint Based Modelling, TCP protocol, Cognition


I would like to thank my supervisors, Peter Clayton and Shaun Bangay, for their advice and support. Thanks also to members of the Graphics Group, who supplied useful ideas. In particular, I would like to thank Kevan Watkins and James Gain for their technical advice.


Introduction 1

1. Virtual Reality Tools 3

1.1. VR386 4

1.2. XAERO 7

2. Virtual World Modelling 13

2.1. Modelling 13

2.2. Motion Specification 14

2.3. Rendering 17

2.4. A Taxonomy of Graphical Models 17

2.5. A Structured Approach to Modelling 20

2.6. Example of an Iterative VR Model 21

3. The Psychological Perspective 23

4. Current Trends in VR 28

4.1. Interfaces and Standards 28

4.2. Interactive Modelling, Languages and Scripts 30

4.3. Uses of VR 34

5. The Design of the Virtual World Editor 38

5.1 Premises and Constraints 38

5.2. Equating the Two Systems 40

5.3. Flow of Data 47

5.4. TCP Bridge 50

6. Implementation Issues 54

6.1. Package Components 54

6.1.1. Link List Handler 55

6.1.2. Script File I/O Routines 56

6.1.3. TCP Procedures Library 57

6.1.4. Editor Extensions 58

6.1.5. The VSide, XSide, Xemulate and Vemulate Modules 59

6.2. Efficiency Issues 59

6.3. Control Devices 62

6.4. Editor Menus 63

6.5. A Possible Application 67

7. Conclusion 71

8. Future Directions and Research Opportunities 73

References 76

Appendix 1 79

Appendix 2 83


The software package that was produced for this report has been built through the exploration of three distinct trends in Virtual Reality. First, designers seeking the production of realistic movement have been building models that harness ever more abstract levels of motion models. Second, researchers seeking to create comfortable working environments within their Virtual Reality packages have turned to cognitive psychology for effective techniques. Third, with the maturity and growth of Virtual Reality, producers have been specialising their tools, and working towards standardised interfaces. Coupling these tools via distributed processing allows them to optimise their individual functions, synergically producing superior tools.

The software package produced in this report, termed the Virtual Editor, provides a comfortable, accessible design area, in which Virtual Reality scenes are built. The Editor interface is an adaptation of a Virtual Reality construction kit called VR386. Vectors are added to the scene to effect motion, and a rigid body modeller called XAERO is invoked to produce a set of movements from these vectors. The interface is conducive to a range of applications where ease of use is important; at the same time the accuracy of the motion engine provides exactness. Envisaged applications are the teaching of physics, architectural design, and product testing.

This report explains how the link between these tools was forged, and assesses the potential of the resultant tool. It traces the development of the Virtual Editor, as design was motivated by research into these three fields.

Chapter 1 begins with a definition of Virtual Reality, and an account of the tools used in this project. Chapter 2 describes a taxonomy of models, illustrating the concept with a model of a virtual hand. Chapter 3 follows the second trend, examining some of the psychological aspects of virtual reality. In this, it motivates their use to this project. Then Chapter 4 outlines the third trend, the diversification, standardisation, and maturity of Virtual Reality. It reviews the software and hardware used, contextualising the Virtual Editor created in this project.

Chapters 5 to 6 are devoted to the Editor package itself. Chapter 5 describes the proposed relationship of the existent tools, covering the design issues in integrating the products. One of its chief concerns is the conversion routines used between the products. Chapter 6 is a report of the project implementation. Chapter 7 concludes the development, and finally, Chapter 8 outlines possible future development.

Appendix 1 contains an EBNF format of the transferred information. The technical terms in Virtual Reality tend to change meaning with the pace of development, so it was felt that a glossary of terms would be useful to the reader. This is included as Appendix 2.

1. Virtual Reality Tools

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man" - George Bernard Shaw ([ANDREWS,1969],pg 371).

The concept of Virtual Reality(1), once used as an umbrella term for a range of experimental computer science, has recently solidified into a definite field. The Electronic Computer Glossary defines it as:

Artificial reality that projects the user into a 3-D space generated by computer. Implementations [include] the use of a data glove and head-mounted stereoscopic display, which allow users to point to and manipulate illusory objects in their view [FREEDMAN,1993].

In a less ambitious manner, the author of the VR386 package defines it as:

a computer-generated simulation of a three - dimensional(2) environment, in which the user is able to both view and manipulate contents within that environment [STAMPE,1993].

In contrast to its breathtaking portrayal in recent film productions (such as the Lawnmower Man, 1992), actual state-of-the-art virtual reality appears somewhat disappointing. A simple law of efficiency is preventing true virtual systems from becoming commonplace: current hardware and software cannot render realistic scenes at anywhere near the 24 frames per second required for believable animation(3). In fact, to present a completely convincing real time world, we would need to process over 80 million polygons per second. Even if it took a single cycle to render a polygon (instead of hundreds), we would struggle to find a clock that approaches this oscillation [MAC,1992].

Virtual Reality demands intensive computations as each frame is rendered. If the viewer of the scene is at all in motion, all visible objects will require pixel-by-pixel rerendering. Although graphics cards such as the VGA have registers for plotting pixels simultaneously(4), there is a tradeoff between low-resolution, blocky images, and realistic images with slow frame rates. One of the key developmental areas is that of increasing rendering speed, and software engineers have sought methods of distributing this workload, through networks and transputers [BANGAY,1994].

In this section, the two VR tools, XAERO, and VR386 are examined, and their approach to speed/resolution tradeoff will become apparent. They are analysed qualitatively and quantitatively, with attention being given to the concept and target user of the tools. The TCP software will also be introduced in this section, although a protocol description is deferred to section 5.4.

1.1. VR386


VR386 is an alpha-version toolkit, written in C, and requires an 80386 or above. The designers built it at a time when VR kits were sparse, and not accessible on a personal computer platform.

The quintessential property of VR386 is that it renders polygons at high speed (typically several thousand per second [STAMPE,1993]). The rending engine, written in assembler, drives a VGA monitor in 320 X 200 or 400 X 300 mode. Figure 1.1 depicts VR386 with an example application.

Because VR386 is a shareware product, it is available with source code. There is an application header file, which details available procedures, and users can create their own projects without too much coding. Contained within this header are object list manipulation routines, drivers for mice, keyboards, and gloves, and a menu system to encapsulate the functions. The package contains an example main file, which can be used as a template. Armed with the header file, users are able to create powerful applications. This enabled VR386 to be tailored for this project, to become a comfortable working environment, using the research on perception, discussed in Chapter 3.

The designers built a comprehensive library on top of the renderer. There are modules for creating polygons, objects (collections of polygons), trees of related objects, object groups (called figures), and the world itself. These objects can populate scenes, and there is a support module for virtual world maintenance. At the top level, there is a menu- driven editor, which supports a wide range of 3-D equipment. For instance, the power glove is represented as a 3-D hand, with limited gestural recognition, and relatively poor spatial accuracy. The mouse can be used both as a 2-D and 3-D pointer (see section 6.3.). The editor allows the user to access attributes throughout this hierarchy, allowing design to take place at a high level of abstraction.

However, the bulk of the design must be done in script files, for which a specialised language has been composed. It even facilitates animation and conditional interaction. A user can program entire scenes without having to know anything of the code base, although the VR386 coordinate system will need to be mastered.

Target User

VR386 can be purchased with an exhaustive manual (see [STAMPE,1993]). Any naive user can begin to program worlds via script files, learning from the examples provided. However, the user will still have to master coordinate systems, and learn to specify object points in three dimensions. Although the language is simple, it requires intensive perusal. However, it is powerful, and with the conditional constructs provided, the user has enough to build interactive, user-driven worlds. This will appeal to the games enthusiast, although it may not have merit with a designer who requires higher resolution and accuracy.

The concepts of 3-D animation borrowed from the film industry are neatly supported, and camera, light and body positioning can be arranged to effective usage.

VR386 can also be used as a graphical engine by application programmers, who harness the application libraries. However, the convoluted nature of the code quickly becomes problematic. For instance, a programmer who wants to store object attributes together with the objects, use the peripherals in different ways, or modify objects at runtime will need to modify code at a dangerously low level. Unexpected problems that can result include hitting label boundary problems (where the 64k segment is surpassed), running short on memory, and interfering with the TSR's. Implementation problems are outlined in Chapter 6.

1.2. XAERO


XAERO is a BSD UNIX X-Windows application (see Figure 1.2). Only the executable is supplied, and it runs under various UNIX platforms, including BSD version 4. The editor presents the virtual world in three orthographic projections, together with a combined orthographic view. Beside the projections is a list of menu options, which, when selected, give rise to separately-controllable windows. A window of object specifications, force and group additions, the animation studio, and default values are some of the windows that can be invoked.

The user begins by inserting primitive objects into this world (such as planes, spheres, cylinders and cuboids). As each object is inserted, its material composition, dimensions, and pose can be altered. The material is dynamically alterable, and objects could either assume some ready-made material, or be endowed with an entirely customised one. Since the material has a specifiable mass, the overall mass of the object is directly calculable. These objects can be composed into compound objects, be linked via dampeners, rods and springs, and have forces placed on them.

As an aside, the choice of using a sphere, cylinder and cube for building blocks is an interesting one. The Cubist painter Cezanne once remarked that "the painter should treat nature in terms of the cylinder, the sphere and the cone" [GARDNER,1980], but aesthetic reasons aside, these shapes are sufficient building blocks for any complex component. However, designers will probably side with Cezanne in finding the absence of triangular shapes, such as regular prisms and cones, a nuisance. One of the useful properties of the primitive set, however, is that the dimensions of these primitives are specified by one, two or three parameters respectively, allowing easy differentiation.

Once the user has created a scenario, and added the required forces, the animation option is chosen. This window displays a single perspective projection, in which the scene is enacted. The user is able to record and playback scenes, and can resume editing after any stage. The scenes generated can then be sent off to a rayracer, where they are rendered.

Worlds, as well as animation sequences can be loaded or saved, although no superimposition is allowed. The significance of this is that each world is a standalone application. If the user wishes to simulate forces that change, he can step through the animation, and alter forces and groups at a particular time frame. However, there is no interaction between the worlds, no user-driven response, and little variance in the type of actions permitted.

Target User

Were it not for a few obscurities, XAERO would be a very effective window-based design tool. A user can master the object and force placement quite easily. However, the scientific bent of the program is very discernible. The user will need a fair knowledge of physics to tailor world parameters (such as collision step widths, resting and rolling speeds), and object parameters (such as tensility and acceleration factor). However, not every user will need to access these features. Surprisingly, the high degree of accuracy in object specification does not include the pose of the object, which is mouse-driven. This has precluded the package from use as a professional design tool.

The script files generated by XAERO redeem this to an extent. These files are more parameter lists than languages, utilising 6-decimal place precision. They are much too tedious and difficult for hand-encoding. On the other hand, their simplicity makes them amenable for generation on other platforms, as is the case with this project. One saving grace of the script is that omitted parameters are automatically filled in by XAERO. Some error checking is done by the parser, but it is relatively easy to crash the package.

The most recent version of XAERO evidences much development on the raytracing scripts. As a designer of raytraced images, this product excels.

Implementation of forces

Although the forces implemented in XAERO have a mathematical basis (as will be discussed in section 2.2), they are designed to be as intuitive as possible, shielding the user from the complexities involved. With a little practice, the user can harness these forces without knowing of the physics involved in the implementation.

The forces implemented in XAERO are divided into three categories:


Local, and


Inertial forces are rudimentary, being a manifestation of gravity. The user is first required to choose a point in space, which sets the first edge of the force vector. Then the user is asked to specify the force's direction, rotating through the three dimensions as desired. The force will extend from the first point, and along the line specified. The length of the vector is determined by the magnitude of the force, which is the next parameter specified by the user. However, an inertial force is intuitively not expected to be object-specific. A suggestion for a project extension (see Chapter 8), is that a variation of inertial force, termed "overall" force, which will act on all bodies concerned, is added.

When sequenced, the object will move in the direction of the force, tumbling at first, but ultimately settling into a stable trajectory. An analogy of this force is that of a boy pulling a bag by a string, in a perfectly straight line. The bag adjusts until its largest (or heaviest) axis lies along the line of the force (the string). None of the forces have finite bounds, so that the distance from the object does not matter. In fact the visible vector emanating from the start point can be aimed away from the object, so that the propagation from the start point is in the opposite direction of the specified vector. Figure 1.3 (b) demonstrates the inertial force.

The second force type, a local force, is set up similarly. However, this type of force is attached to the object itself. That is, the angle and distance between the force and the object remain constant as both spin around. Again, the force need not be centered on the object itself. An expelled balloon demonstrates local force as it bounces about. Figure 1.3 (a) demonstrates the local force.

The third force type, the guided force, is more obscure. Here, the force that pulls the target object is in fact a second object. This second, propellant object must be propagated by one of the above forces. It tows the target object, at a distance and velocity specified in the force parameters. In the context of this project, the towbar is inflexible.

All these forces do not have to have their center of origin attached to the body itself, but it is not of great value to have an inertial force with its point arbitrarily situated in space. Conventionally, we would expect the force to emanate from an object.

The nature of an inertial force requires that there is friction against which objects can be propelled; this friction typically being a gravity force. However, if there is no floor plane, gravity would cause the objects to simply fall in space. A second assumption made in this project is that there is a floor plane by default, and that the gravity value is set to Earth's. The Virtual Editor has facilities for changing both options.

1.3. The TCP Link

As the Rhodes LAN is an Ethernet network, it runs under the TCP/IP protocol, and an implementation of TCP source was required for establishing the link.

A current copy of Waterloo TCP was downloaded and examined for suitability. It is a standard implementation, written with minimal buffer use in mind. With the functions it provides, it emulates a blocking system, which is what was wanted here. Included in the header are functions to open and close sessions, await data and responses, and to send or receive data. It also comes with a complete error status reporter, which was useful in installation. Example applications included are ping, finger, and remote boot. Speed optimisations are also supplied: the packets can be sent in binary mode, and fast read and write functions are available for reliable links.

The UNIX TCP package has procedures that are used in an identical fashion to the Waterloo package, although internally they are different. Both TCP and UDP sessions are supported, the former being the most applicable to this project. The TCP code written was based on the example applications.

2. Virtual World Modelling

A virtual world is the environment into which a virtual reality application immerses its user. This requires a highly developed toolset. Simulating real world objects with computer graphics requires a reproduction of the laws of physics and motion, as well as the simulation of human vision and perspective. In constructing and animating a virtual world, modelling these phenomena can become a tedious and expensive task for the designer.

The task of the virtual world modeller is better understood when broken into three constituents [UNO,1988]:

Object modelling

Motion Specification


This chapter will consider each of these tasks in turn, then outline their relationship, mentioning some of the current tools available.

2.1. Modelling

Graphical packages which model in two dimensions usually handle processing from start to finish, and are easily mastered. However, 3-D modelling demands a thorough mastery of coordinate systems by the user. 3-D objects, built from two-dimensional polygons, become difficult to visualise and extend. The relationship between objects becomes complex, as they can obscure each other.

Whereas the end product of the CAD is a static world, VR systems must animate this world, through imbuing its constituents with their own motion, or behavioural patterns. An object manager system analogous to an operating system is required to manage this behaviour.

2.2. Motion Specification

In a 3-D world, objects are translated and rotated with respect to three coordinates. They obscure each other, and diminish in size as they move from the camera lens. As any stage manager will testify, controlling objects in 3-D space quickly becomes monotonous (see [FOLEY,1990] chapter 21). When these worlds become more complex, it is impractical to program every step of every object; a better method is to let the objects move of their own accord, with only occasional updates to set them on the right path.

Two common methods of doing this are key-framing (found in products such as GRAMPS, BBOP), and scripting (the method used in ASAS, MIRA-3D, and CINEMIRA). Key frames today are prevalent in animation. Artists producing animations at 25 frames per second would have had to draw that many frames per second, but today, through key framing, they are able to draw start and end frames, then use the computer to fill in the rest ([ELLIS,1993]).

Specifying motion is a non-trivial task, and inevitably we turn to the mathematics of motion for a model of specification.

Newton, through his mathematical model of forces, created a system that models all the properties of physical bodies. Newton's fundamental laws of mechanics, or their approximations, form the basis of any modern motion modeller. Although this modelling is computationally expensive, built-in principles here allowed mathematical simplification through differentiation. In so doing, it became computationally reasonable too.

Newton's premise is that every particle x has a certain orbit represented by x = f(t), where t represents time. The central hypothesis is that variances in the motion of x are solely determined by interactions with other particles. Forces exerted by these particles are defined as the influence that is exerted on other bodies, and are a function of the body mass, and the acceleration of the particle:

f = mx"(5)

Newton went on to postulate the additivity of forces; that is, the particle's motion is a summation of all forces exerted on it. The significance of additivity is that the multiple exertion of forces can be simplified to a single influence.

Another important principle is that of analyticity: "the force of one particle on another is an exclusive, analytic function of the positions and velocities of both particles" ([HESTENES,1990], pg 122). By qualifying forces as exclusive, we imply that no other variables are involved in this calculation. By qualifying the function as analytic, we assume that the function and all its derivatives are smooth, and can therefore use approximations in calculation.

Scientists have classified four kinds of forces: electromagnetic, gravitational, strong and weak forces. The strong and weak forces are concerned with the binding of nuclei and radioactive decay respectively. Due to certain properties, Newton's laws are not applicable to these forces, and strong and weak forces are studied in the field of quantum mechanics. In contrast, "Research has established an astounding fact, that all the manifold properties of familiar physical objects can be explained as consequences of electromagnetic interactions". ([HESTENES,1990], pg 124).

We must further divide forces into long range and short range forces. The former refers to body forces over distance, while the latter refers to forces exerted by body surfaces, forming a model for friction, viscosity and buoyancy. Surfaces consist of many particles, and the principal of analyiticity makes calculation complex, but the principal of additivity allows us to approximate these influences.

If we can classify a force as one of these types, we can calculate its motion strictly as a mathematical function:

mx = f(x',x",t)

Which is known as the second order differential equation. It has been proven that "if f is an analytic function, then this equation has a unique general solution, depending only on two arbitrary vector constants" ([HESTENES,1990],pg 136), that is :

x = x(t,a,b), where a and b are vector constants.

An important corollary to this states that "if the position and velocity of an object subject to a known force are specified at any time, the position and velocity at any subsequent time are uniquely determined" ([HESTENES,1990], pg 132).

In other words, our vector model is a deterministic one. If we were to build a real motion scenario (such as inverting a bowl of marbles), and were able to capture the start state of that scenario accurately, Newton's laws guarantee that the mathematical simulation (therefore the software simulation) will be accurate.

As may be inferred, the power of our model is directly dependant on the accuracy of the start state. There is good justification for having a comfortable and accurate user interface.

2.3. Rendering

Methods of rendering objects realistically are many and diverse. Raytracing is one of the most accurate, but it is too slow to be used in real time. There are a range of modern techniques, which have been implemented on real time systems, typically requiring high-end platforms such as the Silicon Graphics platform. Bump mapping is a technique that adds texture to a flat surface, while Gourand and Phong shading determine the light intensity of polygon corners, and use this variable to simulate illumination over the entire object [FREEDMAN,1993].

Although VR386 does not have any of these techniques, it does posses some rendering ability. Materials can be constructed from metallic or cosine-lit surfaces. The metallic surface has a realistic colour-fade pattern, which is especially convincing on moving or rotating objects. Alternatively, the cosine-lit surface alters the surface's illumination level in response to a light source. The author included both concentrated light, and general ambient light, which affects the intensity of all objects in the world.

2.4. A Taxonomy of Graphical Models

In attempting to discover how rigid body simulators in general, and XAERO in particular, work, a taxonomy of graphical models was derived. This proved to be a useful instrument in determining how the Virtual Editor should work.

The motion specification system is highly theoretical, and its mathematics is often a far cry from the available tools. It certainly adds complication to the implementer's concerns, such as clock cycle, resolution, memory and compatibility issues. The following taxonomy is a system developed to build the model gradually, grounding it firmly in theory, and in so doing narrowing the implementer's task.

Barzel, an important figure in Virtual Reality research, has produced a hierarchical classification of virtual models, a framework which allows developers to match a sufficient model to their application (see Table 1).

Underlying any realistic model is an explicit mathematical model, defined here as a geometric model. Parametric surface models and solid geometry fall into this category. However, physical modelling goes beyond this, because it incorporates object characteristics. It is sufficiently powerful for rendering of objects. The physical model has important significance to animators, because if the objects carry these parameters with them, the system exhibits more intelligence, and the number of motion parameters in keyframing is cut down. Constrained motion control does not exist yet, and to control the physical model, we must specify each phase. This method does not generate particularly realistic movement.

Barzel lays down conditions for a physical model. The mathematics used should describe the model completely, so that the difficulty in representation is decreased. What makes models complex is that they are large, and heterogenous in their makeup. All models should fully describe the set, the intent being to reduce this level of difficulty.

The model must be explicit, with minimal assumptions and minimal discrepancy. Variables should exist globally, rather than being tied to conditions. For instance, it should be possible to write x= .. rather than in this situation x=. It must be a precise mathematical model, with minimal shorthand, and should not be written too specifically.

Where the physical model is a language, the kinematic model is really an administrative system, a framework on which to peg mechanical techniques. It models kinematic relationships between bodies by determining the behaviour of points fixed on these bodies.

A coordinate frame is used, and the velocity, combined with the angular velocity of each body, is calculated at every instant. The frame is fixed relative to the bodies, and points on the bodies remained fixed relative to these bodies. Each body has a unique state, or set of attributes. It must be noted that objects are still independent of each other, with no global forces.

The circular forces enacted on a body are known as torque forces. In the dynamic body model, each body motion is a function of the forces and torques acting on all bodies. The constraints of the entire system are modelled by explicit forces; bodies are described as moving under forces and torques. On the assumption that the model's energy is conserved, energy expended on objects can be tracked.

There are still a number of simplifications to this model: the bodies have a constant mass throughout. This simplification is adequate for bodies with mild acceleration. The velocity is linear, and is a translation of the motion of the center of mass. Wind resistance, therefore, is not a factor in terms of the distribution of the body area and motion.

In classical mathematics, all movements can be accounted for by this model. Dissipative forces remove energy from bodies, whilst active forces add energy.

The Virtual Editor of this report straddles the last two categories. The placement of forces in the XAERO environment relate the Editor most closely to the kinematic rigid body model. The forces are autonomous, therefore the object behaviour is an end product of their interaction. However, the addition of global forces, gravity, and a common surface plane are attributes of the dynamic rigid body model.

2.5. A Structured Approach to Modelling

With this taxonomy, Barzel describes the modelling process formally:

All the models of section 2.3 have three components: a conceptual model, with all irrelevant details included, a mathematical model utilising context free expressions, and posed problems, performed through employment of the model.

The conceptual model describes the problem domain, from which an applied mathematical model is wrought. The conceptual model contains all (possibly irrelevant) details, which provide properties for use in the mathematical model. They are worked into equations (mathematical models), utilising context free expressions. Posed problems are fed to the model, and a physical interpretation is done. From this, the analysis of results provide constraints for the conceptual model. The model hierarchy is climbed by dropping implicit assumptions, and employing more of the conceptual model's information.

Barzel's classification contextualises the Virtual Editor's usage. It must be noted that the parameters available in the XAERO system have been greatly reduced by the Virtual Editor. In a sense, the geometric model has been pruned. However, the physical characteristics, such as light, colour and real time speed now provide stronger feedback. This provides input for more abstract models.

2.6. Example of an Iterative VR Model

The model of a virtual hand created by Lee et al [LEE,1993], is a practical example of the use of this taxonomy. Lee attempts the formidable task of modelling a human hand. The hand is a complex object, with 27 degrees of freedom. Because it is covered by a deformable skin layer, it cannot be represented by a solid body model.

The hand's movements are a direct function of its skeleton, and this skeleton forms an ideal starting point for the model (see Figure 2.1). Guo comments that skeleton-driven deformation, where the "skin" is deformed around a mechanical skeleton, has actually been used as a model in numerous film animations, such as Snow White.

The first phase of modelling is to geometrically describe the hand. Lee labels each mobile part of the hand, providing a variable for each, and setting coordinates for each. By studying the bone structure, it is possible to determine positions that the hand can or cannot assume (such as bending the fingers backwards), and these become a set of static constraints. These constraints limit the degrees of freedom achievable by the component. At this stage, the model may be perceived as a solid body system. The next step is to use the science of kinesiology (the study of movement) to determine the dynamic constraints of the hand. Relationships between the fingers (such as the effect of movement that each has on the other) are modelled. Figure 2.2 depicts this system. The model is now a kinematic rigid body model.

Kaufman terms this mathematical motion of the hand an intrinsic one, because it models the motion of the hand, rather than its appearance. To progress to a physical model from here, a extrinsic model to emulate the movement of skin is created. A pliable 3-D hand is bound by a set of virtual springs.

The final step is to mathematically model the torques generated as functions of these springs, to determine the degree of deformation (see Figure 2.3).

Notice how in the dynamic rigid body model, the object's behaviour in context of its environment is of interest. This model exemplifies the development cycle traced by Barzel [BARZEL,1992]. From a simple model, assumptions are gradually lifted. Each new consideration is mapped to a model, to derive a set of equations, which are in turn used as entry points for the next level.

3. The Psychological Perspective

In creating a single package from two overlapping applications, only certain features from each could be preserved. It was found that the measurement of these features could not be done objectively. The research on psychological aspects of VR that was undertaken not only provided answers, but brought new applications for the Virtual Editor to light.

VR has taken CAD a step further in representing reality. Stampe [STAMPE,1993] ascribes the difference between CAD and VR in terms of mode of involvement. When a scene is created through a projected experience, the user is distanced. This is analogous to a child's experience of playing with toy cars. In contrast to this, Virtual Reality advocates a personal experience (analogous to a child's experience of a group game). The process of becoming involved in the experience is termed immersion, and it is effected by visual cues. The faster the immersion, the more realistic the personal experience. In contrast, fatigue, display lags and discomfort caused by headgear destroy the virtual experience.

A primary research aim of this project is to produce a user-friendly interface, thereby achieving a personal experience. The methods of evoking this sort of experience are studied in a branch of clinical psychology called perception. Virtual reality has borrowed many of its precepts, and this chapter explores the ways in which perception theory can improve this interface.

The unvarying precision with which a computer performs, whilst an essential success factor, can detract from its value as a model of reality. A crucial human factor that is often overlooked in simulations is the fact that the accuracy of our sensory perception is not linear. Weber's law states this phenomenon in terms of stimuli: "As the stimulus magnitude increases, so does the size of change needed for discrimination to occur" ([COREN,1979], pg 31). In fact, the tediousness of working in total accuracy is a disturbance to the immersion effect more than it is an assistance.

Virtual reality succeeds only because it exploits this, for instance in the speed of the frame rate. In designing the Virtual Editor, the stance was taken that total accuracy is not required. However, accuracy of design has been built in as a fine editing feature. In this editor, the glove or mouse in is used to position the objects roughly. Placed objects can then be edited, and have their coordinates altered numerically.

When objects that are moving on a fixed line cross our field of vision, the trajectories they produce are not linear. Figure 3.1 shows optical streamers travelling in straight lines. If a virtual reality system is not capable of modelling these patterns in object movements, virtual scene quickly loses believability ([KALAWSKY,1993], pg 59). This is a weakness of this Virtual Editor, because the movements returned are mathematical coordinates, which are rendered autonomously in a perspective projection

Our sense of perception can be divided into two perspectives: egocentric localisations (how we perceive ourselves in our world), and object relative localisation, which is our position relative to other objects. This contrasts the model employed by physicists, where objects are perceived as relative to each other only. Virtual reality systems tend to use the egocentric axis, which is centered on the user [KALAWSKY,1993]. Generating the user's body parts, to become visible at the appropriate time, is a strong visual cue.

We can perceive in three dimensions because we are capable of depth perception (perception of the distances between objects). We are able to do this with the help of depth cues. The difference between our left and right eye images is a fundamental depth cue, but we also make use of pictorial or monocular cues, which we descry with a single eye.

Epstien and Baratz postulate that familiar size is an important cue in determining depth (consider photographs where a coin is placed beside an object to emphasize its size). Related to this is the height of the object above the horizon as an indication of its distance. One option considered, but not implemented, is to draw scaled axis lines in the screen corners, so that distance can easily be gauged.

The lack of these depth cues are very apparent in the XAERO editor, and the difficulty of working in its environment is noticeable. This was an important factor in assigning the roles of the various tools (see Chapter 5).

Textural gradient offers a useful depth cue, because we calculate the distance of an object from us by the reflection of light on it [BERRY,1986]. The wireframe objects utilised by XAERO have no thinned edges to indicate that they are hidden, and no surface material to aid distinction of form.

Its design area consists of three orthographic projections, together with a multiview orthographic projection. Even through the orthographic view is useful in accurate reproduction, it sacrifices linear perspective, another important cue. The XAERO camera animation, however, provides a perspective projection, which is more comfortable. Object perception is easier in this scenario, because rotating wireframes are more comprehensible than stationary ones. It must be noted that the lack of cues in this product is deliberate; they have been sacrificed for scientific accuracy.

At the other end of the accuracy scale is the glove handling capability of VR. The hand image tends to jump and jitter, diminishing the three dimensional effect. However, the aid of the glove in 3-D perception is undeniable. The glove simulates what psychologists term kinaesthesia(6), the perception of depth by touch.

Despite the fact that the touch stimulus is not present (although gloves with controllable pressure pads can be purchased), the movement of on-screen objects induced by the glove is a compelling cue.

Good perception is only achieved with a comfortable working environment, and the positioning of the camera is a key factor. Viewers tend to become very uncomfortable with cameras that are angled [FOLEY,1990]. Moreover, the shape of the camera port is important (screens are produced as rectangles that are wider than they are long because of this). It was decided that a mobile camera would be more useful than a static one. Pinning the camera to the glove was not appealing, because of its erratic movements, and it was decided to include options to set the camera coordinates. It must be stated that, although cognitive psychology has developed a precise classification of these phenomena, it has also produced findings that they are by no means shared by all viewers. Berry, in his paper: Cross-Cultural psychology: research and applications[BERRY,1986] asserts four factors that differentiate the way that people perceive: physical, environmental, genetic, and cultural factors. Campbell et al forwarded the carpentered world hypothesis, which postulates that people who live in regularly-shaped environments are more amenable to visual clues than those who don't [COREN,1979]. It is even suggested that subjects of cultures lacking in pictorial tradition cannot perceive three dimensions in photographs. In 1960, Hudson investigated this phenomenon in an interesting test: subjects were asked to identify the elements in a hunting scene (Figure 3.2), and then to decide if the hunter was aiming for the antelope or the elephant. His findings were conclusive; almost without exception, subjects with no pictorial tradition thought that the Hunter was aiming for the elephant(7). Deregowski later proposed that picture perception was only possible by means of a set of skills, even more so if the cues are impoverished.

Apposite to the carpentered world hypothesis is the sophistication hypothesis; that through learning to interpret patterns, and exposure to pictorial materials, people can become susceptible to visual illusions.

However, these differences are less extreme in our modern society, and there is little need to compensate for such perspective differences in a project of this size. Nevertheless, the area of cognitive psychology holds promise for future virtual reality applications. Virtual reality could become a powerful teaching aid of the type required by the sophistication hypothesis.

4. Current Trends in VR

From the examination of the two VR tools, it was apparent that both could benefit from each other. However, of what value would the resultant tool be? Exploring the current development of VR revealed how designers had specialised their tools, and integrated them with complementary tools. This exploration was also done in the hope that existent ideas and standards would provide a simple means of interfacing the Virtual Editor components. This chapter explains some of the standards found, and goes on to discuss the role of graphical languages in VR. Finally, it outlines some relevant current applications.

4.1. Interfaces and Standards

Sharing graphical information between graphical systems would seem to be a commonplace event. Research was undertaken to discern what graphical standards did exist, how well utilised they were, and their pervasiveness. Reviews of state-of-the-art technology were scrutinised for the current status of graphical standards.

Although none of the standards found seemed suitable for the task, a good deal of relevant work was discovered. It was ascertained that modelling in script files is still a popular option, and that graphical languages written for this purpose exist.

Scientific applications seek to formalise and quantify; in contrast animaters work on an expressive, artistic, visual level [GUO,1993]. Trends in VR have been running in both directions. Simplification and reduction of detail is evident in the XAERO modeller, and is found in simulators such as flight simulators; while VR used in animation adds detail and complexity to the scene[WILLIAMS,1993].

Standards for VR have not appeared (although standards for its individual components abound); consequently, most VR business applications are custom-made from developer kits [PATCH,1993]. From the discussion on the complexity of VR in Chapter 2, it should be evident that standards would have to be built over a substantial number of levels. Consider the problem of porting graphics: Bit maps of graphics are particularly difficult to port, because they are dependant on the resolution of the screen in which they were created [FREEDMAN,1993]. VR developers find building onto existent products difficult.

However, compatibility has been a more successful endeavour where underlying graphics standards, such as PHIGS (Programmer's Hierarchical Interactive Graphics System) have been used. Graphical languages offer an efficient method of storing graphical information. This has been put to good use; the PHIGS standard outlines a graphical language used with great success by high - end workstations.

PHIGS was one of the earliest graphical specifications(8). Built as a language independent concept, it has strong bindings with Fortran and Ada. The language primitives consist of polylines, points, regular shapes, and other primitives that can be found in most conventional languages. Complex polygons are composed from primitive structures. It is assumed that there is a device -independent conceptual workstation, supporting a two-dimensional screen. Similarly, input devices are logical as opposed to physical. The significance of this functional decoupling is that the graphical model can be described independently of the output device. PHIGS defines an administrative architecture through which applications can share graphical information. Today, PHIGS++ has been extended to include such aspects as light source illumination, shadowing and reflection [SIMONE,1994]. PHIGS++, a revision of the GKS standard called GKS-91, CGI, and other standards are contending for a position in ISO and ANSI standards [JERN,1988].

Unfortunately, documentation of the PHIGS language was discovered too late in the design phase for it to be used. Its adaption is one proposals that will be suggested in Chapter 8.

Concerted industry standards are also evolving to bring power and standardisation to graphical interfaces. A notable attempt to standardise hardware is the VESA (Video Electronics Standards Association) card. It was founded in the 1980s, by NEC Home Electronics, and eight video board manufacturers. It defines standards for the VGA and Super VGA monitors, as well as for the bus used. The speed built into the bus is 40-66 MHz, sufficient to include the Pentium standard [NEWTON,1993].

Its main goal is "to standardize the electrical, timing, and programming issues surrounding 800 x 600 pixel resolution video displays, commonly known as Super VGA.". ESA has also issued a standard called "local bus", a new PC-based, high-speed bus, designed to move video between the CPU and the screen more quickly than the conventional AT bus does [NEWTON,1993].

A software standard adopted on the development level is the IDE standard, which has been implemented on languages such as Clarion, BORLAND C++, and Visual Basic. Newton defines the IDE as " A [...] program within which a developer may perform all the essential tasks of development including editing, compiling and debugging" [NEWTON,1993].

4.2. Interactive Modelling, Languages and Scripts

Alternative development environments were surveyed to find ideas for the Virtual Editor. Two schools of thought dominate modelling: that of interactive on-screen modelling, and that of script file writing (a pencil-and-paper approach to design).

VR development is seems to be more inclined towards interactive modelling. In interactive modelling, the user the advantages of a WYSIWYG (What You See is What You Get) interface. The user can see what he is designing, and can easily alter his demands. Yet the script file(9)

cannot be wholesomely dismissed as an alternative medium, due to its accuracy. The user programs a world, using a specification language. Often, these script files are hierarchical, beginning with the attributes of the world (such as light and gravity), and working down to object attributes. The object oriented paradigm is well suited to virtual world programming, and object oriented VR languages are a vital research area.

While script files are more difficult to visualise, and tedious to program, they have the advantage of being less implementation-dependent. The information in the script can be ported between different graphical systems, requiring only a conversion parser. Such a utility seldom demands intense processing. Figure 4.1 is an example of a script file, taken from VR386. The editor described by this report saves its information in ASCII script files, and although it does not have comprehensive parsing facilities, it does leave scripting as a development option for the user. The simplicity of the script language also makes the virtual worlds portable for other software.

The following applications exemplify these two design approaches. It must be noted that most of them precede VR386, which strives to simplify what these provide.

A recent product which addresses the demands of the virtual world designer is a language called SCL. With over 500 commands, it allows four levels of worlds, analogous to Barzel's models: static, physical movement, behavioral, and true artificial intelligence. Objects can be controlled through message passing techniques, and the programmer can work interactively in his designed world, on a frame - by - frame basis [ELLIS,1993].

AVENUE, a VR editor, uses its own Data Description Language (DDL) to model objects. In turn, Orientation Description Language (ODL) is used to model connected structures, and motion is modelled with a rule - based system called ROMA (Rigid Objects' Motion Analyser).

Interspersed frames are created with the DDL and ODL, and the animation is interpolated. The animated sequence is interactive; the user can alter parameters via a set of 8 dials on the screen. Design is fast and intuitive.

The Caligari trueSpace for Windows 3-D Editor, one of the latest-generation 3-D editors, is oriented to interactive design. Running on a PC platform, its ease of use and moderate price make it appealing to non-specialised users.

This completely icon-driven application has an integrated 2-D, 3-D, rendering and animation environment, which can drive the 1024 X 768 mode (see Figure 4.2). Objects are manufactured from wireframe forms, which can then be individually or collectively raytraced. It features advanced facilities such as deformation lattices, UV mapping, keyframe and path-based animation.

The product renders wireframes in

real time, and has a full raytracing facility, which can generate standard graphical formats (such as TIFF and AVI), to be used by other graphical tools. TrueSpace lacks numeric coordinates and accurate alignments, eliminating it as an engineering tool, but its ease of use places it firmly in the video art and multimedia categories [GUO,1993].

The VREAM Virtual Reality Development System, a predecessor of VR386, is a state-of-the-art editor. Running on a 386/486, (25 MHz up), and requiring 4 MB Ram, it supports a variety of 3-D devices, and facilitates the construction of surfaces, cubes, spheres, and more complex wireframe shapes. Although it is interactive, it has facilities for script file modelling [RAMSAY, 1994]. VREAM can accept PCX and other CAD file formats, as well as VOC sound files. It can texture - map PCX bitmapped surfaces onto its objects.

This product was built with flexibility in mind. Like VR386, it supports a variety of screens and 3-D peripheral devices, but where it betters VR386 is in its user-specified screen resolution. The user has control over the resolution\speed tradeoff.

The designers have compensated for the difficulty of 3-D design by allowing script file development, at the same time supplying an icon-driven world editor. VREAM has a sophisticated hierarchy of design, from worlds, to rooms, down to polygon segment. Both the environment and the objects have attributes, which can be attached at various levels of this arrangement, simplifying design. This system allows partitioning, so that only a the required part of the world is loaded into memory at any time. The script files utilised by VR386 (not exploited in this project) are very similar in this way.

4.3. Uses of VR

Section 4.2 outlined some current virtual environments. This section examines applications produced in these environments.

The range of potential VR applications is surprising. While the entertainment and leisure industry is the most obvious employment of immersion, other business applications are emerging. The lack of standards, despite being an encumbrance to developers, has not impeded the growth or diversification of VR applications yet.

Recently, purpose-built Desktop Virtual Reality machines, based on common processors such as the i486 have emerged. This machine has a VESA bus and a specialised VGA, and with its 50MHz clock, it is capable of rending 500 - 5000 polygons per second [OLCKERS,1994].

One of the fastest systems documented in the literature (although presently still in development) is Simulation Devices Incorporated's VR 2000 image generator, driven by the DEC Alpha AXP 21064 dual issue processor. This processor runs at 150MHz, and with its 64 bit addressing ability, it is reputedly the world's fastest chip. At US $55 000, these systems will be able to sustain a 20-player VR scenario, and will have a major impact on the entertainment industry (such as the animation and games industries) [ELLIS,1993]. On a similar level, the fastest custom-designed graphics hardware is the Silicon Graphics range, a requisite for most current major graphical applications, such as volume visualisation and animation [GUO,1993].

These machines are pioneers in the field, and a good deal of reengineering will have to take place in the foreseeable future, when standards finally emerge.

Behavioural Modelling

NASA hopes to use a VR system to model a space station, while automotive industries use VR to create new cars, and to test robot behaviours, before installing them into the production line [ELLIS,1993].

Enhanced Reality

Designers at Columbia University have created an application that assists with laser printer repair [ELIOT,1993]. The user wears semitransparent goggles, and then looks through them at the real subject. The graphics that are generated on these screens highlight or indicate key areas on the printer, guiding the user in his repair. This exemplifies a form of VR called enhanced reality. Williams describes a technique for enhancing existent videotape. The video image is fed into the computer, which creates a 3-D relief map from the texture. Graphic art techniques are used to enhance this film. Such techniques include the use of soft drop shadows (opposite the direction of lighting, and dropped into the silhouette to bring it out more), and soft highlights [WILLIAMS,1993].


The dynamic rigid body model, used in animation, produces truly intelligent movement. One silicon graphics product, Iris, is used to create realistic animations, at a low complexity cost, through a parametric technique. A required movement is plotted in a single dimension, using a rough guide. The frame space (space between the key frames) is large. However, in between successive points, the movement can be altered in detail, while the general pattern does not need recomputing. This is a very efficient method of producing animation [GUO,1993]. Adaptive animation has found favour in the music industry too. Sensors are hooked up to a live actor or singer, and the motion which is recorded is fed to an image generator, which maps it to stored images. Animators can use this to give life to any animate or inanimate object [WINTROB,1993].

Sociological Models

Virtual reality attempts to model our world in more than physical respects; it becomes a useful tool for modelling sociological patterns. One interesting application called VEGAS (Virtual Egress Analysis System), places 200 humans in a burning building, and calculates the movement patterns and survival rates of the crowd. The simulator could be of great value to building designers and firemen alike.

Volume Visualisation

Volume visualisation is another aspect of virtual reality that is stirring interest. Volvis, a volume visualisation package, has been designed to minimise these constraints. The user is given the option of which drawing algorithms to choose, so that he can optimise on speed or accuracy. Volvis is capable of raytraced animation sequences, which are produced in its Animator. However, it also features a Navigator facility, in which the user can examine his virtual scene, and create animation sequences at 10 frames per second. Naturally, the navigator works on a coarser grain. Real animation produced at this speed would be jerky, so the Animator interpolates between the scenes, to produce a smooth motion [KAUFMAN,1993].

Education and Training

Macromedia Inc.'s Smart 3D is a sophisticated modeller, which has been adapted into a medical surgery simulator. The tearing of sensitive tissue, the spreading of blood, and the movement of the muscles can now be experienced in training by medical students [CORC,1993].

On a more fundamental level, VR is being applied as a teaching method to the Sheppard School for the Learning Disabled. Teachers there have been using the Makaton symbol and signing system to teach vocabulary skills. Implemented in a 3-D world, seen through a virtual car, the system has become an exciting experience for the children. Interpretation of the two-dimensional symbols has now been enhanced with vivid colour, movement, and aural stimulus, increasing the interest level. The technology is being met with enthusiasm, and already one child has improved the control over her wheel chair through its use [AI,93].

The Editor of this report has merit as an educational device, and possibilities of this will be discussed in Chapter 8, Future Direction and Research Opportunities.

5. The Design of the Virtual World Editor

This chapter describes the design of the Virtual Editor. It begins by summing the influence of the related research, through a set of premises and constraints. It goes on to describe a conversion process, and the work it entailed. It concludes with an analysis of the system's efficiency.

5.1 Premises and Constraints

In order to make this project technically relevant, an attempt was made to model current trends in software, and particularly, VR. The following list of premises sums up the concepts expressed in the opening chapters. Again, they are classified into the three trends recounted in Chapters 2 to 4:

Mathematical basis must not lose accuracy

As far as possible, the parameters in XAERO concerned with motion (such as pose, material substance, force scale) are kept accurate. Unaltered parameters are kept intact, and alterable ones can be changed by numerical entry, as well as mouse movement.

Ease of use

VR386 requires an exhaustive knowledge of C, and its ideosyncracies do not make it a very adaptable tool for the average user. XAERO, on the other hand, while hosting a windows GUI, is slow and tedious with design, requiring a background of physics. The Virtual Editor was designed to be easy to learn and use, whilst still being optionally expandable.

Speed is a stronger criterion than memory usage

Virtual Reality requires graphics to be as fast as possible, which makes this the overriding criterion in any speed/size tradeoff. All possible speedup techniques in the language were used, and the system was designed in such a way as to spend minimal time on the rendering cycle.

Input devices made optimal for their functions

While mice are very accurate, they do not work well in the 3-D domain. Here, a glove is more intuitive. However, since the glove is not accurate enough for fine work, an optimal mix of mouse and glove was attempted. Minimal use of the keyboard was made, and where it was used, this was done as conveniently as possible.

Standard project components

The platforms, operating systems, and peripherals, with the exception of the Power Glove, are all standard issue. It was felt that the system should remain as portable, and therefore as standard-compliant, as possible. Although the current menu system for VR386 does not comply with any specific standard, the emerging IDE standard was used as a guide. Another application of standardisation is the interoperability over the two operating systems, which uses ASCII buffers and files, and TCP sockets.

Existent tools will not be altered

This is a short- duration project, the thrust of which is to build a good foundation. Although the code written was of necessity tailored to the current versions of software possessed, the source product code was altered as little as possible. Where functions were changed, they were rewritten in a separate module. In principle, XAERO and VR can be upgraded independently, and future work on this project can be conducted by using their documentation.

5.2. Equating the Two Systems

Many methods of interaction between the systems were considered. XAERO can run in batch mode or in Windows, can load and save worlds as scripts, and can output raytracer files. VR386, in addition to having a script language, has (as yet unfinished) facilities for saving and retrieving worlds.

Table II lists some of the more feasible options considered. Once it was ascertained that sharing a common operating system was impossible, a TCP socket link was the logical option.

Settling on option four meant that the data flow could be tabulated. The XAERO documentation had come with a specification of the script file. VR386 would be adapted to produce the input script in a better way than XAERO did. The output of the XAERO engine was known exactly, and conversion back into code for VR386 would be trivial.

The next step of the project was to find out what the XAERO and VR386 objects had in common. XAERO's primitives cannot change shape, although their attributes (size, colour, and texture) can be changed. Table III displays the corresponding object attributes.

There were a number of notable differences, which would require conversions. In the Virtual Editor, lists of objects, forces and materials are created, and it was found necessary to store each created entity with information used in the conversion process. To this end, a generic doubly linked list structure, based on the reusable data structures of Sessions [SESSIONS,1989], was built. The list element types and search procedure can be instantiated at runtime.


In addition to its red, green and blue (rgb) values, an XAERO material also has transparency, friction and roughness. Other important parameters are density, dynamic friction constants, and static friction constants. XAERO supplies a material window in which to view these materials (Figure 5.1), and because recreating this in VR386 would be a major undertaking, it was decided that the original material list should be created on XAERO, and transferred down to VR386.

A VR386 material has only a 16 bit code associated with it. The first bits classify it as metallic, cosine-lit or glass (modes 0,1 and 2 respectively). These three materials have different effects - a glass object is constructed of alternating pixel rows, through which obscured objects can be seen. The last 8 bits signify a colour code. There are 10 colours, each of which can have 16 shades. The adjacent colours do not follow the colour wheel strictly, although they are approximately RGB distributed.

Figure 5.2. presents the conversion algorithm used to convert from XAERO to VR386. No reciprocal of this function was required, since the materials are created on XAERO.

The algorithm uses the C convention y >> x to indicate 2xy, and 2-xy for y <<x.


Although the products both support the concept of graphical objects, their representations are vastly different (see Table III). VR386 objects, as compilations of two dimensional polygons, may have different coloured structures within them, and can have a minimum of two to a maximum of many thousands of constituent polygons. It is even possible to have different representations for an object at different resolutions. This optimisation is useful, because creating curved objects such as spheres and cylinders from flat polygons is expensive. The sphere and cylinder creation functions have a resolution parameter, determining the number of polygons used. This has been set to a low value.

VR386 objects may be manipulated in lists. The application header file defines procedures to work with objects at the individual or at the list level; Recolouring, highlighting, resizing, deleting, and even reshaping is possible. These object lists could not be used, firstly because their element structure was not redefinable, and secondly because VR386 automatically

switches objects between them as they become visible or invisible. Strangely, there is no direct way of accessing objects, such as a name or a key. Therefore, there is no accessible structure that contains the object's dimensions.

Moving an object is simply a matter of updating its pose. The application script language contains code for movement routines, such as looped sequences. VR386 has a multiprocessor for simultaneously updating all the objects.

XAERO objects are at a higher level in the model hierarchy. An object can be one of only six types (spheres, cylinders, cubiods, planes, nails and springs).

Object attributes such as material,size and pose are changed interactively, via the associated window. In the script, the object's current attributes, together with a key number are printed out.

One of the simplifying assumptions made was that the Virtual Editor would not employ all of the XAERO facilities (see section 5.1). It was decided that nails and springs, used to link objects, would be too complex to model at this stage, although they might possibly be incorporated as an extension (See Chapter 8). It was also decided that planes, besides the floor plane, would be too complex, because VR386 planes are functionally very different to XAERO planes. Therefore, VR386 equivalents of spheres, cylinders and cubes were created(10).


While VR386 uses X,Y and Z integers for rotational values, XAERO uses quaternions. Since rotations can be altered by both products, conversions in both directions were necessary.

Some conversion code was found in a graphics library distributed by the University of Alberta. The package was compiled by Robert Lake, 1993. The world scales of both products can be set. VR386 coordinate values must be scaled down by a factor of 400 to be equated with XAERO.


In VR386, objects can be physically linked together, therein being grouped into hierarchical trees. Although each node object retains independent movement, the movement of the parent controls the movement of the overall object.

In XAERO, however, the grouped objects actually assume a new object identity, of a type called compound. This compound object has its own key number. Since all objects are attached to it, there is no concept of a hierarchy here.

Two problems became apparent here: firstly, that the hierarchical object structures of VR386 had to be flattened, and secondly, that the numbering system had to be recast (considering that XAERO created an extra object number for the grouped object).

Solving the first required a data structure extension. The grouped objects were still going to need a parent object, to which the other members could be attached.

The solution was to give list elements extra pointer parameters, which were used to link together grouped objects into a doubly linked list. Then a status symbol was added, denoting if an object was the first, a group object, or still single (F,G or C). All objects own group pointers (which we will term GPrev and GNext in this discussion). It the case of a single object, these are grounded, while in a grouped object, point to the predecessing and following neighbours. Finally, a First object has GPrev pointing to at least one object, and GNext pointing to the last element in the chained group.

When the user wishes to group two objects together, a large set of cases must be considered. It is assumed that if these two objects are already part of groups of their own, the groups should merge, and only one First is appointed. The various cases are summarised in table IV.


The issue of object numbering has been touched on before. What follows is an in-depth discussion of the problem and its solution. XAERO numbers its objects with an I-number, this being the chronological creation order, and a K-number, the order that the objects are put to a script file. The necessity of two number systems is somewhat obscure.

The objects created are VR386 is assigned a single key number, this being part of the object information sent across the link. As the VR386 objects are fed in, the key is read in as I, while K is auto-incremented. This K is the object number output to the XAERO script file. When the returned script is parsed, the K is matched to its associate I, and can be discarded. It is this I that is sent back as the key to the Virtual Editor object.

The compound objects are more complex. Since they need an extra k number, a compound object counter is started at N+1, where N is the number of objects. This is the K number of the composed object; it must be written as so to the script, but can then be discarded. However, each member of the compound object receives N and K numbers as above.

When the forces are read in, naturally they refer to the I number of the objects, but the K equivalent of the I number must be taken from the script file.


Both products have sets of useful parameters which can be altered at runtime. However, in keeping with the simplicity principle, these parameters are set to reasonable defaults. For example, gravity is set to 9.635 ms-2, and the floorplane is set to on.

The defaults are recorded in ASCII files, which are read in on invocation. Procedures for altering defaults, or resetting them to the originals, do exist.

5.3. Flow of Data

After formalising the conversion process, the flow of data could be modelled. Figure 5.3 is a data flow diagram as viewed from the VR386 perspective, and Figure 5.4 models it from the point of view of XAERO. The data flow diagrams (DFD's) have been constructed in accordance with the Gane and Sarcen method (see Harwyszkiewycz [HAWRY,1991], Chapter 6)(11). Appendix 1 contains an EBNF description of the data. In the following explanation, the notation {X} is used to denote the description number in this appendix.

Both DFD's encapsulate two distinct procedures. Processes (1) and (2) of Figure 5.3, and processes (1) to (3) of Figure 5.4 deal with the materials list, whilst the rest deal with scene interaction. From the VR386 perspective, Process (1) must be called at least once. When called, it receives a specification of materials (VR386 Material list file, per {2.1}), which is a list of material names and corresponding codes. This set is incorporated into the defaults file, which houses global defaults for the Virtual Editor {3}.

Invocation of the Virtual Editor begins at process (4), when the defaults are loaded into a default list structure. Processes (5) designates the addition of objects and force to their respective stores. Transmission occurs in process (6). Note that the data sent at this point is only what is strictly required; see {4}. The movement list that returns is even briefer, see {6}. Here, position and rotation of each object are only recorded if there was a change from the previous frame.

Figure 5.4 takes the XAERO perspective. Processes (2) and (4) represent flow generated by the alteration of the materials. As can be noted from {1}, this constitutes a substantial information flow. Process (3) cuts this data by a factor of 11(12). The materials are stored into a material list by process (4).

The batch program launched by VR386 (which we will term Xemulate) collects these, and other parameters, from a default file (process (5)), and transfers them into a default buffer. When a request from VR386 arrives, process (6) bundles these buffers together, producing an input script file for XAERO. It must be remembered that the XAERO script files were designed with completeness in mind. Each frame generated by the script has a complete specification of any changes that have taken place in the world, including default parameter values and material descriptions. If parameters are omitted in the input file, the package generates defaults and inserts them. On a measured run, an input script file of 1522 bytes was expanded to 2189 bytes, an increase of 44%.

The returned script is then picked up by process (7). A great deal of superfluous information must be extracted from the file, including the initiating scenario. The final script file, specified by {6}, is transported back to VR386.

The flow measurements produced in this section, and the file sizes of Table V were ascertained by creating a very simple world on VR386, and measuring it at each stage. The sizes are only approximate, due to the variance in size that can be produced; however, where possible, the worst-case was measured. The table demonstrates the unfortunate effect of having chosen the fourth option of table II: only 7.17% of the data transfer occurs within buffers, the rest being transported in files.

An important observation to be made here is that the script produced by XAERO contains only a set of movement directions, indexed by a key. This notion closely parallels the PHIGS distribution model, employing a traverser, which feeds off a central structure store.

5.4. TCP Bridge

The TCP software was capable of supporting both TCP and UDP (Unreliable Datagram Protocol) sessions. Briefly, TCP establishes a reliable two-way connection, whilst UDP sessions are connectionless, meaning that acknowledgement of reception is not returned. UDP is thus useful for broadcast. Its simplicity makes for a fast channel establishment.

However, this application was deemed applicable to TCP, because:

The precise timing and sequence of transmission is known, although the message size was not.

Transmission has to be reliable, because the remote application is run in batch mode, removing any runtime control from the user. Reliability in this case is a higher priority than speed is.

Figure 5.5 displays a petri net representation(13) of the TCP link. An explanation of transmission follows: From the DOS side, a call to execute the Unix tcp facility is run (1), booting it via the UNIX port 512 (2). Once the Unix application is up and running, it goes into a receive-wait block (3). DOS now closes the execution socket, and opens a communications socket on port 8000 (4). It immediately sends data, and then goes into a receive-wait block. On the other side, the Unix facility receives the data, and returns a reply (5).

The Dos remote-execute is performed when the VR program is first invoked. The Unix facility goes into receive-wait, until such time as data is received. The VR program can now transmit world information up in batches, but when it finally exits, it must send a poison pill to the Unix facility (6), so that it too can terminate. The buffering system used for data transfer is simple; optimising it is one of the possibilities listed in Chapter 8. The script information is collected into a large buffer, and then shunted across the network. On the other side, it is read from the socket into a large buffer, and then peeled off and parsed line by line. Effectively, the information is scanned twice at each end. However, the motivation for this is that greater flexibility is built into the system. The per-line reads and writes are done with sscanf and sprintf respectively, allowing the c i/o script language to be used. The alternative would be a painstaking parsing method, requiring a duplication of the number-character conversions that these facilities provide.

6. Implementation Issues

This chapter begins with a discussion of the software written for the Editor. At every stage of design, speed and efficiency were a necessity, and section 6.2 addresses this issue. Section 6.3 discusses the peripheral device problems that were encountered. This leads to a description of the menu options created, in section 3. Finally, a possible application of the Virtual Editor is discussed.

6.1. Package Components

Planning the content and constraints of the data transmission, and establishing the bridge was done in the design phase. The next two phases of design, creating a higher level menu, and optimising the script files, had to be done by tracing the existent code. The library family that was built is depicted in Figure 6.1. At the time of submission, this code amounted to more than 6350 lines.

All the code was first written on the DOS platform, with the assistance of the Borland C++ IDE. Simulations of the entire process were executed with file-based i/o, before components were ported to the Unix platform. These components were compiled under ANSI C to minimise porting discrepancies; those that remained utilised Borland C-specific functions where they improved on their ANSI equivalents. Despite being less tolerant to pointer dereferencing, and lacking a few functions (such as atoi, a function to convert ASCII code to integer), the Unix-based GCC (Gnu C Compiler) proved to be very compatible. Problematic code on the Unix platform was downloaded to, and repaired on, the Borland compiler, which has faster and more sophisticated debugging methods.

The most severe bugs resulted from the type discrepancies that exist between DOS and UNIX, an area in which the C compiler does not assist much.

6.1.1. Link List Handler

The link list handler provides a doubly linked list library for maintaining the virtual world data. It was found that Session's code [SESSIONS,1989] needed alteration.

The existent search procedure was unidirectional and slow. Bidirectional and optimised procedures were added. Furthermore, the original search function returned elements by value, necessitating a memory copy on every access. The code is now supplemented by searches that return a pointer to the structure required. The tradeoff in this optimisation is that the data is no longer protected from the client caller. In this case the client's responsibility can be checked, making the increased speed worth the risk.

This link list handler was compiled on the DOS Borland IDE, and ported to UNIX with minimal alteration.

6.1.2. Script File I/O Routines

The script i/o routines were written for the script file parsing operations. Table VI details the functions and their purpose (note that most parameters have been omitted). These functions are general and reliable enough to institute changes in the script file contents. The script operations were originally written for file i/o, but corresponding functions had to be written for text string i/o (hence input stream parameters have been omitted in the table). All functions return a zero if unsuccessful, or if the end of input was encountered.

Again, the functions were written on the Borland interface and ported to Unix. The UNIX implementation proved to be more fragile, and the differences in string representation created numerous holdups. Since the sscanf function was used to scan the buffer line by line, the C function strtok had to be used to peel lines off the buffer. This function keeps its own implicit pointers, and some careful adaption was required to keep them in synchronisation.

6.1.3. TCP Procedures Library

TCP procedures required for the VR386 side are : TCP open, remote execute, send, receive, and close transmission. The UNIX side has corresponding procedures. However, it has additional busywait functions to handle batch mode. Table VII displays these specialised procedures.

Figure 6.2 illustrates the combined interaction of the TCP and the scriptio libraries. Writing to a string buffer is something that can be done directly by the sprintf command. Incorporating the command into a function would forgo the flexibility of the stream language. Only a macro for adding a single numeric parameter was found useful. The routines for parsing a buffer are more powerful in nature. Figure 6.3 demonstrates the use of the parsing routines, as used to parse the TOV buffer. Note how the modules may be used in an application-independent manner.

6.1.4. Editor Extensions

The editor extensions were built as substitutes for the existent menu, which was not comfortable from the user's perspective. A menu structure system has been created with paramaterised procedures for a main menu on the top row of the screen, side menus dropped from a main menu selection, and submenus dropped from these side menus. It was felt that any deeper level of nesting only cluttered the space.

An improved user request box was written, this one giving the user an alterable default. Together with this, there is an unobtrusive commentary box that appears at the bottom of the screen, and is utilised to keep the user up to date.

High-level procedures for editing forces, materials and objects appear in the editor module.

6.1.5. The VSide, XSide, Xemulate and Vemulate Modules

The VSide module, the largest in the suite, is the working layer between the editor functions and the VR386 backbone. Above it, a module called Vemulate replaces the original top-level VR386 main program. It contains the main execution loop, the main menu format, and the initialising and closing down code. VSide contains the world design, saving and transmission code, constructed from the TCP, link list and script parsing modules. An attempt to keep the modules separate was made, but eventually module sharing between VSide and the editor module had to be allowed. VSide provides mechanisms for the higher-level editor suite, but it also uses the editor functions in some sub procedures. The alternative would be to make more of VSide global to the editor module, but this would compromise seriously on safety.

The XSide module corresponds to the VSide workhorse, containing most of the conversion and parsing code. Above it, the Xemulate module contains the master code. When invoked, it sets up defaults and goes into busywait mode, in anticipation of the VR transmission. When the transmission comes through, it spawns XAERO in batch mode, awaits the return script, and then translates the new script.

6.2. Efficiency Issues

This section deals with the problems encountered in implementation, and some of the solutions found. It also deals with optimisations that were attempted.

On the first timing, a delay of four seconds on transmission allayed any hopes of operating a real time link. The most time consuming factor lay in the invocation of XAERO with the required script file. There was no way of optimising this, short of editing the XAERO code. However, three effective optimisations were done:

All the conversion code was moved to the Xemulate module. This means that the Virtual Editor reads and transmits variables without any alteration. Position, scale, rotation and colour code conversions are done by Xemulate.

Previously, information was written to a file before it was transmitted, but these files were replaced by runtime buffers.

Some testing of the c i/o functions was done on the DOS platform, to ascertain which was fastest. A 150 byte file was copied 10 times to obtain the following results (see table VIII).

The fread and fwrite parameters in table VIII refer to the byte block size read. Although one combination revealed the fastest read/write time, the variance in timings due to block size was considered too unreliable. The fgetc and fputc appeared to be more consistent, and were used where possible. Plauger's reference The Standard C Library was consulted for information on i/o optimisation [PLAUGER,1992].

Retesting the code produced a time of just under 2 seconds for a 4-object, 4-force world. Of this, about 166 milliseconds elapse while VR386 is awaiting the reply from XAERO. This was the best time. However the wait varied from 77 milliseconds to 360 milliseconds, probably due to network conditions.

Many other standard measures were taken to optimise for speed and efficiency:


Although many modules were required for the end product, the level of function nesting was kept to an absolute minimum. Extensive use was made of macros. These macros cannot be debugged in the normal way, and were the source of many hidden bugs.


As much processing as possible was done at startup. On the VR side, the defaults file, the list structures for world entities, and the default parameters were set up on startup. Then the TCP link was evoked, and tested. Timings taken for startup averaged just under a second.

The script files

In reading and writing the script files, many references to the object, material and force lists are made, so a keying system was utilised. Each list structure has a current pointer, pointing to the last created element. Since the double link allows bidirectional traversal, lists can be accessed very quickly. However, the materials list required a string key since the material codes are not unique. Optimising this, and other aspects, is deferred to Chapter 8.

Much of the content of an XAERO script is not used, and therefore does not need alteration. This information is captured in a default buffer at startup. Each time a new script file is required, this default buffer is written piecemeal to the new file. The speed advantage gained is the speedup of a per-character copy versus a specialised string-based function such as C's printf statement.

When XAERO simulates over a number of frames, it returns the complete world for every frame. However, anything other than object pose change is unneeded; this data is quickly eliminated with the parseto() function. If the pose or part thereof is unchanged between frames, pose information also becomes redundant. An updated object position or rotation is supplied only when there is a change from the previous frame. The parser indicates which of these it is by attaching an appropriate flag to the new values.

6.3. Control Devices

Although VR386 offers support for a wide range of user input devices (such as joysticks, trackballs, head mounted displays, gloves and 6-dimensional mice), it does not provide clean functions to use these devices. Associated with any device is a pointer structure, containing the device's pose, and button status. In the case of a glove, the structure holds any gestures that are recognised. The devices are monitored through TSR's, and polled at rates reasonable enough for fine sensitivity. In certain modes, a 2-D mouse can be used as a 3-D device. Depressing the right button alternates it between the X-Y and X-Z planes.

Working with the device functions was time consuming and frustrating. The mouse tends to swap between 2-D and 3-D modes, making button-prompted functions difficult. Customising the mouse functions was an awkward undertaking.

As mentioned in Chapters 1 and 3, the glove handling capability of VR386 was poor, although this is more a reflection on the coarseness of the glove than the glove driver. Glove routines were implemented jointly with some of the mouse routines, but when it was found that the gesture recognition was too inaccurate and slow, the glove code was abandoned. Attempts to read the glove buttons were also explored, but these procedures met with little success.

One of the advantages of the device structure abstraction is that it does allow for many devices. Adding different peripherals to the current package will necessitate only slight reworking of the code.

6.4. Editor Menus

Figure 6.4 depicts the menu system to three levels. Dotted lines denote shared menus. As can be inferred from Figure 6.4, the menu options were placed in a left-to-right progression, in the order of their usage. The figure shows only the first three level menus, although some options lead to many more levels.

It was felt that the myriad key functions implemented on VR386 detracted from the virtual experience, and were removed. The menu is invoked with an M, and the menu options can be key driven. Use of the keyboard has been minimised. A few of the menu options are worth discussion:

World Menu

Options for saving and loading worlds are present, and there is also facility to save the configuration parameters.

Since the transmission code had originally been written for file-based i/o, it was an easy matter to alter the transmission code for saving the world plus defaults to a file. The format of appendix 1.4 was kept. The user can thus create a world file by following the EBNF specification 4. The load world function required a little more work, but this time the save world code could be derived from the former.

Sky and floor refer to the sky and floor colours respectively. The Base option refers to a floor plane. This information is sent to XAERO, but it is one of the features yet to be implemented.

Camera Menu

The camera zoom is preset to 2. The zoom scale of XAERO and VR386 is very different. VR386 has a perspective projection, and high zoom value distorts the scene. Hither and yon refer to the clipping range of the camera.

Object Menu

The facilities for creating and editing objects utilise the same substructure. When the user has to choose a material, a table of materials is drawn, and he chooses the appropriate one with a mouse. The dimensions can be scaled numerically, or proportionately by the mouse.

Although the user can move the object at any time when the menu is off, he can specify the object's pose numerically as an editor option. The link and untie functions are used to create compound objects from primitives. Linked objects move in unison, although they can still be individually altered.

Force Menu

The force menu mimics the object menu. The system prompts a user to highlight an object, and then requests the force type. If the user chooses a guided force, the system checks for the existence of a second object(14). Again, the mouse is used to place the force. The mouse action is hardly intuitive at this stage, but reworking the code to place forces with a glove is not a large undertaking.

After placing both ends of the force, the user must enter a size. Strictly speaking, the size is translated as the length of the vector, so the size should be specified after the first point, and a line of the appropriate length dragged into position. However, it was decided that giving full control over both ends was more effective. When the force is transferred to XAERO, the coordinates are normalised, and the size is used there to determine the vector length.

As with objects, editing a force allows the user to alter his mouse-chosen coordinates numerically. There is a fundamental difference in the way that forces and objects are stored. In VR386, the only entity that behaves as if drawn in three dimensions is an object. Were forces were represented as single-polygons, there would be difficulties in differentiating them from object primitives. On the other hand, creating and drawing an object to represent a force is a fast process. It was decided that forces would not appear until editing was desired. In this case, the user chooses an object, and is presented with the associated forces one a at a time. The advantage of this method is that forces do not clutter the screen.

Animation Menu

This menu performs the remote transfer. The Frame and Rate parameters are used to adjust the XAERO input. Frames refers to the number of frames required, and the rate refers to the generation rate. Increasing the rate increases the granularity (and therefore the time duration) of the simulation. XAERO allows forces to be specified over any time duration in the sequence, but in this editor the forces last the length of the simulation.

Sendoff performs a sendoff of the current state, and awaits a reception. At this point, the Editor could be adapted for the user to continue design as he waits. However, altering the world would complicate the movement list which is produced at this stage, because it bases movements on that initial stage.

There are two further options; Perform Movements and Examine. Perform movements runs through the movement list, moving the objects. In reality, it should iterate through the list at the frame rate specified, but this would involve work with the multitasker, and was considered beyond the scope of this thesis. The Examine movements option saves a copy of the current world, demonstrates the movement list, and restores the world. Both options do allow the user the choice of stepping through the sequence, or running straight through it.

6.5. A Possible Application

This section describes a typical application for which the Editor might be used. We take the example of inverting a bowl of marbles.

The first step is to design materials, in this case for the marbles and the bowl. If the available materials are not close enough, they are created on the XAERO windows editor, and ported down to VR386.

After this, the designer creates the objects that he requires on the Virtual Editor. The bowl could be built from many small cylinders, grouped together. The marbles are placed in the bowl. In Figure 6.6, frame A depicts the choosing of a material, and frame B shows the object edit option; note the simplicity of the menu.

Step three is to add the forces required. For instance, vectors to tip the bowl could be added. It must be remembered that vertexes produce linear forces; nonetheless, adding opposite vectors to opposite ends of an object will cause that object to rotate. Frame C shows the final stage in adding the force. After specifying the start and end points, a magnitude is attached.

The model is now ready for simulation. The designer sends it through, and awaits a returned sequence. At a standard animation speed of 25 frames per second, he would want in the order of hundreds of frames for a smooth animation. He plays the sequence through with the perform option. Frame D shows the world about to be transmitted, and frame E, figure 6.7, shows the resting position of the cylinder after movement has ensued.

Once the demonstration has been completed, the user can alter the vectors, move objects around, and try the sequence again. At any point, he can save a promising world, and retrieve it at a later stage.
Figure 6.7 shows the traffic that was sent through the buffers in this simulation.

7. Conclusion

This thesis was has explored the evolutionary world of Virtual Reality. It has showed how two complimentary VR tools were evolved into a more sophisticated tool. It began with an investigation of their purpose, and their merits as VR tools. Then, through basing decisions on psychological research, current classification of mathematical models, and examples of distributed VR, a model of interaction was formulated.

Formal methods were used as far as possible for the preliminary design, but the rest was built by referencing the existing source code, and using language specific optimisations. Benchmarks and empirical testing were used to retain efficiency.

The software was written on one platform, and ported to the other. The code was modularised into various levels of abstraction. Although these modules were mostly completed and tested in isolation, there was unfortunately not enough time to test the integrated system thoroughly.

More accessible than the XAERO editor, the Virtual Editor allows usage of the XAERO mechanics engine without the requirement of a background in physics. From the user's point of view, world design is an expedient process. From the designer's point of view, specialised applications can be built easily.

Creating from existent code is always a problematic undertaking, and design cannot take place in isolation from implementation. Bugs and ideosyncracies which arose from this code slowed development, and necessitated a convoluted design. Methods of keeping the code modularised were sought at every stage. One of the goals of exploratory research is to provide a platform from which future work can take place, and from the standpoint of easy extensibility, this goal was achieved.

Through coalescing a wide range of research, this project brings many emerging aspects of Virtual Reality to light, and could introduce and motivate diverse and novel future research.

8. Future Directions and Research Opportunities

In the exploration a new and relatively unstructured field, innovative and interesting concepts were found at every stage. The scope of this project addressed was formidable, and there was not enough time to explore all of these aspects to a great extent. This chapter outlines potential development areas, again in terms of the three aspects explored.

The Mathematical Model

A significant component of XAERO remains untapped. Additions to the virtual model include the springs, dampeners and rods that could be added. New functions might be introduced from the Virtual Editor side: for instance, a global force that affects all objects could be specified. In this way, the model hierarchy will be ascended. Since the objects and forces are already stored in link lists, this will be trivial to implement.

Mathematically based applications of the Virtual Editor include the teaching of physics, architecture and product design.

Development from a psychological perspective

The present interface is still somewhat limited, and amenable to endless improvements. Improving the interface by harnessing a more accurate glove would make design easier. The placing of scales, selective lighting, and textures could provide better 3-D cues. The 320 x 200 pixel mode is fast, but perhaps a higher resolution screen with a slower rendering rate should be given as a user option.

On a technical level, speed optimisations are still needed. In particular, linked list access could be speeded up through caching and buffering (Sessions outlines methods of doing this in his text [SESSIONS,1989]). The movement performance function is rudimentary at this stage. With caching and buffering, this option could be upgraded into a more sophisticated animation studio.

The objects are coloured by their XAERO-equivalent material, but a better option might be to use the colour for a status code. The designing of objects can still be improved. For example, facilities for copying objects and object groups could be added.

As discussed in Chapter 4, Virtual Reality has great potential in therapy and skill teaching. Virtual Reality can be used for training users to perceive and create in three dimensions. This is a novel area of research to which the Virtual Editor could be applied.

Development in distributed processing

Chapters 4 and 5 presented the research done on graphical standards and languages. A possible extension to this project would be to convert the information flowing over the TCP link into such a language; similarities to PHIGS have already been outlined.

Although distribution was explored, the notion of parallelism was not. A successful method of parallelising the components could be implemented. Communication is done via the duplexed TCP protocol, but with the use of broadcasting, the Editor needn't use only two stations. Part of the current research at Rhodes concerns distribution methods, and this system could be scaled to a large set of stations (see [BANGAY,1993]).

The present system has hardly undergone capacitance testing. Research into high-volume data transfer could yield important findings about distributing functions in Virtual Reality. This would be of commercial interest, because this distribution advocates the use of existent multipurpose machines, rather than specialised high-end workstations.

A very important principal upheld was that the software components are modular. The Editor functions could be used to enhance VR386 applications that are unrelated to this one. The link list, script handling, and tcp modules are useful kits in their own right, and could be integrated into many applications.


[ANDREWS,1969] Andrews, A Quotations for Speakers and Writers, Newess Books, Sydney, 1969

[BANGAY,1994] Bangay, S. Parallel implementation of a Virtual Reality System on a Transputer Architecture, Master's Thesis, Rhodes University 1993. Also K. Watkin's Honour's project, A Virtual Modelling Environment, 1994.

[BARZEL,1992] Barzel, R Physical Modelling for Computer Graphics - A structured Approach, 1992.

[BERRY,1986] Berry, J W et al Cross-Cultural Psychology: Research and Applications, Cambridge University Press, Second edition, 1986.

[CAVENDISH,1985] Marshall Cavendish The Great Artists, Part 13, Volume 1, 19th Century, Marshall Cavendish Ltd, London, 1985

[CORC,1993] Corcoran, C Smart 3D gives on-screen objects physical attributes, Infoworld, July 5, 1993 v15 n27 p16(1), Infoworld Publishing Company, 1993

[COREN,1979] Coren et al Sensation and Perception, Academic Press, 1979.

[ELIOT,1993] Eliot, Lance B. Reality into Virtual Reality, AI expert, December 1993, v8 n21 p9(3)

[ELLIS,1993] Ellis, S Bring Virtual Worlds to Life, EXE Nov 1993, v8 n6 p76(4), Process Communications Ltd. (UK) 1993.

[ENGELKE,1993] Engelke, E Waterloo TCP Programmers Guide, Release 1.20 (Poscript manual supplied with the TCP package), 1993.

[FOLEY,1990] Foley et Al Computer Graphics: Principles and Practice, Addison-Wesley, Reading, Massachusetts (1990).

[FREEDMAN,1993] Freedman, A Electronic Computer Glossary, The Computer Language Co. Inc. 1993.

[GARDNER,1980] Gardner,L Art Through the Ages, 7th Edition, Harcourt Brace Joovanovich, inc. 1980

[GUO,1993] Guo et al Controlling Movement using Parametric Frame Space Interpolation, p 216-226, Models and Techniques in Computer Animation, edited by N. Magnenat and Thalmann and D. Telman, Springer-Verlang, Tokyo, 1993.

[HAWRY,1991] Hawryszkiewycz, I Introduction to Systems Analysis and Design, Second edition, 1991, University of Technology, Sydney, Ch 6-8, 12.

[HESTENES,1990] Hestenes, D New Foundations for Classical Mechanics, Kluwer Academic Publishers, the Netherlands, 1990

[HOPGOOD,1991] Hopgood, R A Primer for PHIGS, 1991

[JERN,1988] Jern, M The Choice of a Graphics System; Standard, Emerging Standard or De-facto-Standard, New Trends in Computer Graphics, edited by N. Magnenat and Thalmann and D. Telman, Springer-Verlang, Tokyo, 1988 (pp 488-496).

[KALAWSKY,1993] Kalawsky, R S The Science of Virtual Reality and Virtual Environments, Addison Wesley Press, 1993

[KAUFMAN,1993] Kaufman, AE et al Navigation and Animation in a Volume Visualisation System, pp 64-74. Models and Techniques in Computer Animation, edited by N. Magnenat and Thalmann and D. Telman, Springer-Verlang, Tokyo, 1993.

[LEE,1993] Lee et al Constraint Based Hand Animation, Models and Techniques in Computer Animation, edited by N. Magnenat and Thalmann and D. Telman, Springer-Verlang, Tokyo, 1993.

[MAC,1992] Macnichol, G Desktop Computer Animation, Focal Press, Boston & London, 1992

[NEWTON,1993] Newton, H Newton's Telecom Dictionary, 1993.

[OLCKERS,1994] Olckers, P et al VIRTUAL REALITY; Part 1:Introduction to virtual reality, Compuer graphics, February 1994, Vol 5 no 1, pp 38 - 41.

[PATCH,1993] Patch, K Virtual Reality becoming more real, PC Week Oct 4, 1993 v10 n39 p147(1), Ziff-Davis publishing company 1993

[PLAUGER,1992] Plauger, P.J. The standard C library, Prentice Hall, Englewood Cliffs, New Jersey, 1992. pp 225-332

[RAMSAY, 1994] Ramsay, M Real Tools for Virtual Worlds,Computer Graphics World, Jan 18, 1994, v17 n1 p60(2)

[SESSIONS,1989] Sessions, R Reusable Data Structures for C, Prentice Hall, Englewood Cliffs, New Jersey, 1989 pp 1-87

[SIMONE,1994] Simone, L Enter the 3rd Dimension with trueSpace and Visual Reality, pp 17-19, PC Magazine SA, July 1994, volume 2 number 6.

[STAMPE,1993] Stampe, D et al Virtual Reality Creations, Waite group press, California, 1993.

[UNO,1988] Uno,S et al AVENUE: An Integrated 3-D Animation System, proceeding of CG International, 1988

[WILLIAMS,1993] Williams, L Living Pictures, Models and Techniques in Computer Animation, edited by N. Magnenat and Thalmann and D. Telman, Springer-Verlang, Tokyo, 1993.

[WINTROB,1993] Wintrob, S Visual Computing: beyond the lab, Computing Canada, Plesman Publications Limited (Canada), Dec 20, 1993, v19 n26, p1

[AI,93] (no author supplied) Getting a Virtual Education, AI expert August 1993, Miller Freedman Publications, v8 n8 p48

Appendix 1

An EBNF format of the script files

1. XAERO Material list file = number_of_materials

("xmat.dat") {Xmaterial info}


material_information = key matname mattype d dfc fc iv sv dv ismore dr dg db t re ro


matname = char[STAMPE,1993]

d,fc,fc,iv,sv,dv,tr,re,ro = REAL

ismore = INTEGER

dg,dr,db = WORD

mattype = WORD

2. VR386 Material list file = number_of_materials

("Vmat.dat") {VR_material_info}


VR_material_info = matname mattype

number_of_materials INTEGER

3. VR386 Defualts file = number_of_materials

{VR material info}

gravity frame_rate number_of_frames ground_colour floor_colour hither yon zoom x y z rx ry rz floorplane

gravity, frame_rate = REAL

number_of_frames, ground_colour, floor_colour, hither,

yon, zoom, x, y, z, rx, ry, rz = INTEGER

floorplane = BOOLEAN


("XDef.Dat") K

p 1.400000 1.400000 5.000000

r 0.982963 0.129410 -0.129410 -0.017037

z 1.000000






h 1.00000000e-03 1.00000000e-03


e Y 1.00000000e-04

k Y 1.00000000e-03

b 1.00000000e-02 1.00000000e-05

u 1.00000000e-04 1.00000000e-08

g N 1.00000000e-01

r 1.00000000e+04 1.00000000e+02

j 1.00000000e+04 1.00000000e+02

m 1.00000000e-05

q 1.00000000e-02

s N

a N 8.00000000e-01 3.00000000e+00



i" frames


g 0.0000000e+00 -9.81000000e+00


frames = REAL

Material_list = m matname d dfc fc iv sv dv [dr dg db t re ro]

5. FROMV BUFFER = number_of_frames

frame rate







Number_of_frames = INTEGER

frame_rate = REAL

object information = (("o" objstatus) | "e") obnumber obtype dimensions matkey position rotations

obnumber, matkey,num_ob_objects = INTEGER

dimensions,positions, rotations = WORD WORD WORD

objstatus = ['F'|'G'|'S']

objtype = ['B' | 'S' | 'C']

force_information = "o" key type objnumber fromvec vectype tovec gforce [destobj]

vectype = ['I'|'G'|'L']

tovec, fromvec = REAL REAL REAL

gforce = REAL

floorplane = BOOLEAN


("offtox") "i" frame_rate

"z" zoom



"g 0.00000000e+00 -9.81000000e+00


"M 32"




object_information = "K" number obj_details

{"E" obj_details}

obj_details = type dimensions material

"p" position

"q" quaternion

"i" inumber

type = "sphere"|"box"|"cylinder"|"composed"

inumber = INTEGER

position = REAL REAL REAL


force_information = "F" starttime endtime "K"objnumber [pointvector] forceparameter force

starttime,endtime = REAL

pointvector = DWORD DWORD DWORD

forceparameter = ("inertial" pointvector) | ("local") pointvector | ("guided" force "K" objnum pointvector)

force = REAL








object_update = ("o" objdetails | "g" objdetails {objdetails} "e")

objdetails = number (positions | rotations | (positions rotations))

positions = "p" WORD WORD WORD

rotations = "r" WORD WORD WORD

Appendix 2

A Glossary of Terms

Some of the technical terms associated with virtual reality tend to change meaning as technology changes. Definitions of some of the terms used in this thesis is provided:

CAD The development of three dimensional environments has long been possible through 3-D CAD (Computer Aided Design) tools. According to Freedman [1993]:

CAD software is available for generic design or specialized uses, such as architectural, electrical and mechanical design. CAD software may also be highly specialized for creating products such as printed circuits and integrated circuits.CAD systems are often turnkey(15) systems, which are put together by vendors that may develop or integrate software into standard or optimized hardware. Except in a few cases, CAD systems rely extensively on graphics.

XAERO This is the name of the Unix based rigid body modeller. The X denotes that the product runs in BSD Xwindows.

VR386 This is the name of the DOS-based Virtual Reality system, produced by D. Stampe of Toronto.

TCP This stands for Transmission Control Protocol. It is a set of protocols developed by the United States Department of Defense to link dissimilar computers across many kinds of networks, including unreliable ones and connected to dissimilar LANs. TCP is supported by many manufacturers of minicomputers, personal computers, and other devices. It is also the protocol commonly used over Ethernet. It is a four layer protocol, the top layer of which, the Network Interfacing layer, was used.

TCP packet code is often distributed as part of the UNIX source code, such as that found with Solaris. It is also available as a shareware product, and the DOS based TCP was downloaded from a site at the University of Waterloo, USA [NEWTON,1993].

solid modelling This is one of the various accepted methods of graphically representing objects. It is a mathematical technique, and the least abstract form of CAD. Unlike wireframe and surface modelling, solid modelling systems ensure that all surfaces meet properly and that the object is geometrically correct. A solid model can also be sectioned (cut open) to reveal its internal features. Solids allow interference checking, which tests to see if two or more objects occupy the same space.

surface modelling Used in CAD, this is a mathematical technique for representing solid-appearing objects. Surface modelling is a more complex method for representing objects than wireframe modelling, but not as sophisticated as solid modelling.

Although surface and solid models can appear the same on screen, they are quite different. Surface models cannot be sliced open as can solid models. In addition, in surface modelling, the object can be geometrically incorrect; whereas, in solid modelling, it must be correct.

ray tracing In computer graphics, the creation of reflections, refractions and shadows on a graphics image. It follows a series of rays from a specific light source and computes each pixel in the image to determine the effect of the light. It is a very processor-intensive operation.

Immersion Tools such as the data glove and the head mounted display function to allow the user to immerse himself into a scenario. The more senses these tools occupy, the more realistic the experience. However, a key factor in Virtual Reality is that the user is not deceived into mistaking simulation for reality; rather, he indulges in the "willing suspension of belief", much as if he were reading a novel ([STAMPE,1993]).

Animation Animation, developed long before the emergence of computer science, founded many of the important graphical motion techniques used in Virtual Reality. Early animation was expensive to create because of the time expended in drawing each frame. Attempts to optimise this led to inventions such as the rotoscope, a mechanical device used to emulate motion by means of a skeleton, and keyframing, where the start and end scenes between two frames were drawn, and short cuts were found to interpolate the scene change between.

Key framing This is an animation technique whereby the animator specifies the start and end frames of a particular sequence, and then uses a computer to calculate the intervening frames. Key framing can be done at various levels of complexity. With lerping, or linear interpolation, the animator indicates this motion by means of a set of straight lines. A constant-velocity motion results. Another method, called splining, utilises curves for the interpolation. Slerping, or spherical linear interpolation, is even better. It utilises a 4-D sphere, through which quaternions move.

Real time Real time applications allow the user to interact without having to wait for processing. In a teller machine situation, real time response must be of shorter duration than three seconds, but in a graphical environment, the response time must be of the order of the refresh rate.

Pose When objects are first created, they are typically rendered as having their center in the center of the coordinate system(16), and having no rotations in any plane. To measure the area that they cover, the point furthest from the object's center is used as a radius for a bounding sphere.

Now, when the object is moved or rotated, it is assumed that this motion is performed on the center of the object. Object collisions and obstructions are tested by ascertaining if any bodies lie within the bounding sphere.

The 3-D coordinate position, together with the 3-dimensional rotational values (17)), are described as the object's pose. If we make the assumption that we are dealing with rigid, unchangeable objects, the entire animation process of the world is reduced to a set of changing object poses.

Quaternions Rotating in three dimensions causes visual discrepancies. Quaternions offer a more efficient method of modelling rotation. Conceptually, a quaternion is a four-dimensional vector, which exists in a four-dimensional sphere. Any rotation can be described by exactly two quaternions, so conventionally the one that involves the least amount of traversal across the sphere is chosen.

1. The term shall henceforth be shortened to VR

2. three-dimensional will henceforth be abbreviated to 3-D.

3. Frames moving at less than this speed cause jerky motion, termed temporal antialiasing. Although 24 frames per second is smooth enough for most animation, temporal antialiasing can still occur if an animated object changes position too quickly [FOLEY,1990].

4. VR 386 uses a mode that plots four pixels per cycle

5. We use the convention that x' denotes the first derivative, and x" denotes the second. In this context x' is velocity and x" is acceleration

6. Kinaesthesia includes the awareness of movement, and the awareness of our own limbs. We need this skill to gauge weight supported by our limbs, and to contract our muscles appropriately [KALAWSKY,1993].

7. Some psychologists have disagreed with the fairness of the test, which implicitly assumes that subjects understand it. It has been pointed out that the geometric accuracy of the diagram is not totally correct either, which weakens Hudson's hypothesis

8. . PHIGS was first introduced in 1976 on APS system; it was developed from the Graphical Kernel System (GKS), in 1985.

9. By "script file" we mean a textual specification of the scenario required. The file is written in a specification language, on a conventional editor, and usually saved as an ASCII file.


10 K. Watkins must be accredited for providing the object creation code, which he produced for his own project.

11. Data Flow Diagrams are generally used to model data flow and data conservation. They do not utilise chronological order, or conditional branches. Unidirectional arrows, representing flows, point to processes, marked by circles. Rectangles denote external entities, where i/o takes place, and horizontal lines denote local data stores, which are buffers or files in this context.

12. The material ice was contracted from 110 bytes on XAERO to 9 on VR386

13. Petri nets are used for calculating liveness and safeness. Places (circles) may contain tokens (the dark point). Arrows determine how places may fire.

14. XAERO actually permits a guided force to be added to a single object. However an object that drives itself contradicts the guided force definition

15. A turnkey system is a total package, which is both sold and installed by a vendor. The term "turnkey" conveys the idea that the buyer is presented with the key to the package he has just bought, without having to do any installation [FREEDMAN,1993].

16. Coordinate system descriptions are problematic. In this report, coordinate systems are assumed to be Cartesian, although VR systems have found merit on other axis types.

17. If the quaternion system is used, there are four dimensions, and each position has two representations. This system, used in XAERO, is efficient in terms of calculation complexity. Chapter 5 expands on this problem.