Conference PaperPDF Available

Healing Cracks in Cyberspace: towards best practice

Authors:
  • floatingorigin.com

Abstract and Figures

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.
Content may be subject to copyright.
Healing Cracks in Cyberspace: towards best practice
Chris Thorne
Systemic Pty Ltd
dragonmagi@gmail.com
ABSTRACT
As we move rmly into the digital age, navigation through
cyberspace has become an increasingly ubiquitous form of
human-computer interaction. Whether the application we
use is geospatial, ight simulation, virtual reality, augmented
reality, simulation or game; we rely on sophisticated compu-
tation 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 dierences
in the quality, complexity and performance of implementa-
tions and some ad-hoc approaches to designing for sucient
quality. To help move research and development towards a
consensus solution, this paper reviews and evaluates dier-
ent approaches. New metrics to estimate error and quality
are presented. A simple and ecient method to minimising
positional jitter, that will benet scientic and engineering
calculations sensitive to error and achieve the best perfor-
mance and quality for general applications, is recommended.
CCS CONCEPTS
Human-centered computing Visualization tech-
niques.
KEYWORDS
Digital positional systems, oating point, navigation, inter-
action, cyberspace, positional jitter, oating origin, quality,
accuracy
Permission to make digital or hard copies of part or all of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for prot or commercial advantage and that copies
bear this notice and the full citation on the rst page. Copyrights for third-
party components of this work must be honored. For all other uses, contact
the owner/author(s).
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
©2019 Copyright held by the owner/author(s).
ACM ISBN 978-1-4503-7696-9/19/12.
https://doi.org/10.1145/3369457.3369540
ACM Reference Format:
Chris Thorne. 2019. Healing Cracks in Cyberspace: towards best
practice. In 31ST AUSTRALIAN CONFERENCE ON HUMAN-COMPU TER-
INTERACTION (OZCHI’19), December 2–5, 2019, Fremantle, WA, Aus-
tralia. ACM, New York, NY, USA, 12 pages. https://doi.org/10.1145/
3369457.3369540
1 INTRODUCTION
After putting down the compass and picking up the com-
puter, we began to rely on digital positional systems for
mapping, navigation, interaction and commerce in many
areas of work and entertainment. Such applications cover a
wide range of industry, e.g.: geospatial, military, games, vir-
tual worlds, modelling and simulation, to name a few. They
have in common some form of virtual space, or cyberspace.
We navigate cyberspace in moving pictures: observing
and responding to digital images on video screens. Data
is synthesised and information perspectives are presented
as seen from a virtual viewpoint. These perspectives, or
renderings[
45
], are our observational window through which
we comprehend the digital world.
Before the computer, we made sense of our position in the
World by measuring relative to the latitude and longitude ori-
gin (0,0), using analog tools and mathematics. The accuracy
of our calculations did not change with location and was
not expected to. However, translating our historical origin-
relative navigation concepts into computer algorithms had
an unexpected side eect: the accuracy of digital position
and calculation does change with location. In digital spaces,
positional errors increase with distance from the origin, in-
dependently of any other form of error that is input into
calculations. When these errors increase suciently, posi-
tional jitter becomes noticeable.
This paper explains the positional jitter phenomenon and
its widespread impact on spatiotemporal applications. Re-
cent methods to mitigate positional jitter are reviewed and
categorised. The eciency and eectiveness of these meth-
ods are compared against three metrics: performance, quality
and complexity, in order to decide which is best practice for
interaction and t for purpose.
The literature review for this study found that the most
popular “oating origin” approaches to jitter were based on
a common code method, or algorithm. Inspection of imple-
mentations of a number of code samples and documentation
revealed this common approach appeared to be sub-optimal
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
for performance and quality. No performance and quality
analysis literature was found in relation to these implemen-
tations. It was also noted that the documented implemen-
tations were divergent from the intended algorithm of the
original oating 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 scien-
tic and engineering calculations sensitive to error. These
considerations were the motivation to examine and mea-
sure oating origin implementations and determine a best
practice approach. A best practice for positional calculations
is important because it can lead to improvements to many
aspects of our lives that rely on digital systems.
The Unity game engine is used to demonstrate virtual
spaces, or scenes, navigation and jitter within the spaces, and
operations on the scene or objects within. It is also used
to demonstrate jitter mitigation algorithms, and measure
performance and quality metrics. Figure 1 shows the Unity
interface with a scene in the middle panel.
Figure 1: Unity interface. The top left panel lists a hierar-
chy of game objects representing the game world, or
scene
.
The top middle panel shows Scene, Game or Asset view se-
lection tabs. The center panel is showing the scene design
view. The right panel Inspector gives information about ob-
jects or scripts you select. The bottom panel is divided into
an asset hierarchy view and list of assets.
Section 2 describes and illustrates positional jitter, and
points to past research for further explanation. Section 3
reviews the literature on industry accepted positional jitter
mitigation methods which focus on locating the viewpoint
near the origin, and describes how view navigation and jit-
ter mitigation works. Mitigation methods are categorised
and their high level logic is described. Section 4 presents
empirical measurements and analysis of results. Section 5
introduces new objective metrics and uses it to provide addi-
tional analysis. Concluding remarks are given in section 6
followed by further research in section 7.
2 POSITIONAL JITTER
Positional jitter, hereafter: jitter, for brevity, varies with the
resolution of oating point coordinate values, e.g. (x,y,z), and
their precision[
44
]: single precision where high performance
is needed and double precision for greater accuracy. Jitter
occurs when the resolution of local space around x, y or z,
decreases with their size: i.e. the distance of the local space
from the origin[
39
]. As resolution decreases, the relative
error of the coordinates increases, leading to greater error in
calculations that use them. The resulting errors manifest as
variations in rendering and jittery motion. These eects are
not always noticeable but becomes problematic when they
impinge on the quality or accuracy required by an application
[4] [39][31].
Figure 2 demonstrates how errors in a visual display, or
rendering, vary with position. The scene models a hallway
with two intersecting checker pattern objects positioned
1m from the viewpoint. Each image represents the same
scene from the same viewpoint. The viewpoint and objects
are in exactly the same position relative to each other. The
only dierence is the resolution of digital space in which they
reside. The scene is rendered accurately when the player
viewpoint is centered at the origin and becomes progressively
inaccurate as the scene and viewpoint are moved to distances
of 900,000 and beyond, where the checkerboard patterns
become unrecognisable. Lighting and shadows also vary.
Resolution induced error, magnied in calculations, is
solely responsible for the progressive breakdown of this
application. Applications that deal with large scales, such
as Earth or Solar system; or mission critical delity such
military software, need to take special measures to prevent
jitter and maintain the accuracy they need.
Early jitter mitigation methods primarily focussed on seg-
mentation of space into units that were small enough to
avoid noticeable jitter. Although segmentation is often nec-
essary for managing large regions and is appropriate within
the world model end of the simulation pipeline, it does not
provide a general solution to jitter and is not as appropri-
ate in the display end of the pipeline [
38
]. Approaches later
shifted to include origin manipulation after the publication
of papers leading up to Thorne’s thesis on origin-centric
techniques [
39
]. More recently, origin based methods refer
to some form of “oating origin” that diers in the code
implementations.
3 REVIEW OF VIEW NAVIGATION AND FLOATING
ORIGIN APPROACHES
Floating origin is a virtual navigation method that minimises
jitter and unpredictable, variable accuracy in calculations. It
employs a mathematical trick to exploit the greater accuracy
attainable from the high resolution region surrounding the
Healing Cracks in Cyberspace OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
Figure 2: Illustration of the positional variance of scene ren-
dering. The scene is rendered accurately when the viewpoint
is centered at (0 0 0) and becomes progressively inaccurate
when the scene is moved relative to the origin. a. At (0 0
0): the rendered view with viewpoint at the origin. b. At
(0 0 900): the scene darkens but this may be due to ren-
derer algorithm. c. At (9,000 9,000 9,000): The foreground
lighting brightens and a tearing eect on the oor. d. At
(90,000 90,000 90,000): objects appear pixellated as parts of
one checkerboard that were occluded now in front of the
other. The edges of shadows become ragged and tearing ef-
fects appear all over the scene. e. At (900,000 900,000 900,000):
the scene breaks up and random light/dark polygons appear
on the oor. f. Rendering has broken down completely when
the distance reaches 9million).
origin: instead of moving the viewpoint through space, the
space is moved in reverse. Moving the origin to a viewpoint
is mathematically equivalent to moving the entire visible
scene, or space, in reverse. This relative move achieves the
same apparent motion through space but with higher quality
views because jitter is minimised.
Although resolution, and therefore accuracy, can be im-
proved by maintaining the viewpoint within a certain dis-
tance from the origin, in early literature and implementa-
tions, the concept of oating origin was deliberately coupled
with continuous navigation to ensure optimal accuracy[
39
].
Described as zero-centered motion by Thorne[
36
], the navi-
gation view always stays at (0,0,0). Figure 3 is reproduced
from that paper to illustrate. 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 con-
tinuous reverse translation[
37
] and then continuous oating
origin [
39
] to emphasise the immediate response linkage of
origin translation to viewpoint translation.
For at least a decade, there have been many references to
“oating origin” that is not implemented as continuous navi-
gation, but allows a certain amount of origin-relative motion
before re-centering the viewpoint at the origin. The only
clear continuous oating origin reference in the literature is
a Web based Earth visualisation paper by Gutbell et. al. [
30
]:
“we dene the center of the map when the system starts
and use a method called Floating Origin, as described by
Thorne ... to guarantee the highest computational accuracy
around the area of the camera”. References to a continuous
oating origin method was given in a private correspon-
dence with Kahyaoglu[
17
] on the Mapbox[
19
] ZoomableMap
demo application: “ZoomableMap demo scene though up-
dates map on every camera move. So ... you’ll see it’ll change
on every small move.” In another private communications,
Zdarsky[
47
] and Benger[
3
] also refer to applying a continu-
ous method. With limited published formal material in this
area, further correspondence to expose the underlying algo-
rithms of commercial and non-commercial implementations
is required.
Figure 3: Zero-centered motion. A player is positioned at the
origin with a cube and cone nearby. In the left image, when
the user gives the command to move through the scene, the
scene is moved in the opposite direction instead. The user’s
view stays at the origin and the apparent motion is identical
to what was expected. The right image represents conven-
tional origin-relative navigation.
How continuous floating origin works
With Continuous Floating Origin (CFO), when an application
receives navigation movement input, e.g. from the mouse
or keyboard, the whole scene is moved in the opposite di-
rection to that which the player would move, using a single
Transform[
46
] function. Transform refers to the mathemat-
ical transformation of coordinates, and is usually achieved
by multiplying the coordinate values by a matrix: the trans-
formation matrix. This multiplication can scale, translate
and rotate the coordinates all at once. In the case of oating
origin, moving the scene requires a translation operation
only: values are subtracted from the the x, y and z position
of the scene.
Figure 4 illustrates a game scene in the Unity game editor
and engine. The panel on the right shows the view the player
will see when the game starts. On the left is a hierarchy of
objects, all under one called “root”. This root node is an
invisible object for the CFO algorithm only: the oating
origin reverse translation is applied to this node only and all
objects underneath the node will move.
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
Relationship to application structure. Positional applications
with graphical, or video output will generally use more than
one type of coordinate system. For modelling the entire appli-
cation world, coordinates such as (latitude, longitude, height)
for geospatial, segmented spatial coordinates for games and
other large scale applications, or (Right ascension, Declina-
tion) for astronomy. In addition, they may use double preci-
sion for greater accuracy. All these simulations also have in
common a transformation to the cartesian (x,y,z) coordinates
used to render video perspectives, usually in single precision
for greater speed, and further transformation to coordinates
suited to dierent stages of processing. Therefore, these sim-
ulations have a staged structure, a pipeline[
38
], that performs
operations in sequence, including converting application co-
ordinates into cartesian coordinates at the graphics output
stage.
The oating origin methods discussed in this paper apply
at this latter stage of the pipeline. A complete oating origin
solution has some relevant methods that may occur in a
higher application coordinate stage, e.g. when coordinates
are converted between high and low precision and converted
to cartesian. Such details have little impact on the analysis
of this paper and are not discussed further for simplicity and
clarity.
Summary. CFO has three main design aspects:
(1)
Immediate response linkage of origin translation to
viewpoint translation.
(2)
A single translation operation is applied to the scene
for each response.
(3)
It applies to the viewing, or graphics, end of the simu-
lation pipeline.
The following categorises the above against other oating
origin methods implementations. Sections 4 and 5 measure
and compare compare the implementations.
Review of floating origin implementations
In the past decade, there have been many references to the
use of “oating origin” in forums and other documentation.
A number of developer implementations of oating origin
have been described and some have published actual code
[
33
][
26
][
8
]. The published code makes the method, or algo-
rithm, clear, because each operation required by the algo-
rithm has to be specied unambiguously for it to execute
correctly. It is more common to nd pseudo code or descrip-
tions of coded methods, e.g. Frasson et. al. [
1
] describe their
method for geospatial terrain: “We implemented a simple
origin oset algorithm ..., where the camera’s eye
peye
is
always under a certain distance threshold dmax from the
world origin (0, 0, 0).” ... “the current camera position is sub-
tracted from the oset, then the camera is translated again
Figure 4: Example scene hierarchy is shown on the left panel
and comprised of 4 types of elements: Camera (represents
the player’s viewpoint), lights to make the scene visible, an
object representing the player and a set of other objects. As
noted, in Unity, each object has a Transform matrix. When
objects are arranged in a hierarchy, as above, the Transform
of parent objects also applies to children objects. In this case,
all objects except player and camera are placed under the
root node.
to origin. The oset value is used to build the model trans-
formation matrix of each object, eectively translating the
world objects towards the new origin.” Mahdavi et. al.[
2
] are
more brief : “In the case of jittering, one can render objects
using relative—rather than absolute — coordinates.... In such
references, it can be dicult to infer the exact algorithm.
Another case used a transition-to-viewpoint based ap-
proach, not analysed in this paper, that moves the origin
to view locations of interest:[
40
] “...dening an origin for
the viewer and every relative object is then translated based
on that local origin. Therefore, when viewing the buoy in
Northern Europe, the origin would be based on the viewer,
not the origin of the earth”.
Although oating origin is becoming widely adopted as
the general solution to jitter, there are dierences in imple-
mentations. The literature review did not nd any empirical
performance or quality analysis of these implementations.
This paper uses both quantitative and qualitative compar-
isons of the eciency and quality of two categories of oat-
ing origin approaches: CFO, which keeps the viewpoint at
the origin and moves the whole scene in one operation, and
Periodic Object Shifting (POS), which moves every object
individually whenever the viewpoint reaches threshold dis-
tance from the origin.
The online published information about the algorithms
is reviewed here. The essential algorithms of some methods
have been inferred from available documentation and corre-
spondence has been initiated for clarication. Approaches
fall into one of the following categories:
Healing Cracks in Cyberspace OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
(1)
Move the origin continuously (i.e. in lock-step with
navigation input).[37][39][30][17][47][3]
(2)
Move origin after navigating a certain threshold dis-
tance: POS method. [
1
][
28
][
33
][
12
][
23
][
26
][
8
][
32
] [
7
]
[24] [11][3]
(3)
Unclear. Some form of origin shift is referred to, how-
ever, documents unclear or yet to verify if the origin
is moved continuously with navigation or in steps.
There are also dierent methods for implementing the origin
move:
(1)
Move every object in the scene in reverse.[
33
][
12
][
23
]
[26][8][32][7][5][47][25][3]
(2)
Move entire scene in reverse.[
30
][
36
][
37
][
38
] [
39
][
37
]
[21][3]
(3)
Unclear. Documents unclear or yet to verify if the en-
tire scene is moved in one step or each object is moved.
An example of an implementation that needs to be claried
is HDRP[
18
] used in the Unity3D game engine. Documenta-
tion on HDRP is quite detailed but does not explicitly specify
if it is a oating origin solution, if it moves every object, or
if it moves the whole scene, each time there is a navigation
change or uses an oset. Specically: the statement: “HDRP
uses camera relative rendering. This means that there is a
good rendering precision even far away from the origin of
the world.” is incorrect because all rendering is camera rel-
ative and, as shown in Figure 2, it does not prevent poorer
accuracy and jitter. In a unity forum, a moderator: Cummings
[
8
], provides more information: “HDRP is camera-relative
rendering, so the camera remains at 0,0,0 at all times.” then
implies that it is not at (0,0,0) all the time: “This allows you
to utilise ECS to shift everything periodically.
In contrast, a Unity method with code published in 2010[
33
],
updated in 2018, is clear to follow. This implementation, de-
scribed in the next section, has been persistently referred
to over the last decade[
12
][
26
][
8
][
23
][
32
][
7
] [
5
]. In brief, it
uses the periodic threshold approach and translates each
object in reverse.
Algorithms for navigation and moving the view
The following algorithms in Figures 5 and 6 are available
online. They are presented here in simplied Unity script
pseudo code for easier understanding.
Unity objects have a Transform matrix which is used for
translating, rotating and scaling the object geometry. The
implementations based on the 2010 article [
33
] have a part
in common where, after a threshold distance is reached, the
reverse translation is applied to each object Transform when
performing the oating origin relative move. The simplied
pseudo code for this common part is given in Figure 5.
The rst part of the code tests if the viewpoint has moved
more than a certain threshold distance from the origin and,
if so, execute several loops. The rst loop translates each
object in reverse, closer to the origin. In doing so, there is
a complication where relative position of objects changes
with respect to that of xed viewpoints and other non object
features, such as invisible barriers with collision physics
attached. Therefore, there are additional loops for everything
else that needs to be restored to the same relative position
within the scene.
Note that there is also a special case that may need addi-
tional processing for either method: meshes that are so large
that their vertex coordinates are large enough to be sensitive
to jitter. When such meshes are moved as a single object, or
rendered in close proximity to other objects, jitter eects on
the mesh can occur. In such cases either the coordinates of
the mesh must be transformed, not the whole mesh as an
object; or the mesh must be subdivided into smaller pieces
with smaller range of vertex coordinates. Figure 5 shows the
i f ( v i e w p o i n t i s mo re th a n a t h r e s h o l d
d i s t a n c e f r om t h e o r i g i n )
{
f o r e a c h ( o b j e c t t r a n s f o r m ) {
a pp l y r e v e rs e t r a n s l a t i o n t o o b j ec t
transform
}
f o r e a c h ( v i e w po i n t ) {
a pp l y r e v e rs e t r a n s l a t i o n t o v i ew po i n t
transform
}
f o r e a c h ( u n a t t a c h e d c o l l i d e r ) {
a pp l y r e v e rs e t r a n s l a t i o n t o c o l l i d e r
transform
}
}
Figure 5: Simplied pseudo code of POS algorithm[33].
simplied Unity pseudo code of the commonly referenced
and repurposed object shift algorithm in the Unity wiki[
33
].
When the player navigates past a threshold distance from
the origin, the objects are translated by the negation of the
current position and then the current position is reset to
(0,0,0). The Unity forum version used a distance of 100 units.
Pahunov[
26
] [
27
] recommended: “Set the Shift threshold to
the oset step, so that the camera will not exceed the dou-
ble of this distance (for threshold of 4000 maximum camera
position is 8000 on any axis)”. Bowles[
5
] used a threshold of
16384.0.
Figure 6 shows simplied pseudo Unity code for the CFO
algorithm in the online ebook: A Simple Floating Origin[
35
].
A version of this code was used for the CFO test program
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
used to make measurements for this paper. In this algorithm,
the whole scene is moved in a single translation operation
as shown in Figure 6.
i f ( t h e r e w as a n a v i g a t i o n i n p u t c h an g e )
{
t r a n s l a t e t he s c en e i n r e v e rs e w it h a
s i n gl e t r a n l s l a t i o n o p er a t io n
}
Figure 6: The simplied pseudo code for a CFO algorithm.
Algorithm analysis. It is evident from the listings in Figure 5,
that the rst loop in the periodic shift algorithm translates
every object every each time it is executed. The execution
time is therefore proportional to the number of objects in
the scene. As the execution time increases (e.g. with a larger
number of objects), the frame rate[
42
], a common perfor-
mance measure, will reduce. However, it is not performed
often: only when the threshold distance is reached.
In contrast, the CFO algorithm of Figure 6 has a single
translation operation per navigation change and therefore
has a constant execution time, no matter many objects are in
the scene, but is executed with every player move, e.g. with
mouse or keyboard.
The literature review has shown that the original intent
behind oating origin was the continuous kind: the CFO
method. However, over more than a decade, oating origin
has been interpreted by some developers [
12
][
26
][
8
][
23
][
32
]
[
7
] [
5
] to mean that objects must be shifted individually,
as typied by the POS algorithm above. It appears the idea
of moving the entire Universe was not often translated di-
rectly into code. The following sections demonstrate that
this interpretation and resulting implementations have an
unnecessary negative impact on applications.
4 PERFORMANCE MEASUREMENTS
The Unity game proler was used to obtain visual measures
of performance dierences. A quantitative comparison was
then performed to measure frame rates using a frame rate
Heads Up Display (HUD) created using guidance from the
tutorial by Jasper Flick[
10
]. The meter displays a running
average Frames Per Second (FPS) as well as highest and
lowest values.
In order to directly compare the execution cost of both
methods, the threshold distance test of the POS method was
changed to use the same navigation change input test of
the CFO algorithm. This setting eliminated any dierence
in navigation response because, without an identical trigger
for executing both methods, meaningful average frame rate
comparisons could not be made. The only dierence between
the two implementations was therefore the cost of executing
each time input change was detected. Consequently, this
special test form of the POS method is referred to as Contin-
uous Object Shift (COS) for the purpose of this performance
comparison.
A large array of 10,000 of particle objects was used in both
tests. Only one loop of the Figure 5 algorithm was required in
the continuous object shift test: as there were 10,000 objects
it was not necessary to add loops for a small number of
viewpoints or colliders. The particle test was sucient to
produce a measurable dierence between the continuous
object shift and CFO algorithms.
The test platform was a 2015 13inch Macbook Pro, with a
Core i5 2.9GHz processor and Intel Iris Graphics 6100 1536
MB. The Unity version was 2018.3.0f2. A small game was
built with a simple scene and the 10,000 particle objects. The
same scene was used in each test, the only dierence being
the Script containing the viewpoint navigation algorithm
because the CFO and COS methods were written as game
scripts.
The CFO and COS tests were run in full screen mode at a
resolution of 1024
×
768 with no other applications running.
Each test was performed with only a few rectangular shapes
visible to prevent rendering load from dominating measure-
ments. The measurement metric was the proportion of script
execution time versus execution time on other functions
such as rendering, physics and memory management.
During each test run, screen snapshots were taken, while
constantly pressing one of the keyboard navigation keys.
The average FPS values from the snapshots were then tab-
ulated and averaged. In addition, a snapshot of the game
performance prole, using the Unity inbuilt proler, was
taken after each run. In the proler images, an example of
which is shown in Figure 7, the blue colour represents script
execution time (i.e. for executing any operation, including
movement of objects), green is for for rendering and orange
for physics calculations.
Results
Figure 8 shows the prole of the game running CFO. Com-
paring Figure 7 with Figure 8, it can be seen that the blue
script execution timings are much smaller for CFO than the
object shifting algorithm, indicating it uses less computation
resources.
Table 1 shows the results of frame rate measurements for
the COS and CFO methods.
Figure 9 Illustrates the game scene with particles (green
boxes) and some scene objects. Performance measures were
not taken with these particles in view because, on the test
platform, the rendering of so many objects in view takes
up such a large proportion of execution time that the script
execution time would barely be visible. Therefore, metrics
Healing Cracks in Cyberspace OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
Figure 7: Performance prole for version of game using con-
tinuous object shift oating origin navigation. This gure
shows the proler performance statistics. As can be seen
from this image, the script execution time (Primarily due
to movement of each object), coloured blue, dominates.
Figure 8: Performance prole for version of game using CFO
navigation. This gure shows the proler performance sta-
tistics. As can be seen from this image, the rendering execu-
tion time, in green, dominates, and the blue script execution
time is insignicant.
were taken with only minimal geometry in view (Figure 10).
Figure 10 illustrates the game scene without particles and
most objects behind the view and only a wall and oor in
sight. The FPS meter, overlaid at the top left, shows three
measures in frames per second: highest frame rate at the very
top, average frame rate underneath and lowest frame rate
at the bottom. Player interaction during the measurements
was via keyboard navigation input to move the view around
the scene. An average frame rate of 47 FPS was measured
Table 1: Average Frames Per Second (FPS) measurements
Count COS CFO
1 45 55
2 47 56
3 48 55
4 43 53
5 39 50
6 40 52
7 42 54
8 48 54
9 52 53
10 38 43
11 43 58
12 46 57
13 49 55
14 50 56
15 58 56
16 57 48
17 53 51
Average 47 53
Figure 9: Game view showing particle objects used in the
testing. If the tests were performed with these objects in
view, the execution performance would have been domi-
nated by the execution time required to render these par-
ticles, and the relative size of the oating origin execution
time would not be easy to discern.
for the COS version of the periodic shift approach compared
to 53 FPS for the CFO method.
Analysis of results
Performance. During each run, screen snapshots were taken
to capture the displayed frame rates. Over 15 snapshots of
the screen were taken for each method and the average FPS
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
Figure 10: Image from the CFO test game showing only a few
visible objects. This reduces the relative impact of rendering
on performance measures. On the test laptop, additional ob-
jects quickly increase the proportion of processing time re-
quired for rendering to the extent that the rendering time
would swamp the smaller time taken to execute scripts.
reading tabulated as illustrated in Table 1. The left column
of the table is the snapshot count. The next column shows
average FPS for COS and the right column the average FPS
for CFO.
As expected, the algorithm analysis showed the execution
time of periodic shift increases with the number of scene
objects. The result is supported by the greater script execu-
tion time of the shift method shown in blue in the Figure
7 proles and the lower average frame rate (FPS) measure.
Therefore, in terms of execution speed, CFO is the best per-
forming implementation of oating origin. Similar results
showing no measurable performance overhead from CFO,
and some improvements, were reported in [
39
], e.g. on page
189: “This simple world transform method has virtually no
performance overhead: it adds only one transform to the
transformation hierarchy and there is no dierence in frame
rate reported by the BS Contact web3D Browser.
As noted earlier, the periodic object shift test implemen-
tation was made to have the same input response as the
CFO implementation in order to measure the relative cost
of moving every object. However, the POS method was not
designed to be used this way: the threshold is normally set
to a much larger value, e.g. Pahunov recommends a value
of 4000 [
26
][
27
]. By using a large threshold value, the cost
of shifting scene objects is only incurred at brief moments
over hundreds, or thousands of frames, thus bringing the
performance close to that of CFO. Therefore, despite being
slower and a little more complex, the periodic approach can
be tuned to execute with a good average frame rate almost
as fast as CFO.
In addition, in a situation where a large number of ob-
jects are being occluded, cracks from jitter that open up in
foreground objects will cause the background objects to be
visible to the renderer, resulting in lower performance as
more background objects need to be processed. Measure-
ments of this eect is left for later research.
Apart from dierences in performance, there are three
disadvantages of the periodic method:
occasional discontinuities (hiccups/icker/stutter) in
the frame rate,
greater complexity,
poorer quality.
Occasional discontinuities. Although periodic shift with nor-
mal threshold can be made to perform very close to CFO
in the tests modelled here, there is anecdotal evidence on
forums that it suers from discontinuities, e.g. a icker or
jump in motion [
31
] [
20
] [
23
][
16
] and other overheads or
complications. In an online forum, Kahyaoğlu[
16
], in refer-
ring to a use of the 2010 oating origin Unity script says:
“if I’m not mistaken, it’s fetching everything in one frame
and will cause a huge freeze if your world is big & popu-
lated.” to which NinjaDanz3r2017 replies : “Correct, it’s not
terribly optimised for a large number of objects but it works
decently.
Other issues and overheads with Unity camera “relative
rendering” were referred to by “matias”[
20
] but they will
not be discussed as they may have been addressed in later
versions.
Greater complexity. The POS solution requires more code: a
number of loops compared to the single step transform of
CFO. The main disadvantage stemming from its object trans-
form loop is sensitivity to data size. Benger and Dobler[
4
]
highlight this issue with their big data application where
their oating origin implementation performance was a size
sensitive solution.
In contrast, the single step CFO transform is invariant to
data size and more exible because simpler code lends itself
to Graphics Processing Unity (GPU) software or even hard-
ware implementation. For any data coordinates (vertices) to
be processed by the GPU, the total transformation matrix
can be calculated, with the oating origin reverse transform
incorporated a priori . In an online forum, "pris"[
29
] refers
to using precisely this a priori transform approach to their
GPU algorithm: “Using double precision to calculate the nal
transform matrix and then sending it to the shader to trans-
form a vertex that’s close to the origin loses less precision
compared to calculating the nal transform matrix on the
GPU.
Healing Cracks in Cyberspace OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
Further evidence that CFO is supportable on GPU, using a
single a priori matrix multiplication step, can be found. Red-
way3D documentation[
31
] states: “matrix data uploaded on
the GPU will have been calculated as accurately as possible,
BEFORE being clamped to simple precision oating point
value for the vertex programs.” GurBu Technologies[
34
] of-
fer a “GPU instancer” that has “Support for Floating Origin
handling.
Poorer quality. Quality degradation, sensitive to the size of
threshold (distance from origin) has been explained and il-
lustrated in section 2 and detailed evidence was compre-
hensively covered in [
39
]. The next section quanties this
aspect and oers objective measures of the quality dierence
between CFO and POS.
5 NEW ERROR AND QUALITY METRICS
Section 2 described oating point resolution based jitter and
demonstrated the eects on rendering. The evidence, illus-
trated in Figure 2, is qualitative: the eects on rendering
quality are visually obvious but not a numerical measure. A
way to quantify the resolution of 3D oating point space and
the resulting jitter eects was provided in [
39
], page 195. The
formula is expressed in terms of the minimum error for a
oating point number for a given precision [
43
], the machine
epsilon:
ϵm
. For the purpose of this paper, you can think of
machine epsilon as the size of the smallest gap between one
representable oating point coordinate variable and the next,
i.e. it is the highest 1D resolution of a oating point variable,
for a given oating point precision, attainable between 0 and
1.
The 3D positional resolution formula of Thorne is a geo-
metric equation that takes into account three dimensions and
calculates the worst case gap between two coordinates in 3D
space. It quanties the variance of resolution with distance
from the origin and thus gives a base estimate of the degree
of jitter inherent in the vicinity of any location within 3D
space itself. The geometric formula is more complicated than
required for this paper and can be approximated to:
epsilon er r or ,or r esolut ion =3.4×ϵm×distance
This new formula gives us a simple heuristic scale, the
positional resolution scale, or Rez scale for brevity, with which
we can measure the absolute resolution of 3D space at any
viewpoint locality. Furthermore, the ratio of resolution at
distance
d
to the resolution at the origin gives a simple com-
parative rule-of-thumb:
The r atio o f resolution at dist ance d f rom the oriдin
compared to resolution at the oriдin =
3.4×ϵm×d/(3.4×ϵm)=d
i.e. the gaps between representable coordinates are d times
larger.
The distance ratio and the Rez scale are objective measures,
unlike the arbitrary guidance from the Google developer
documentation[
11
] (relating to the Unity POS method): “The
optimal way to use this method is to call it just before the
gameplay moves too far from the origin. You can determine
how far is far enough through experimentation.” Instead of
using such a trial and error rule for determining a satisfactory
quality, we can now quantitatively compare the estimated
quality dierence between CFO and POS, at a given distance
from the origin. Thus, the quality of positional applications,
in general, based on their underlying algorithms, can also be
measured by these tools.
For example, for a POS algorithm with a threshold of 4000,
on the Rez scale rendering at that distance uses coordinates
with a spatial resolution that is 4000 times larger than it
would under the CFO algorithm and the inherent jitter would
be at least 4000 times greater. Therefore, the CFO design can
lead to at least three orders of magnitude better quality.
It may be a surprise to the reader that the quality factors
of methods dier so much when qualitative measures for
appearance of images, such as those in Figure 2, do not seem
so dierent until larger distances, e.g. 90,000 are reached.
This is because some quality degradation is not always visi-
ble. Scientic and engineering calculations sensitive to error
would benet more from the CFO algorithm’s minimisation
of positional error.
The last mile to zero maers most. An important observation
not evident from the Rez scale formula is that the delity
and quality in calculations on a given span of space, within
a larger space, improves at an increasing rate as the distance
from the origin is reduced. The full version of the formula
in [
39
] reveals that resolution changes only at power of
two boundaries, and consequently, as the distance from the
origin is reduced, resolution across any given span of space
increases exponentially.
To demonstrate, consider a span of 31 from 32 to 63. It
will have no change in resolution across the span: resolution
is a constant 32
×ϵm
. For the same span of 31 from 0 to 31,
starting from 0, the resolution gaps increase by exponents of
2: 2
1
at 2, then 2
2
at 4, 2
3
at 8 and 2
4
at 16, i.e. by 16 times from
0 to 31. In other words, if the distance from origin is reduced
from 63 to 32, there is no improvement in resolution. But
when it is reduced from 31 to 0 resolution increases by up
to 16 times. On average, as the distance to the origin closes,
the resolution within a xed span increases exponentially
until it reaches the optimal value of ϵmat 0.
The POS references in this paper document thresholds
between 100 and 8000. Any application allowing navigation,
interaction in a region 100 from the origin has lost up to 64
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
times the resolution available at the origin. In a region 8000
from the origin this increases up to 4096 times. Therefore,
it is important to recognise both the orders of magnitude
resolution improvement of closing the last mile to zero and
that the change for a given span is exponential, not linear.
This is something to be mindful of when designing applica-
tions demanding the highest accuracy attainable in a locality
within a larger space, such as: military area of operations, or-
dinance simulation and guidance, terrestrial and space ight
simulation, high accuracy modelling, and remote surgery.
6 CONCLUSION
Cracks in cyberspace, born of old analogue navigation meth-
ods, lead to jitter that negatively impacts applications. The
Floating origin technique, has been used to solve funda-
mental accuracy issues like jitter across a wide range of
applications, including games [
26
][
8
][
23
][
32
][
7
] [
5
] [
18
], big
data[
4
], space and ight simulation [
22
][
12
][
15
], geospatial
[
6
][
30
][
1
] [
2
][
40
] [
9
][
28
][
14
]. The approach has stood the
test of time, in formal research and informal development
communities, moving from theoretical to practical value.
Therefore, any improvements on the way in which oating
origin is implemented will only increase its value.
Two forms of oating origin implementation were com-
pared for performance, complexity and quality of rendering.
Qualitative and quantitative measures, including the Rez
scale, were used to compare the oating origin implementa-
tion designs. The results show that the main drawback of the
periodic origin shift implementation is that jitter can mani-
fest in proportion to the threshold size because it allows view
navigation to travel relative to the origin. Its performance is
also sensitive to data size. In contrast, the continuous oat-
ing origin (CFO) technique’s most signicant advantages are
greater quality of rendering and the performance is invari-
ant to data size. The method also has the benet of reduced
complexity.
Two simple analytical tools for developers have been pre-
sented. Developers did not have a suitable tool to determine
the resolution their application needs and what jitter may
result from it. Consequently, design of algorithms has been
by trial and error, causing variable and unpredictable quality.
The two objective measures, the Rez scale and the distance ra-
tio, will allow designers and developers to predict the ecacy
of their jitter mitigation method by predicting resolution for
a given distance from the origin. This means, for example,
those using the periodic shift method can calculate a thresh-
old size to suit their needs.
A signicant consideration for application design was
highlighted: as the distance from the origin is reduced, the
resolution within any xed span of space increases exponen-
tially, reducing the base positional in exponential proportion.
This study makes the following best practice recommen-
dations for positional applications:
For a given precision, dene the minimum accuracy
required for observations.
Design application pipeline with optimisation of accu-
racy and other quality measures in mind.
Use objective measures to estimate and verify accuracy
and performance.
If observational space is to be a continuous window
into the greater world space and optimal accuracy and
quality is desired, use of the continuous oating origin
technique.
Close the last mile to zero for the greatest benet in
quality and error minimisation.
The last point should be of interest to scientists and en-
gineers working with equations highly sensitive to error
because the CFO method will optimally minimise error from
positional jitter. Finally, although the oating origin naviga-
tion interaction technique has been used to explore solutions
to jitter, prior work provides the evidential basis for extend-
ing the ndings of this study to other forms of interaction
and non rendering calculation, e.g. physics, where positional
computation occurs.
7 FURTHER RESEARCH
Benger has indicated[
3
] that he applies all approaches re-
viewed here within the implementation of the VISH soft-
ware platform [
41
]. Further research is required to determine
the basis for choosing one approach over another, if it was
mandatory or simply preferential.
A new study that would benet the eld would be to
measure the performance dierence when objects that would
normally be occluded from rendering are made visible solely
due to gaps opening up between foreground objects.
Furthermore, there are a number of references to CFO
not being implemented through a scene transform method
such as described here. For example, Zdarsky[
47
] cited better
performance for a continuous origin centric method but
worse performance when using the transform scene node
method. These and similar cases need to be reviewed and
assessed empirically.
Although there are already more complex applications
than the test programs used here, which exploit CFO to some
limited extent, no documented controlled validation of these
systems against measures such as performance or quality has
been found. More complex software test programs should
be developed to expand on the measurements above. These
tests should include higher precision stage, with step down
in precision, tiled based maps, very large scales (e.g galaxy).
Healing Cracks in Cyberspace OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia
REFERENCES
[1]
Tadeu Pozzer Alex Frasson, Tiago EngelCesar. 2018. Ecient screen-
space rendering of vector features on virtual terrains. In ACM SIG-
GRAPH Symposium on Interactive 3D Graphics and Games. Montreal,
Quebec, Canada. https://doi.org/DOI:10.1145/3190834.3190851
[2]
Faramarz Samavatia Ali Mahdavi-Amiria, Troy Aldersona. 2015. Sur-
vey of Digital Earth. Computers and Graphics 53 (2015), 1–23. https:
//doi.org/10.1016/j.cag.2015.08.005
[3] Werner Benger. 2019. Private correspondence.
[4]
Werner Benger and Wolfgang Dobler. 2017. Massive Geometric Algebra:
Visions for C++ Implementations of Geometric Algebra to Scale into the
Big Data Era. Springer International Publishing. https://doi.org/DOI:
10.1007/s00006-017- 0780-4 resolve at: https://hdl.handle.net.
[5]
Huw Bowles. 2018. Ocean renderer code. Retrieved 11 May 2019 from
https://github.com/huwb/crest-oceanrender
[6]
Jörg Blankenbach Christoph Blut, Timothy Blut. 2017. CityGML goes
mobile: application of large 3D CityGML models on smartphones.
International Journal of Digital Earth 12, Article 1 (Nov 2017), 25-
42 pages. https://doi.org/DOI:10.1080/17538947.2017.1404150
[7]
Cliftonm. 2016. What about physics happening far from the (oating)
origin ? Retrieved 11 May 2019 from https://forum.unity.com/threads/
oating-origin- doesnt-work-on-the-y- axis.390998/ Mar 11 2016.
[8]
Robert Cummings. 2018. Forum comment on subject: Ecs oating
origin? Retrieved 11 May 2019 from https://forum.unity.com/threads/
ecs-oating- origin.546472 aka hippocoder, Aug 22, 2018.
[9]
Guofeng Cao Feixiong Luo, Ershun Zhong. 2011. VGIS-AntiJitter: An
eective framework for solving jitter problems in virtual geographic
information systems. International Journal of Digital Earth 6, Article 1
(2011), 23 pages. https://doi.org/DOI:10.1080/17538947.2011.601766
Also: Ricardo Delgado Tellez, Pengqi Gao.
[10]
Jasper Flick. 2018. Frames Per Second. Retrieved 14 May 2019
from https://catlikecoding.com/unity/tutorials/frames-per- second/ Es-
timated date: No publishing date given.
[11]
Google. 2019. Floating Origin. Retrieved 20 May 2019
from https://developers.google.com/maps/documentation/gaming/
move_oating_origin last edited on 14 April 2019, at 15:32 (UTC).
[12]
goonsweat. 2017. Floating Point wiki script Implementation 2017. Re-
trieved 1 May 2019 from https://answers.unity.com/questions/1408174/
oating-point- wiki-script-implementation- 2017.html Sep 17, 2017.
[13]
Matt Groening and David X. Cohen. 2000. A Clone of my Own. Re-
trieved 2 June 2019 from https://theinfosphere.org/A_Clone_of_My_
Own Seen on Australian television circa 2007, Originally aired on 9
April, 2000, on Fox, quote by Cubert Farnsworth, in A Clone of my
Own, Futurama, Season 2 Episode 5 (Act III).
[14]
Analytical Graphcis Inc. 2019. AGI STK Components for Java. Re-
trieved 1 May 2019 from http://help.agi.com/AGIComponentsJava/
html/BlogPrecisionsPrecision.htm/ Documentation on AGI STK com-
ponents for Java.
[15]
ingfors. 2012. Best World Scale? Retrieved 22 May
2019 from https://forums.ogre3d.org/viewtopic.php?f=2&t=68604&
p=449325&hilit=oating+origin#p449325
[16]
Baran Kahyaoglu. 2017. Gitlab comment on implementing oating
origin. Retrieved 20 May 2019 from https://github.com/mapbox/
mapbox-unity- sdk/issues/141 brnkhy = Kahyaoglu.
[17]
Baran Kahyaoglu. 2019. ZoomableMap. Private correspondence on
ZoomableMap demo.
[18]
Sebastien Lagarde. 2018. Unity High Denition Render Pipeline.
Retrieved 1 May 2019 from https://blogs.unity3d.com/2018/03/16/
the-high- denition-render- pipeline-focused-on-visual- quality/
[19]
mapbox. 2019. Mapbox. Retrieved 4 jun 2019 from https://www.
mapbox.com/ Maps SDK for smarphones.
[20]
matias. 2013. New way of handling camera relative rendering. Re-
trieved 20 May 2019 from https://www.yosoygames.com.ar/wp/2013/
10/new-way-of-handling- camera-relative-rendering/ Originally Oc-
tober 20, 2013, Ogre forums.
[21]
Alan Hudson ... Michael McCann, Richard Puk. 2009. Proposed
Enhancements to the X3D Geospatial Component. In 14th Interna-
tional Conference on 3D Web Technology. Darmstadt, Germany. https:
//doi.org/DOI:10.1145/1559764.1559788 Also: Rex Melton, Don Brutz-
man.
[22]
mononomonom. 2018. Space Graphics Toolkit. Retrieved 24 May 2019
from https://forum.unity.com/threads/space-graphics-toolkit.147954/
page-39
[23]
NinjaDanz3r. 2017. Implement oating origin. Retrieved 20 May 2019
from https://github.com/mapbox/mapbox-unity-sdk/issues/141
[24]
Soloman Northrop. 2018. Tiled map demo LODs, oating ori-
gin. Retrieved 8 Jun 2019 from https://www.youtube.com/watch?v=
qDkBTsLdhps
[25]
Soloman Northrop. 2019. Tiled map demo LODs. Private correspon-
dence.
[26]
Denis Pahunov. 2018. Settings for MapMagic World Generator. Re-
trieved 18 May 2019 from https://gitlab.com/denispahunov/mapmagic/
wikis/Settings
[27]
Denis Pahunov. 2019. Voxeland project settings. Retrieved 18 May
2019 from https://gitlab.com/denispahunov/voxeland/wikis/general_
settings
[28]
Kevin Ring Patrick Cozzi. 2011. 3D engine design for
virtual globes. CRC Press, Taylor and Francis Group.
https://www.crcpress.com/3D-Engine-Design- for-Virtual-Globes/
Cozzi-Ring/p/book/9781568817118
[29]
Pris. 2012. Maintain performance and precision with
a large vertex buer? Retrieved 20 May 2019
from https://gamedev.stackexchange.com/questions/32951/
maintain-performance- and-precision-with- a-large- vertex-buer
[30]
Arjan Kuijper Ralf Gutbell, Lars Pandikow. 2018. Web-Based Visual-
ization Component for Geo-Information. Springer. Conference paper
Human Interface and the Management of Information. Interaction,
Visualization, and Analytics, 2018, pp 23 - 35.
[31]
Redway3D. 2019. Retrieved 10 May 2019 from http://www.downloads.
redway3d.com/downloads/public/documentation/index.html Red-
way3D software package.
[32]
sebeisdrache. 2015. Floating Origin and Multiplayer. Re-
trieved 11 May 2019 from https://answers.unity.com/questions/882826/
oating-origin- and-multiplayer.html
[33]
Peter Stirling. 2010. Floating Origin. Retrieved 1 May 2019, from
http://wiki.unity3d.com/index.php/Floating_Origin
[34]
GurBu Technologies. 2018. Editor Extensions/Utilities. Retrieved
24 May 2019 from https://www.gameassetdeals.com/asset/117566/
gpu-instancer
[35]
Chris Thorne. 2018. A Simple Floating Origin. Retrieved 11 May 2019
from https://www.simpleoatingorigin.com Online ebook.
[36]
Christopher G. Thorne. 2004. The Kata of web3D. In Conference:
ACM SIGGRAPH 2004 Web graphics. Los Angeles, California. https:
//doi.org/DOI:10.1145/1186194.1186215
[37]
Christopher G. Thorne. 2005. Using a Floating Origin to Improve
Fidelity and Performance of Large Distributed Virtual Worlds. In 4th
International Conference on Cyberworlds (CW 2005). Singapore. https:
//doi.org/DOI:10.1145/3190834.3190851
[38]
Christopher G. Thorne. 2006. Error Minimising Pipeline for Hi-Fidelity,
Scalable Geospatial my. In 5th International Conference on Cyberworlds
(CW 2006). Lausanne, Switzerland. https://doi.org/DOI:10.1109/CW.
2006.22.Source:DBLP
OZCHI’19, December 2–5, 2019, Fremantle, WA, Australia Chris Thorne
[39] Christopher G. Thorne. 2007. Origin-centric techniques for optimising
scalability and the delity of motion, interaction and rendering. Ph.D.
Dissertation. The University of Western Australia, Crawley, Western
Australia. https://doi.org/DOI:10.13140/RG.2.2.10421.32481
[40]
Dale R. Tourtelotte. 2010. X3D-Earth full globe coverage uti-
lizing multiple datasets. Master’s thesis. NAVAL POSTGRAD-
UATE SCHOOL, Monteray, California. https://doi.org/DOI:
10.13140/RG.2.2.10421.32481 Accession Number : ADA531611,
https://apps.dtic.mil/dtic/tr/fulltext/u2/a531611.pdf.
[41]
René Heinzl Werner Benger, Georg Ritter. 2007. The concepts of VISH.
??, Article 1 (April 2007). https://doi.org/DOI:10.1.1.453.859 Also:
Ricardo Delgado Tellez, Pengqi Gao.
[42]
Wikipedia.org. 2019. Frame rate. Retrieved 24 May 2019 from
https://en.wikipedia.org/wiki/Frame_rate
[43]
Wikipedia.org. 2019. Machine Epsilon. Retrieved 20 May 2019 from
https://en.wikipedia.org/wiki/Machine_epsilon
[44]
Wikipedia.org. 2019. Precision. Retrieved 12 Jun 2019 from https:
//en.wikipedia.org/wiki/Precision
[45]
Wikipedia.org. 2019. Rendering (computer graphics). Retrieved 18
Jun 2019 from https://en.wikipedia.org/wiki/Rendering_(computer_
graphics)
[46]
Wikipedia.org. 2019. Transformation matrix. Retrieved 22 May 2019
from https://en.wikipedia.org/wiki/Transformation_matrix
[47]
Joerg Zdarsky. 2019. Procedural universe and oating origin. Private
correspondence.
... Due to digital limitations, error is built into the floating point number representation [3] -in addition to any inaccuracies in input data. Consequently, game and simulation applications can develop noticeable error due to propagation in complex multivariate equations and increasing scale [4]. An equation for calculating this positional error, based on geometry and floating point representation, was originally published in a 2007 thesis [3] and presented as an approximation for 3D space in Healing Cracks in Cyberspace [4]. ...
... Consequently, game and simulation applications can develop noticeable error due to propagation in complex multivariate equations and increasing scale [4]. An equation for calculating this positional error, based on geometry and floating point representation, was originally published in a 2007 thesis [3] and presented as an approximation for 3D space in Healing Cracks in Cyberspace [4]. ...
... 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. ...
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.
... The concept of floating origin became popular and was implemented widely in game engines and other spatial industries. However, the method was later termed Continuous Floating Origin (CFO) to distinguish it from non-relative implementations [2] that are not optimal and fail to scale gracefully. ...
... CFO achieves navigation of digital spaces by keeping the virtual camera at the origin and moving objects around it. The relative motion appears the same as moving through a space but has the advantage of optimal fidelity and scalability [2,3,4,5]. ...
... In computer graphics, parent-child hierarchies form an inverted tree structure called a scenegraph. Figure 1 displays two panels of the Unity editor interface that is illustrated in Figure 2. "FOMainRoot" is the top level scenegraph node that is reverse-translated [2] by CFO. The right panel displays the translation value (position). ...
Technical Report
Full-text available
Origin-centric techniques are a class of solutions to a widespread problem in computation: positional jitter. This article introduces a new origin-centric technique, progressive relative spaces, designed to solve a particular form of positional error, distant relative jitter, that occurs when working with objects organised in a hierarchical spatial relationship spanning large distances. The new algorithm is designed to work with another origin-centric technique, continuous floating origin. The combined methods have been used to enable continuous virtual travel from Earth to Pluto with low precision variables and math.
... Improved accuracy is just the beginning of the optimisations available from origin-centering. A significant body of work has been devoted to the application of origin-centric ideas to computer graphics and simulation with particular emphasis on achieving optimal accuracy, rendering quality and scalability [2,6,9,10]. ...
... Rendering, a very complex operation, is also a position independent function. As has been shown [2,6,9] that relocating objects to zero before they are rendered produces consistently high quality results when compared to conventional approaches where objects are not relocated to Zero. ...
... Other areas of improvement have also been explored: performance, interaction, simplicity: reduction of code and space requirements [2,6]. A detailed analysis of equation simplicity and performance improvements that arise from floating origin was given in [3,4]. ...
Technical Report
Full-text available
Many functions based on positional parameters have a position independent aspect: there is no absolute place where the calculation must be done because the result depends only on the relative information between its parameters. Position independent functions can therefore be relocated and still produce the same theoretical result. One benefit of this idea is the potential for improved accuracy. A floating point number is more accurate the closer the value is to zero because the representation resolution increases inversely with value. It follows that floating point calculations are more accurate when the parameters are small. Therefore, as a position independent function is progressively moved towards Zero its computed result will be more and more accurate until optimal accuracy is reached.
... 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. ...
... Unity [6], for example, has a Lookat function for this purpose. The difference between origin-sifting methods and real floating origin was explained in Healing Cracks in Cyberspace [2]. ...
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.
... The maximum bounds or distance between any two points of the closure has also been referred to as the span [4]. ...
... 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. ...
... The idea of position independence, combined with an understanding of the limited nature of floating point representation, has been exploited to develop numerical optimisation advances in computer science such as an optimising simulation pipeline design [4], continuous floating origin [3], code reduction and performance improvement [1], increased rendering quality, and practically unlimited scaling [2,3,6]. ...
... The idea of position independence, combined with an understanding of the limited nature of floating point representation, has been exploited to develop numerical optimisation advances in computer science such as an optimising simulation pipeline design [4], continuous floating origin [3], code reduction and performance improvement [1], increased rendering quality, and practically unlimited scaling [2,3,6]. ...
Technical Report
Full-text available
The concept of position independence has lead to numerical optimisation advances in computer science, particularly for error reduction and improved scalability. The term was not simply and clearly defined in prior publications. We provide a concise definition. This and related articles are motivated by the desire to promulgate a better understanding of relative information concepts and their application to design and computation.
... In an origin-centric system, i.e. one that uses the Continuous Floating Origin [3] technique, the camera position is always (0, 0, 0) and the equation becomes: ...
Technical Report
Full-text available
Positional systems, such as games, need to calculate the distance between objects and the player camera for many different reasons. Examples are: sensing proximity to a position, object or actor; controlling visibility of objects; to trigger an action based on distance travelled; to make a prediction, such as dead-reckoning; or to perform a calculation, such as perspective foreshortening of a distant object. Such distance calculations may be performed thousands, or even millions of times a second. To meet the response requirements of an interactive system, it is therefore worth exploring methods that improve the performance of this fundamental calculation. This article compares the speed of conventional distance calculation to a faster method that exploits a feature of Continuous Floating Origin.
... Note that, for the purpose of disambiguation, these optimisations are not possible with origin/object-shifting methods [8,9] that are incorrectly named "floating origin". This limitation of shifting methods is in addition to those discussed in a comparison of key differences between object-shifting and CFO [5]. ...
Experiment Findings
Full-text available
An aspect of the rotation floating origin technique offers some unique opportunities for high-level optimisations within applications-in World space-that are normally only available at a low level stage of the graphics pipeline. The technique fixes the orientation of the virtual camera to screen-facing. This aspect can be exploited to utilise optimisations, such as Z-culling or depth-culling, and other 1-dimensional culling algorithms. The aim of this experiment was to measure the increase in performance from 1-dimensional World space culling of objects together with culling of spatially referenced calculations. The culling was applied to graphical billboard objects, representing trees, that were a distance away or behind the camera. Measurements were taken for a 1 million billboard forrest with 3 different types of culling.
... Note that, for the purpose of disambiguation, these optimisations are not possible with origin/object-shifting methods [8,9] that are incorrectly named "floating origin". This limitation of shifting methods is in addition to those discussed in a comparison of key differences between object-shifting and CFO [5]. ...
Experiment Findings
Full-text available
The technique of rotation floating origin fixes the orientation of the virtual camera to screen-facing. This aspect offers some unique opportunities for high-level optimisations within applications-in World space-that are normally only available a very low level within the graphics pipeline. One of these optimisations is referred to as Z-culling or depth-culling. The aim of this experiment was to measure the increase in performance from 1-dimensional Z-culling of spatially referenced calculations. World space Z-culling was applied to rotation calculations on graphical billboards representing trees in a virtual forrest. Measurements were compared no culling, inner loop culling and block culling of calculations.
... The experiment described a World layout where two towers were positioned over 55km from the starting point. The player was then moved to the distant towers using the Continuous Floating Origin method [3] which eliminated other forms of jitter that would obscure demonstration of the distant relative jitter. The experiment demonstrated the application of a positional refinement technique, Progressive Relative Spaces (PRS), to remove jitter from one of two towers positioned some distance away. ...
Experiment Findings
Full-text available
Positional jitter is a common source of error in positional computation. One form of positional jitter, distant relative jitter, is isolated in this experimented to better understand its behaviour and appearance during interactive movement. The aim is to enable developers to recognise the signature behaviour of this form of jitter, when other forms are not manifesting, and change design to mitigate its effects.
Conference Paper
Full-text available
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.
Thesis
Full-text available
This thesis examined the idea of position independence of equations together with the optimising power of centering calculations and positional objects at the origin. The combined centred position independent concept became a single organising principle for optimising the fidelity and scalability of simulation pipelines and also formed the basis for a new centred relative paradigm for computing.
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
http://rdcu.be/vdRh Geometric algebra (GA) is a promising approach to address interoperability bottlenecks that are particularly prominent in the big data era. Similar to how GA unites and simplifies otherwise distinct mathematical branches it may also help to unite software via common interfaces between otherwise distinct applications. The promising potential of GA would be best exhibited by the ability of seamless integration into existing, complex applications. To achieve this vision various constraints have to be considered. Particularly having C++ in focus, we discuss the “wish list” that an optimal C++ implementation should provide. We find that to cover the various constraints an hybrid approach benefiting from multiple programming paradigms, ranging from generic to object-oriented programming, will be needed. C++ is a very suitable platform providing all these capabilities and promising approaches like Generative Programming and Active Libraries provide technology highly desirable for universally promoting GA to an extensive range of application domains.
Article
Full-text available
Geometric algebra (GA) is a promising approach to address interoperability bottlenecks that are particularly prominent in the big data era. Similar to how GA unites and simplifies otherwise distinct mathematical branches it may also help to unite software via common interfaces between otherwise distinct applications. The promising potential of GA would be best exhibited by the ability of seamless integration into existing, complex applications. To achieve this vision various constraints have to be considered. Particularly having C++ in focus, we discuss the “wish list” that an optimal C++ implementation should provide. We find that to cover the various constraints an hybrid approach benefiting from multiple programming paradigms, ranging from generic to object-oriented programming, will be needed. C++ is a very suitable platform providing all these capabilities and promising approaches like Generative Programming and Active Libraries provide technology highly desirable for universally promoting GA to an extensive range of application domains.
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.
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.
Conference Paper
[Full text available at https://doi.org/10.1145/3190834.3190851] Rendering vector data on virtual terrains is a relevant issue as its applications range from virtual simulation to public administration. The expected level of visual quality and extents of virtual terrains demand efficient solutions. We propose a screen-space approach to render high-quality line and polygon vector data in real-time. A novel polygon rendering algorithm is proposed to address the limitations of current techniques. We present a flexible acceleration structure to accommodate the vector features and to enable efficient culling, user editing, and styling at runtime. The vector data is processed and provided for random access in the GPU, where the elements are adequately rendered in a deferred rendering pipeline using a modern temporal antialiasing. Results show that our approach provides increased visual quality and real-time performance for massive datasets.
Article
With the proposition of the Digital Earth (DE) concept, Virtual Geographic Information System (VGIS) has started to play the role of a Digital Earth prototype system. Many core problems involved in VGIS, such as out-of-core management and interactive rendering of very large scale terrain and image data, have been well studied in the past decades. However, the jitter problem, a common problem in VGIS that often causes annoying visual artefacts and deteriorates the output image quality, draws little attention. In this paper, after an intensive analysis of the jitter problem, a comprehensive framework is proposed to address such a problem while accounting for the characteristics of different data types in VGIS, such as terrain or ocean mesh data, vector data and 3-D model data. Specifically, this framework provides an improved dynamic local coordinate system (DLCS) method for terrain or ocean mesh data. For vector data, the framework provides a simple and effective multiple local coordinate systems (MLCS) method. The framework provides a MLCS method for 3-D model data making full use of the existing local coordinate system of the model. The advantages of the proposed methods over current approaches are analysed and highlighted through case studies involving large GIS datasets.