Conference PaperPDF Available

Using a Floating Origin to Improve Fidelity and Performance of Large, Distributed Virtual Worlds

Authors:
  • floatingorigin.com

Abstract and Figures

Large Virtual Worlds (VWs) are increasingly common in the computer graphics areas of simulation, games, geospatial or scientific visualisation. In such VWs, simulated motion of the viewpoint and other objects becomes jittery and lacking in realism when far from the world's origin. Shape and appearance of objects can also degenerate. Since these effects depend on position in space, they will be collectively termed Spatial Jitter (SJ). Traditional solutions to SJ embody the idea that viewpoint motion through the VW must involve a change of the viewpoint's coordinates. This notion of viewpoint motion increases design complexity and the processing overhead of code written to counter SJ. A Floating Origin (FO) approach is presented which floats the world's origin with the viewpoint when navigating a continuous VW, eliminating SJ effects and lowering design and processing overheads. It ensures constant high fidelity in contrast to the continuously varying fidelity of conventional solutions.
Content may be subject to copyright.
Using a Floating Origin to Improve Fidelity and Performance of
Large, Distributed Virtual Worlds
Chris Thorne
School of Computer Science and Software Engineering
The University of Western Australia
chris@ping.com.au
Abstract
Large Virtual Worlds (VWs) are increasingly
common in the computer graphics areas of simulation,
games, geospatial or scientific visualisation. In such
VWs, simulated motion of the viewpoint and other
objects becomes jittery and lacking in realism when
far from the world's origin. Shape and appearance of
objects can also degenerate. Since these effects
depend on position in space, they will be collectively
termed Spatial Jitter (SJ).
Traditional solutions to SJ embody the idea that
viewpoint motion through the VW must involve a
change of the viewpoint's coordinates. This notion of
viewpoint motion increases design complexity and the
processing overhead of code written to counter SJ.
A Floating Origin (FO) approach is presented
which floats the world's origin with the viewpoint
when navigating a continuous VW, eliminating SJ
effects and lowering design and processing overheads.
It ensures constant high fidelity in contrast to the
continuously varying fidelity of conventional solutions.
1. Introduction
Imagine yourself at the top of a ramp leading down
and away into the distance. It seems mirror smooth
but as you walk down, small irregularities appear like
tiny staircase steps. Further down your progress gets
quite bumpy. Eventually your feet can fit comfortably
on each step. Later, you have to take small jumps. You
conclude that before long the next step will result in a
fall and perhaps broken bones!
The diabolical staircase with ever larger steps
represents the floating point number line, with its origin
at the top and ever increasing gaps between one
representable number and the next. On a digital
computer, there is a discrete set of representable
floating point numbers which are not distributed
evenly [5]: the gap between one number and the next
increases with its size, or distance from the origin. The
gap between 1 and the next number is called the
machine epsilon, Em [7]. The gap between x and the
next number is ~ x . Em. In general,
gap = P2(x) . Em , where P2(x) is the largest power
of 2 that is less than |x|.
In a VW, the position of objects is defined by
coordinates, a notation that denotes distance from
origin [6]. Modern computer graphics hardware uses
floating point numbers for the coordinates of objects
[4,16]. Therefore, like the staircase, the further
coordinates are from the origin the larger the gaps
between them.
It follows from the above that moving something
from one position to another will show increasingly
larger jumps with increasing distance from origin,
leading to SJ. Figure 1 illustrates the jittery motion of
two dots moving far from the origin. SJ effects have
been noted before [1, 9, 13, 18, 26, 27, 28, 29].
The total number of representable values a floating
point number can have depends on the precision [5] of
the floating point representation used. In general, the
precision of a real number is the number of decimal
Figure 1. Snapshots of two moving dots overlaid
into one image. The dots are near (1000000,
1000000, 1000000) and move from the distant
upper right to the near lower left. Each upper dot
snapshot is connected by a line, tracing its jittery
path. A straight line underneath highlights the
uneven motion of the dots.
digits in it which are treated as significant for
computations [30]. Current graphics hardware has a
maximum of 23 bits precision, the precision of the
Single Precision Floating Point (SPFP) standard [8],
for the coordinates of objects. Often, the precision used
can be less [4] and a lower precision means larger gaps
between coordinates.
Poor understanding of SJ and its cause, and
difficulty grasping the idea of moving the origin instead
of the viewpoint, have been barriers to implementing a
FO solution. Another barrier has been that existing
designs can be difficult to convert to a FO approach.
Consequently, this paper aims to remove the enigma
surrounding the SJ problem by explaining it clearly and
further aims to show how an optimal and complete
solution can be attained.
In order to better explain different approaches to
preventing SJ, the VW application is divided into a
display system (DS) and object system (OS). The OS is
responsible for defining, tracking and handling the
interaction of objects. These objects are given to the
DS which generates a user's view into the VW
(rendering). The DS uses a representation of the
objects in a form more suitable to fast rendering and
has operators that affect object appearance. Among the
operators are transforms which shift objects so they are
positioned correctly in relation to each other.
The following describes how SJ has been addressed
and how some people had difficulties understanding the
problem. The FO approach is then described with
emphasis on how designers need to change the way
they think about SJ and the solution. The general
design for a distributed FO system is presented and
compared with conventional solutions. The discussion
also describes how the FO method should be combined
with level of detail streaming and dynamic placement
to complete the approach. The benefits of FO are
summarised in the concluding remarks.
2. Traditional approaches
Traditional approaches to SJ fall into three classes:
on-the-fly shifting of coordinates, subdivision of the
world into local coordinate systems and piecewise
shifting of world coordinates (WC).
2.1. On-the-fly shifting of coordinates
The on-the-fly approach to jitter shifts objects and
the viewpoint close to the origin before calculations are
performed that will noticeably affect how they are
rendered. The shifting involves changing the object
coordinates or transforms that affect their coordinates.
In an article on simulating a solar system, Oneil [13]
describes dealing with jitter by shifting visible objects
just before they are rendered to each frame. A frame is
an image in a series sent to the user's display at a rate of
at least 30 frames per second to give the appearance of
smooth animation. Oneil's algorithm temporarily sets
the viewpoint position at the world origin and subtracts
the true viewpoint position from that of all visible
objects. Thus everything used in rendering a frame now
has small, accurate coordinates and the calculations are
consequently higher fidelity, avoiding jitter effects.
Once the frame is rendered, viewpoints and object
positions are restored to their previous values.
Other on-the-fly examples can be found in online
articles and forums on game development sites [26, 27,
28, 29]. For example, in the blitzcoder forum [28],
“Andy” proposed a periodic on-the-fly method: every
time the viewpoint became, for example, 10,000 from
the origin, it was shifted back to the origin and all
objects were shifted by the same transform to keep
them in correct relative position.
2.2. Multiple local coordinate systems
Many VWs were divided into smaller coordinate
regions enabling easier management of detail and
minimizing jitter at the same time. This segmentation
requires additional structures and management
overhead to handle movement between regions.
The Dungeon Siege game segmented its world into
SiegeNodes, each with its own local coordinate space.
When the viewpoint crossed a boundary between
nodes, the local coordinate system changed to that of
the node being entered and a “Space Walk” began [1].
The space walk visited each active node and
recalculated coordinate transforms to shift objects
closer to the new local origin. This ensured coordinates
did not get large enough to cause jitter.
The connection between nodes in Dungeon Siege
was similar to what has been called portals in other
segmented VWs. Eternal Lands (EL), a Massively
Multiplayer Online Game (MMPOG), used portals
which teleported the player from one segment to
another. EL had one world map divided into continent
maps. It also used ships as a natural transporter system.
Other games also made use of natural transporter
systems to move between segments [12, 15, 31].
In the Morrowind game [12], a player walking far
enough along a path would experience a halt where
movement was temporarily blocked, while a message
like “loading external environment” was displayed.
This hiatus marked the transition from one segment of
the game world and the next.
Flight simulators need to counter jitter because they
cover very large areas. FlightGear, for example,
divided the earth into tiles, each with a local coordinate
system. It made aircraft and other object coordinates
relative to the reference point of the tile they were in.
“This reference point (for purposes of avoiding floating
point precision problems) defines the origin of a local
coordinate system” [14].
Another simulation system using local coordinate
spaces was Spline, used by Barrus et al. [3] to build the
Diamond Park virtual world. Spline supported the
subdivision of the larger world into smaller locales and
the efficient communications between them. When an
object moved from one locale to the next its
coordinates were transformed to be relative to the new
locale origin.
VGIS, a GIS application for modeling the earth,
subdivided the world into regions. VGIS was described
in a paper by Lindstrom et al. [10] who thought the
subdivision was necessary: “This is necessary as the
precision afforded by current graphics hardware is
insufficient for representing detailed geometry
distributed over a large volume in a single coordinate
system”.
2.3. Piecewise shifting of coordinates in a
continuous virtual world
Dungeon Siege appears like a continuous world
because there is no noticeable hiatus while moving
between segments, but it is not a true continuous world
because it subdivided the world into SeigeNodes. A
true continuous world has a single world coordinate
system with no artificial segmentation of that space.
Examples of applications built on a continuous world
space are Terravision [9], planet-earth [24] and
applications using the GeoVRML [18] technology.
These applications perform a shift when a special type
of viewpoint is selected.
GeoVRML is a geospatial extension to the VRML
[25] language. In GeoVRML, whenever one moves to a
new area of interest, a GeoViewpoint is used. A
GeoViewpoint contains the origin of the area of interest
and the position of a nearby viewpoint, both in WC.
The GeoViewpoint reverse transforms the world by
subtracting the origin from the WC of the nearby
viewpoint and other objects resulting in small
coordinate values, thus avoiding jitter. In this way, the
world is shifted in a piecewise fashion as the user goes
from viewpoint to viewpoint.
Apart from viewpoint selection, another way to
move though a virtual world is by free navigation. Free
navigation is when the user operates controls for
walking, flying or other continuous movement. In
GeoVRML, there is nothing to stop one from freely
navigating to a point where SJ occurs. Terravision is
based on GeoVRML and thus has the same properties,
except the free navigation issue is managed by
periodically re-translating the world so the viewpoint is
at the origin, and everything else is closer to it.
The planet-earth project [24] uses a continuous
shifting of the world. This is a combination of
piecewise shifting via viewpoints like GeoVRML and
TerraVision plus continuous reverse translation of the
world during free navigation. The latter is what
distinguishes the FO method from other continuous
world methods like GeoVRML and TerraVision and is
described in the next section. It also distinguishes FO
from the traditional SJ solutions which have the
viewpoint always moving relative to the origin.
3. Floating origin approach
3.1. Reversal of navigation thinking
In the review of traditional systems that manage
jitter, there is a common thought process apparent in
their design. The apparent assumption is that while
freely navigating or moving from one viewpoint to
another, the coordinate of the viewpoint must move
through the virtual world: i.e. its value must change.
Coordinate shifting is only added on just prior to
rendering frames or to periodically reduce the
viewpoint and object coordinate values. Even with
GeoVRML and TerraVision, free navigation moves the
viewpoint through the world space.
The FO approach is a departure from such
conventional navigation thinking. As shown in Figure
2, instead of allowing the viewpoint to move in the
world, the world is reverse transformed to position the
desired point at the origin. The origin is not fixed
relative to the rest of the world but floats with the
viewpoint. Therefore, the viewpoint is always centered
at the highest fidelity place: the origin, even when
freely navigating. The effect of using a FO is that there
will be no observable SJ. Since the origin is the world's
center, this type of viewpoint is termed here a centered
viewpoint.
3.2. Understanding the problem, grasping the
solution and implementing it
Comprehensive searches revealed the closest
approaches to FO that have been formally documented
are the GeoVRML and Terravision approaches already
Figure 2. Comparing conventional and floating
origin navigation.
described [9, 18]. They are in the narrow field of web
based geospatial 3D. There were also a small number
of online articles and forum topics [13, 26, 27, 28, 29].
This section looks at how people came to understand
SJ and their approaches to it.
In the informal online documentation, there is
evidence people have had difficulty understanding the
problems caused by large distances from the origin. On
the blitzcoder community forum [26], “Nukomod”
initially did not understand what floating point
coordinates and distance from origin would do to
motion and rendering: The further a mesh travels from
the 0,0,0 origin the more it begins to 'break apart'.
There seems to be some inaccuracy in positioning child
entities and the whole model begins to 'shake'.
In the BlitzBasic forum, “Second Chance” [29] had
a problem with disappearing planets in a space game:
“...Then it's assigned its orbital distance from the star
(0,0,0). Everything looks good until you get out to
about the orbit of Uranus (29,000,000 game units) and
beyond, at that point the planets start to wink in and out
of existence.”
In a gamedev.net forum, “Lode” [27] was surprised
by a problem with rendering planets in a space game: “
... just to test I made some cube-planets, and even if
they're only 1000 units they're uglier than the EXACT
same scene 1000 times smaller! ... for bigger scenes
with more cubes at larger distances, it looks even worse
that this”.
In another blitzcoder forum topic, “Nmuta” [28] had
similar problems with objects 10,000 units along the z
axis: “Anyone else hear about this problem occurring
if you don't normalizing your world regularly, and
getting graphics problems when you go too far away
from 0,0,0 ? I need to know what that means.”
The above quotes show that people working on
large scale worlds can be surprised when encountering
the limits of floating point coordinates and are initially
at a loss as to what to do about it.
There is even evidence that once people understood
the jitter problem and a general solution: that
viewpoint and object coordinates should be closer to
the origin, they still had difficulty grasping the FO
concept. For example, on the blitzcoder forum [28],
Nmuta says: It's just weird, the thought of it. Instead
of moving a person, you are moving several tons of
land and buildings and enemies!!!! ... The whole
concept of 3D in general is such an interesting
illusion”. “Mt Dew” says: “When first suggested to me
that I needed to change my system from moving my
person through the solar system to moving the solar
system around the person ... well ... i was a bit
daunted”. “Andy” stated: “This is probably the single
most difficult concept for new programmers to
understand, but it is vital to the process.”
Leclerc et al. and Reddy et al. [9,18] understood SJ
and created the piecewise continuous world solutions
of GeoVRML and TerraVision. However, they did not
take the method to a full FO solution. Since these
authors published in a fairly narrow field, this might
explain why their understanding did not disseminate to
the broader community and reach the games and flight
simulation audience.
The lack of adequate, widespread literature on the
subject and evidence of difficulty thinking of a solution
in terms of continuous reverse transformation are the
main motivations for writing this paper. The following
section describes the design for FO navigation.
3.3. Design for floating origin navigation and
rendering
To implement FO navigation, the design of the
client needs to support reverse transformation of the
world whenever the viewpoint is set to a WC and
during free navigation. This section describes a general
distributed architecture to meet these requirements.
As shown in Figure 3, reverse transforming the
world can be achieved by placing a top level transform,
the world transform (WT), over the entire set of objects.
Whenever a viewpoint is selected, the inverse of the
viewpoint's coordinate is applied to the WT. The result
is that the objects are shifted in reverse towards the
viewer who stays at the origin.
Figure 3. Structure of the client, showing how
centered viewpoint and navigation components
affect the WT which, in turn, transforms objects.
Note how other navigation and behaviours do not
affect the WT but act directly on the objects.
Free navigation controls also apply a reverse
transformation to the WT. Other interaction and
behaviors, such as moving an object, opening a door, or
pressing a button, all happen in the normal fashion and
do not affect the WT.
A necessary consequence of the WT is that
viewpoints must not be under the WT itself because
this would form an endless feedback loop with the WT.
The design therefore separates viewpoints from the
objects and object transforms that are under the WT.
Normally, an application must keep track of where
objects are in relation to each other and to the user's
viewpoint in order to manage relationships and
interactions between objects and render things
correctly. However, in the FO approach, the object
coordinates in each user's DS are unique to that user's
position in the world because they are always the
smallest values relative to the user's current world
position. This is one reason why the OS part of the
application must be separate from the DS, so it can
keep track of viewpoint and object position in WC
while the DS separately transforms the local coordinate
system of each user. This also implies the application
has to keep track of a unique WT for each user.
A VW must be distributed to support multiple
participants, such as in a MMOG, distributed
simulation [2,11] or for collaboration. The OS
maintains the overall VW picture and oversees
interaction between participants, so it is the OS which
needs to be distributed, usually by putting part of it on
one or more servers. Similarly, distributing the FO
method is a matter of separating the OS into client and
server parts and defining a network communication
protocol to transmit the necessary information between
the parts (Figure 4).
It is the responsibility of each client DS to provide
position updates as the user navigates so the OS can
track positions in WC. In a distributed application, the
client's DS will pass its updated user position to its
local OS which now sends it on to the server OS. This
is similar to Massively Multiplayer Online Games
(MMOGs): the online servers must get user position
updates streamed back constantly in order to correctly
perform collision detection, physics and interactions
and update the visible picture for all users. The main
difference is that the server OS is keeping track of
reverse transforms for each user locale in addition to
tracking object users' WC positions.
Apart from changing the navigation code to reverse
transform the WT, the collision detection algorithm
may also need modifying. In a conventional system,
collision detection activates when navigation causes a
volume around the viewpoint to intersect with an
object. With FO, because the viewpoint does not move,
collision detection has to activate when an object is
moved to collide with the volume around the
viewpoint.
In a VW, the user only needs to see the part of the
world in the vicinity of the current location. Therefore,
only detail from this part, the user's locale, need be
downloaded from server to client. That is no different
from MMOGs which already do similar management of
the amount of information the client system has to
handle and display. This management technique is
called Level of Detail (LOD) and not only limits the
information displayed but what has to be transformed.
In the FO approach, LOD would be streamed from
the server on demand to keep the overhead of changing
detail to a minimum as the user moves. In addition,
whenever a user selects a viewpoint the server will pass
the client the appropriate reverse transform to shift the
local DS's objects to the center of the locale. This
information may be in the form of a centered viewpoint
(Figure 2) or raw transform information.
Many objects such as terrain and other static things
do not have to exist in the DS until they are about to
become in visible range. Then they are placed
dynamically in the environment. This just in time
dynamic placement means objects are positioned with
optimum accuracy because their DS coordinates are
minimised to the smallest they can be before being
placed.
To transmit LOD, position and other information
between client and server, current distributed VW
applications commonly use TCP/IP sockets [20], or
UDP [21] for communication between client and
server. Some systems use multicast [22] and others use
HTTP [19]. A combination of two of these methods is
also possible. The planet-earth project [23] uses HTTP
because it is widely supported and the fact that it
requires no setup effort for the user.
Figure 4. Architecture of the distributed VW
application showing separation of client and
server parts of the OS and how transformations
and position streaming is communicated.
Figure 4 shows the logical architecture of a
distributed VW application with the OS divided into
client and server components. Locale, LOD, transform
and position information is exchanged between the
server and client parts of the distributed OS. The client
OS applies reverse transforms to the visible world via
the DS, giving the user the impression of moving
through the world.
From this section, the following design aspects are
required to implement FO:
1. a top level transform, the WT, that affects all the
objects in the VW,
2. special centered viewpoints which reverse
transform the world through the WT,
3. a free navigation system that applies a reverse
transform to the WT,
4. separation of viewpoint transforms from object
structures in the DS,
5. distributing the OS between client and server
and providing a supporting protocol,
6. modified collision detection and terrain
following,
7. streamed LOD, and
8. dynamic, just-in-time placement
4. Comparison of floating origin with
traditional methods
4.1 Design complexity and performance costs
There is a performance and design cost to traditional
solutions. Morrowind [12], for example, has a large
world divided into smaller parts. A player walking far
enough along a path will experience the hiatus
described in section 2. The delay is caused by the game
engine loading terrain and objects for a connecting
segment because the player has crossed one of the
invisible boundaries that separates segments. Apart
from causing a disruption to the immersive experience,
such events occupy the system resources enough to
make gameplay hesitate for a noticeable time.
Even though Dungeon Siege has no loading screens,
its space walk has significant performance costs. It
requires a scaffolding: a structure of linked nodes that
enable the walking algorithm to work its way out from
the new center node to other neighbors. It uses
considerable processing resources and the frequency of
performing recalculations has to be limited: “as
infrequently as possible to avoid bogging down the
CPU ” [1].
Algorithms like Oneil's also involve extra work to
modify the transformation for each object. Like other
graphics systems, Oneil's would require a structure
through which objects can be located in relation to each
other and the world. To transform each object the
structure has to be traversed to access each object's
transform. The work for transform calculations plus
scaffolding traversal is proportional to the number of
objects. Oneil's algorithm runs every frame, so, for a
large number of objects, would represent a large
processing overhead at a good frame rate (greater than
30 times a second).
In the blitzcoder forum [28], Andy said that with his
method, shifting all objects in one go is too
computationally expensive and would produce a
noticeable delay, so the algorithm was enhanced to
progressively shift objects, a small number at a time,
while allowing other operations to continue.
In contrast, the FO method does not need the
scaffolding and transform operations used by Dungeon
Siege, Oneil and others on every object, as the objects
are automatically translated via the WT. Therefore, a
lot of processing overhead is removed.
For viewpoint movement the reverse transformation
requires no additional code above what is normally
there because the navigation code that previously
transformed the viewpoint now (inversely) modifies the
WT instead. It is just the same operations applied in
reverse on a different place. Therefore, there is no
additional performance cost to using FO. This is the
same conclusion that Nmuta came to: Nmuta [28]: “Yet
in terms of rendering, the computer doesn't really know
the difference I suppose. It would still be the same
number of polygons moving just as fast in the same
direction.”.
Although GeoVRML does not have the overhead of
transitions between segments because it uses a
continuous world, free navigation still allows the
viewpoint to move far from the origin where jitter can
occur and there is no automated control in place to
prevent it. There is also nothing stopping the
GeoViewpoint position being set to the other side of
the world to its origin, in which case jitter would be
very noticeable. The FO method does not separate
viewpoint position from the origin, thus eliminating
these potential problems.
4.2 Coordinate systems and representation
The FO method exploits the high fidelity region
around the origin of the floating point space used by
modern graphics systems. If other than floating point
was used, this would not be possible. Floating point
with a precision greater than 8 bits only came into wide
use in graphics hardware from 2002, when the Pixel
Shader 2.0 specification was released [16]. Prior to
that, fixed point and integer numbers were commonly
used for coordinates and they have an even distribution
of representable numbers. Therefore, a FO approach
would not have benefited visualisation. This
background may also have contributed to the
difficulties some people had in understanding SJ and its
FO based solution on modern hardware.
There is no need for representing the coordinates of
objects and viewpoint in double precision floating
point as Oneil thought was necessary [13] because the
dense precision region around the SPFP origin gives
sufficient accuracy for smooth motion and accurate
rendering in VWs up to and larger than the earth [24].
Not having to use double precision for operations also
reduces processing overhead because SPFP operations
are faster than double precision operations [13].
Multiple local coordinate systems like in EL,
FlightGear and VGIS are also not required in an FO
approach. All supporting structures and algorithms to
handle transitions between segments, as in Morrowind,
Eternal Lands and Dungeon Siege are no longer
needed.
4.3 Applying a FO design
Despite its efficiency benefits, the FO method
cannot be fully exploited if the OS and DS are not
designed to support it. In online forums, there is
evidence that people attempted an approach similar to
FO but found it was not efficient to modify an existing
application. For example, Nmuta [28] tried using an
FO type of system to stop SJ with his space game, but
gave up and went with a an on-the-fly method when he
found the overhead of implementing FO on top of an
the B3D engine was too high: “keeping the player at
0,0,0 all the time as MSW suggested is proving to be a
little too tricky to implement given my current engine's
set up, so I think I might use your way, with the grid.”.
In the same forum “Andy” described the cost of
implementing FO on B3D, saying “You would end up
having to write code to do everything that B3D does
already and add overhead.”. He further said that the
progressive piecewise approach he proposed was only a
few lines of code but modifying B3D's “movement,
rotation and collision code will add hundreds of lines
and slow the program”.
From the above one can conclude that for a VW to
make best use of the efficiency of FO it would have to
be designed from the beginning with that method in
mind or already have a design that can be easily
adapted.
As all of the conventional approaches to SJ allow
the viewpoint to move relative to the origin, accuracy
of motion and rendering will continually vary: i.e. the
fidelity will be unpredictable. Many developers may
not realise the cause when the quality of rendering is
subtly wrong when viewed from a large coordinate.
Small seams may appear in one place but not another.
Small unaccounted for inaccuracies could plague
developers who do not know they are simply caused by
SJ. FO ensures rendering is always performed from a
centered viewpoint and therefore ensures all motion
and rendering has the same quality.
The absence of complex scaffolding and code to
handle transitions from one local coordinate system to
the next results in a simpler design. As pointed out in
section 4.1, this simpler design has less processing and
code overhead, as long as the implementation is not
burdened by an existing code base with incompatible
design.
5. Conclusion
One may sympathise with parents who complain the
younger generation are lazy: they expect everything to
come to them. In a virtual world the rules of physics do
not apply, it is just as easy to bring the world to you as
it is to move yourself in the world. This paper has
shown that for modern graphics hardware based on
floating point numbers, it is better to keep the
viewpoint at the origin and reverse transform the world.
So in terms of virtual worlds, the young have the right
way of thinking.
The problem of spatial jitter and several classes of
conventional approaches to the problem have been
described. The benefits of the floating origin solution
are that it:
1. eliminates observable spatial jitter,
2. lowers design complexity,
3. lowers processing overhead,
4. provides constant, optimum fidelity of motion
and rendering compared to the continually variable
fidelity of conventional approaches, and
5. allows end user devices to operate within their
precision limits without spatial jitter problems.
These benefits have to be weighed against the need
for a new design that will support floating origin
navigation efficiently.
Floating point suits the view-centric nature of
computer graphics: the local region around the
viewpoint is what the user sees and that is where most
of the accuracy of rendering and motion needs to be. A
floating origin allows this natural benefit of floating
point to be applied to the rendering of every frame.
When combined with level of detail streaming and
dynamic placement a floating origin optimizes the
quality of motion, interaction and rendering throughout
large, continuous virtual worlds by minimizing spatial
jitter.
6. References
[1] Bilas, S. 2003. The Continuous World of Dungeon Siege,
Gas Powered Games,
www.drizzle.com/~scottb/gdc/continuous-world.htm.
[2] Blais,C., Brutzman, D., Horner, D., Niclaus, S. 2001.
Web-based 3D technology for scenario authoring and
visualisation: the SAVAGE project, Interservice/Industry
Training, Simulation and Education Conference (I/ITSEC)
2001, Orlando, Florida.
[3] Barrus, J. W., Waters, R. C., and Anderson, D. B. 1996.
Locales and Beacons: Efficient and Precise Support For
Large Multi-User Virtual Environments. Retrieved: March 1,
2003, from http://www.merl.com/papers/TR95-16a/.
[4] Carmack, J. 2003. Carmack's .plan files blog, 29/1/03,
http://doom-ed.com/blog/category/doom-ed/john-carmack/.
[5] Computer Architecture, section 2.6,
http://csep1.phy.ornl.gov/ca/node8.html#SECTION0002600
0000000000000.
[6] Definition of Coordinate,
http://www.chatham.k12.ma.us/techpage/dictionary/a.htm.
[7] Horvath, G. and Verhoeff, T. 2003. Numerical
Difficulties in Pre-University Informatics Education and
Competitions, Informatics in Education, 2003, Col. 2, No. 1,
21-38.
[8] IEEE 754-1985 (R1990). IEEE Standard for Binary
Floating-Point Arithmetic, http://standards.ieee.org/.
[9] Leclerc, Y., Reddy, M., Eriksen, M., Brecht, J. and
Colleen, D. 2002, SRI's Digital Earth Project, Technical
Note No. 560, Artificial Intelligence Center, SRI
International, Menlo Park, CA.
[10] Lindstrom, P., Koller, D., Ribarsky, W., Hodges, L.,
Bosch, A., and Faust, N. 1997. An Integrated Global GIS
and Visual Simulation System. Tech. Rep. GIT-GVU-97-07,
Georgia Institute of Technology, Mar. 1997.
[11] Macedonia, M., Zyda, M., Pratt, D., Barham, P. and
Zestwitz, S., (1994). "NPSNET: A Network Software
Architecture for Large-Scale Virtual Environments",
Presence: Teleoperators and Virtual Environments, Vol. 3,
N. 4, 1994, pp.265-287.
[12] Morrowind game, Bethesda Softworks,
http://www.elderscrolls.com.
[13] O'Neil., S. 2002. A Real-Time Procedural Universe,
Part Three: Matters of Scale, Gamasutra, July 12, 2002.
[14] Olson, C.L. 1997, FlightGear Scenery Generation Tools,
http://www.jp.flightgear.org/Docs/Scenery/SceneryGeneratio
n/SceneryGeneration.html.
[15] Pirates of the Caribbean game, Bethesda Softworks,
http://pirates.bethsoft.com.
[16] Pixel Shader 2.0 precision, http://www.digit-
life.com/articles2/ps-precision.
[17] Privantu, R. 2004. Eternal lands, post mortem,
http://www.devmaster.net/articles/mmorpg-
postmortem/part1.php.
[18] Reddy, M., Iverson, L., Leclerc, Y. and Heller , A.
2001. GeoVRML: Open Web-based 3D Cartography. In
Proceedings of the International Cartographic Conference
(ICC2001), Beijing, 6-10 August 2001.
[19] RFC 1945 - Hypertext Transfer Protocol – HTTP/1.0,
May 1996.
[20] RFC 793 - Transmission Control Protocol, DARPA
INTERNET PROGRAM PROTOCOL SPECIFICATION,
1981.
[21] RFC 768 - User Datagram Protocol, J. Postel, ISI, 28,
1980.
[22] RFC 966 - Host groups: A multicast extension to the
Internet Protocol, Network Working Group, S. E. Deering,
D. R. Cheriton, Stanford University, December 1985.
[23] Thorne, C. 2005. Exploiting an Evolutionary Accident
in Web3D Communications to Integrate Application,
Proceedings of the SIGGRAPH 2005 conference on Web
graphics: in conjunction with ACM SIGGRAPH 2005: Web
Graphics, Session: 3D, Conference CD ROM, Los Angeles,
CA, 31 July-4 August, 2005.
[24] Thorne, C. and Weiley, V. 2003. Earth's Avatar: The
Web Augmented Virtual Earth (WAVE), SIGGRAPH 2003
Conference on Web Graphics, Session: Visualisation, San
Diego, CA, July 27-31.
[25] VRML. ISO/IEC 14772-1:1997. The Virtual Reality
Modeling Language, Part 1.
[26] 2004 blitzCoder community forum, Topic Large
playing area problems, initiated by “Nukomod”
n.http://64.233.179.104/search?q=cache:3gSbeJsSYEcJ:ww
w.blitzcoder.com/cgi-bin/ubb-
cgi/ubbmisc.cgi%3Faction%3Dfindthread%26forum%3DFor
um14%26number%3D14%26thisthread%3D001610%26go
%3Dnewer.
[27] 2002 gamedev community forum, Topic Large object in
OpenGL look ugly???, initiated by “Lode”:
http://www.gamedev.net/community/forums/topic.asp?topic_
id=106633.
[28] 2003 blitzCoder community forum, Topic: Huge worlds,
initiated by “Nmuta” http://www.blitzcoder.com/cgi-bin/ubb-
cgi/postdisplay.cgi?forum=Forum4&topic=000352.
[29] 2004. BlitzBasic community forum, Topic: Mystery of
the disapearing planets, initiated by “Second Chance”
http://www.blitzbasic.co.nz/Community/posts.php?topic=233
66.
[30] Wolfram Research, Mathematica documentation,
http://documents.wolfram.com/v5/TheMathematicaBook/Ad
vancedMathematicsInMathematica/Numbers/3.1.4.html.
[31] World of Warcraft web site, http://worldofwarcraft.com.
... A number of related techniques for optimisation of spatiotemporal systems have been documented [2,3,4,5]. They were derived from positional error and another fundamental principle: position independence. ...
... They were derived from positional error and another fundamental principle: position independence. One of the techniques, Continuous Floating Origin [4,5], has gained increasing adoption in game technology. ...
Research
Full-text available
Measuring and predicting error is important in computing, where accuracy and reliability are major concerns. A new way to more accurately measure error using a relative geometric formula was developed for handling of error on a more solid and effective scientific basis. The approach became a foundation for other benefits, such as improved scalability, quality, and performance. However, the approach to error measurement has not come into general use and the potential gains are still not fully realised or even well understood. This focus article re-presents key insights of that research in order to establish greater awareness of their value to modern computing.
... No performance and quality analysis literature was found in relation to these implementations. It was also noted that the documented implementations were divergent from the intended algorithm of the original floating origin research [37] [39]. This paper shows an optimal quality algorithm can have orders of magnitude less base error, an aspect of particular importance to scientific and engineering calculations sensitive to error. ...
... This idea was aptly mirrored in a Futurama episode when the Planet Express space ship was described as moving by staying still and shifting the Universe around itself [13]. This method was later called continuous reverse translation [37] and then continuous floating origin [39] to emphasise the immediate response linkage of origin translation to viewpoint translation. ...
Conference Paper
Full-text available
As we move firmly into the digital age, navigation through cyberspace has become an increasingly ubiquitous form of human-computer interaction. Whether the application we use is geospatial, flight simulation, virtual reality, augmented reality, simulation or game; we rely on sophisticated computation to paint data into views we can understand. 3D images and video with moving perspectives allow rapid navigation and assimilation of information. However, despite all the sophistication of modern technology, we have inadvertently programmed random cracks into cyberspace leading to positional jitter. Positional jitter can present as: random motion, rendering errors, physics errors and imprecise interaction. This unintended numerical error, and its mitigation, has been a focus of research and development over that past 2 decades. A review of mitigation methods has revealed differences in the quality, complexity and performance of implementations and some ad-hoc approaches to designing for sufficient quality. To help move research and development towards a consensus solution, this paper reviews and evaluates different approaches. New metrics to estimate error and quality are presented. A simple and efficient method to minimising positional jitter, that will benefit scientific and engineering calculations sensitive to error and achieve the best performance and quality for general applications, is recommended.
... Over the past two decades, an understanding has developed that the quality of positional systems varies with position, causing positional jitter, and one key approach to address this issue is called floating origin [2]. ...
... The visual representation of world perspectives, or rendering, involves sophisticated calculations that are sensitive to input error and this is, in part, due to increasing constraints in precision through the stages of the pipeline [4] and variations in coordinate resolution with distance from the origin [2]. Floating origin, coupled with other origin-centric techniques [1], addresses both of these aspects and it is applied just before the rendering step in the pipeline. ...
Experiment Findings
Full-text available
Positional systems perform computation using position variables, such as time and location. Many applications fall under this umbrella to some degree and can suffer from accuracy problems referred to as positional jitter. A general algorithmic approach, called floating origin, has been developed to reduce positional jitter. Floating origin is part of an even more general origin-centric paradigm aimed at improving the fidelity and scalability of applications. This article presents tests of two variations of floating origin for sensitivity to positional error using a simple physics-based simulation. The results show that the continuous floating origin algorithm is capable of scaling the simulation to Solar system scale with stable and repeatable accuracy - well beyond the normally accepted limits of the Unity game engine.
... No performance and quality analysis literature was found in relation to these implementations. It was also noted that the documented implementations were divergent from the intended algorithm of the original floating origin research [37] [39]. These considerations were the motivation to measure floating origin implementations and determine a best practice approach. ...
... This idea was aptly mirrored in a Futurama episode when the Planet Express space ship was described as moving by staying still and shifting the Universe around itself [13]. This method was later called continuous reverse translation [37] and then continuous floating origin [38] [39] to emphasise the immediate response linkage of origin translation to viewpoint translation. ...
Preprint
Full-text available
As we move firmly into the digital age, navigation through cyberspace has become an increasingly ubiquitous form of human-computer interaction. Whether the application we use is geospatial, flight simulation, virtual reality, augmented reality, simulation or game; we rely on sophisticated computation to paint data into views we can understand. 3D images and video with moving perspectives allow rapid navigation and assimilation of information. However, despite all the sophistication of modern technology, we have inadvertently programmed random cracks into cyberspace leading to posi-tional jitter. Positional jitter can present as: random motion, rendering errors, physics errors and imprecise interaction. This unintended numerical error, and its mitigation, has been a focus of research and development over that past 2 decades. A review of mitigation methods has revealed differences in the quality, complexity and performance of implementations and some ad-hoc approaches to designing for sufficient quality. To help move research and development towards a consensus solution, this paper reviews and evaluates different approaches. New metrics to estimate error and quality are presented. A simple and efficient method to minimising positional jitter, that can achieve the best performance and quality, is recommended.
... The clipping planes are too separated for standard projection but reasonable for extended depth buer strategies. The Camera was positioned at the origin, to limit the amount of spatial jitter and increased Z-ghting as in the oating origin technique [Tho05]. ...
Conference Paper
Large scale 3D scenes in applications like space simulations are often subject to depth buffer related issues and visual artefacts like Z-fighting and spatial jittering. These issues are primarily a result of indistinguishable depth buffer values. To mitigate these issues, many techniques have been developed over time to better distribute depth values over the clipping range. These techniques range from simple adjustments of the projection matrix to complex solutions like multistage rendering with layered depth buffers. This work presents, compares and evaluates commonly used approaches found in iterature and real world applications. An experiment is set up to compare the presented depth buffer techniques using the metric of minimum triangle separation (MTS). The gathered results are presented and evaluated, to give a good overview on which techniques are well suited for the use in applications with large scale 3D scenes.
... Continuous Floating Origin (CFO) [2,3] is a virtual viewpoint navigation technique that keeps the player camera, or view, at the World origin as the player relative moves through virtual space. ...
Experiment Findings
Full-text available
In the field of computer graphics, objects that turn to face the user viewpoint are called billboards. Billboards can be used for information purposes or to increase apparent scene complexity. The latter use is the focus for performance enhancement in this article. This article documents an experiment which compares a novel fast billboard algorithm with the more common method. The new method exploits a synergy between the fundamental computer graphics rotation algorithm and a feature of the view navigation technique Continuous Floating Origin.
... As such, it makes sense that their bounds be limited because an infinite bounds would not benefit from relocation error minimisation. Examples of relative closures can be found in the application of position optimisation law [2] and related virtual space navigation [3,4,5]. ...
Technical Report
Full-text available
Relative closure This note is the third in a series on relative computation building on earlier work and forming part of the foundation for relative computation. The following definition provides a definitive reference for future articles. A relative closure is a position independent algorithm with a bounded set of positional input. ...
Chapter
Three-dimensional visualization of maps is becoming an increasingly important issue on the Internet. The growing computing power of consumer devices and the establishment of new technologies like HTML5 and WebGL allow a plug-in free display of 3D geo applications directly in the browser. Existing software solutions like Google Earth or Cesium either lack the necessary customizability or fail to deliver a realistic representation of the world. In this work a browser-based visualization component for geo-information is designed and a prototype is implemented in the gaming engine Unity3D. Unity3D allows translating the implementation to JavaScript and to embed it in the browser with WebGL. A comparison of the prototype with the open-source geo-visualization framework Cesium shows, that while maintaining an acceptable performance an improvement of the visual quality is achieved. Another reason to use a gaming engine as platform for our streaming algorithm is that they usually feature engines for physics, audio, traffic simulations and more, which we want to use in our future work.
Article
Full-text available
CityGML, a semantic information model for digital/virtual city models has become quite popular in various scenarios. While the data format is still actively under development, it is already supported by different software solutions, especially GIS-based desktop applications. Mobile systems on the other hand are still neglected, even though the georeferenced objects of CityGML have many application fields, for example, in the currently popular area of location-based Augmented Reality. In this paper we present an independent multi-platform CityGML viewer, its architecture and specific implementation techniques that we use to realize and optimize the process of visualizing CityGML data for use in Augmented Reality. The main focus lies in improving the implementation on mobile devices, such as smartphones, and assessing its usability and performance in comparison to web-based approaches. Due to the constrained hardware resources of smartphones, it is a particular challenge to handle complex 3D objects and large virtual worlds as provided by CityGML, not only in terms of memory and storage space, but also with respect to mobile processing units and display sizes.
Article
Full-text available
The creation of a digital representation of the Earth and its associated data is a complex and difficult task. The incredible size of geospatial data and differences between data sets pose challenges related to big data, data creation, and data integration. Advances in globe representation and visualization have made use of Discrete Global Grid Systems (DGGSs) that discretize the globe into a set of cells to which data are assigned. DGGSs are well studied and important in the GIS, OGC, and Digital Earth communities but have not been well-introduced to the computer graphics community. In this paper, we provide an overview of DGGSs and their use in digitally representing the Earth, describe several current Digital Earth systems and their methods of Earth representation, and list a number of applications of Digital Earths with related works. Moreover, we discuss the key research areas and related papers from computer graphics that are useful for a Digital Earth system, such as advanced techniques for geospatial data creation and representation.
Conference Paper
Full-text available
The Virtual Reality Modeling Language (VRML) ushered in a new era in computer graphics by providing the first international standard 3D format for the Web (web3D). Unfortunately, some who tried VRML applications found they did not work and naturally blamed the language. However, the problem often lay in the sensitivity to different client software environments of the programming interfaces used to extend VRML. In many cases, VRML applications had to be extended to include things VRML lacked, such as sophisticated user interface and interactivity, database access, multiuser support, security and system integration support. These important aspects of modern systems were added via a programming interface (PI), called the External Authoring Interface (EAI). The problem was that applications based on the EAI would not work reliably due to changes in the client environment by competitive commercial stakeholders, affecting things like the support for a required third party programming language. It is this problem that often lead to unsatisfactory user experiences, not VRML itself.Below the client battlefield radar, three small web3D functions accidentally evolved, in symbiosis with the Web, to provide an alternative integration method built on a simple but solid foundation: the Hypertext Transport Protocol (HTTP). HTTP is the protocol from which the very fabric of the Web was woven. This paper presents methods to integrate web3D application components directly via HTTP. The three web3D functions are used in combination to implement a communication cycle that makes use of persistent state stored in web services. The approach uses open standards, is portable across platforms and resilient to changes in client environment. Applications based on this approach will work more reliably on disparate end user systems and enable developers to leverage increasingly sophisticated web advances.
Conference Paper
Full-text available
Virtual worlds including whole earth environments have been made since the beginning of VR. In 1998, Vice President Al Gore described a vision called the “Digital Earth" which led to a burst of activity. This subsided after the year 2000 when the political landscape and organizational structures changed. We postulate another reason for this downturn was due to a focus by some developers on proprietary, costly infrastructure for large Earth databases, for which applications were then sought. This approach can quickly either overwhelm the capacity of an organization’s resources, or at least become hard to justify when there is no additional funding stream. Therefore, we propose as an alternative a low cost, open source, collaborative and highly scalable system. Some existing development has come from organizations with their own map databases, intent on publishing their own content. Our system will empower other organizations or individuals to publish their own content into the developing Virtual Earth. We have started implementing these methods in our 3D Metanet Atlas Platform (3map) project.
Article
Full-text available
This paper explores the issues involved in designing and developing network software architectures for large scale virtual environments. We present our ideas in the context of NPSNET-IV, the first 3D virtual environment that incorporates both the IEEE 1278 Distributed Interactive Simulation (DIS) application protocol and the IP Multicast network protocol for multi-player simulation over the Internet. Key Words: Virtual reality, networked virtual environments, large scale distributed interactive simulation, DIS, IP Multicast. I. Introduction The construction of large scale virtual environments has been a long-stated goal of virtual environment (VE) proponents and now is a major objective of both commercial and government organizations. We define large scale environments as those that support more than a 1000 concurrent dynamic entities or players. However, there exists major technical challenges which will require new network software architectures for distributed VEs. This paper exa...
Conference Paper
There is a natural desire to make multi-user virtual environments large in spatial extent, in numbers of objects, and in numbers of users interacting with the environment. However, doing this brings up several problems: efficiently managing the flow of large amounts of data between large numbers of users, representing precise position and velocity information about objects that are arrayed across a large volume of space, and allowing designers to create parts of a virtual environment separately and combine them together later. Locales are an efficient method for solving these problems by breaking up a virtual world into compact chunks that can be described and communicated independently. In addition, locales can be used to support a number of special effects that allow virtual worlds to easily transcend reality. While having many benefits, locales introduce an additional problem: finding something when you do not know what locale it is in. This is solved by the companion concept of beacons, which makes it possible to find something no matter where it is
Article
query formats. One should explicitly avoid exposing any of the internal structure of the database in order to formulate queries. Moreover, one needs to allow for the possibility of sophisticated Boolean combination of simple queries in order to find exactly the desired set of metadata.
Web-based 3D technology for scenario authoring and visualisation: the SAVAGE project, Interservice/Industry Training, Simulation and Education Conference (I/ITSEC)
  • C Blais
  • D Brutzman
  • D Horner
  • S Niclaus
Blais,C., Brutzman, D., Horner, D., Niclaus, S. 2001. Web-based 3D technology for scenario authoring and visualisation: the SAVAGE project, Interservice/Industry Training, Simulation and Education Conference (I/ITSEC) 2001, Orlando, Florida.
Simulation and Education Conference (I/ITSEC)
Training, Simulation and Education Conference (I/ITSEC) 2001, Orlando, Florida.
Carmack's .plan files blog
  • J Carmack
Carmack, J. 2003. Carmack's.plan files blog, 29/1/03, http://doom-ed.com/blog/category/doom-ed/john-carmack/.
  • G Horvath
  • T Verhoeff
Horvath, G. and Verhoeff, T. 2003. Numerical Difficulties in Pre-University Informatics Education and Competitions, Informatics in Education, 2003, Col. 2, No. 1, 21-38.