This paper talks about the structural organization and architecture of a Virtual Reality Explorer. It attempts to throw some light on the components and their functions of a VR Explorer and what issues should be kept in mind while making such an application. via @prchg

1.
Structural
organization
and
architecture
of
a
Virtual
Reality
Explorer
Prachi
Gupta,
Vinayak
Suley
Note:
This
is
a
technical
paper
I
wrote
with
a
friend
of
mine
during
our
second
year
of
Bachelor's
degree.
Authoring
this
paper
was
probably
the
most
fun
and
rewarding
learning
experience
of
my
life
and
hence
I
thought
it
deserves
a
place
in
my
published
content.
At
the
time
we
wrote
this,
all
this
was
original
work
and
all
the
ideas
mentioned
here
are
what
we
came
up
with
on
our
own
over
countless
discussions,
most
of
which
ended
up
in
our
discussing
or
dreaming
about
stuff
completely
irrelevant
to
the
project
at
hand.

2. Abstract:
This
paper
talks
about
the
structural
organization
and
architecture
of
a
Virtual
Reality
Explorer.
It
attempts
to
throw
some
light
on
the
components
and
their
functions
of
a
VR
Explorer
and
what
issues
should
be
kept
in
mind
while
making
such
an
application.
Virtual
Reality:
The
word
virtual
means,
being
in
effect
but
not
in
actual
fact.
Reality
is
something
of
or
relating
to
practical
or
everyday
concerns
or
activities.
Combining
these
two,
we
get
Virtual
Reality,
i.e.
something
of
practical
or
everyday
use
in
effect
but
not
in
actual
fact.
Virtual
Reality
Explorer:
The
Virtual
Reality
Explorer
is
a
visual
aid
for
exploring
a
possibly
remote
premise
using
a
computer
through
standard
input
devices
like
keyboard
and
mouse.
It
will
simulate
the
view
as
seen
by
a
person
actually
walking
through
the
premises.
The
application
will
have
the
capability
to
work
under
two
modes
-­‐
1.
The
tour
mode
The
Tour
mode
will
follow
a
predefined
route
through
the
entire
premises
giving
the
user
a
guided
tour
with
no
input
required
from
the
user's
side.
2.
The
search
mode

3. The
Search
mode
will
enable
a
user
to
search
the
best
possible
path
and/or
all
the
routes
to
a
place
on
the
premises
from
another
place
in
the
premises.
Building
the
Virtual
World:
In
order
to
view
any
building
in
3
dimensions
it
first
has
to
be
modeled
in
some
way.
This
can
be
done
in
various
ways.
All
the
vertex
locations
can
be
coded
into
the
program,
however
this
is
an
extremely
inefficient
way
of
making
a
virtual
world
and
the
idea
does
not
deserve
a
further
discussion.
One
of
the
other
approaches
is
to
dynamically
create
portions
of
the
virtual
world
in
a
sort
of
‘World
Creator
Tool
Kit’.
For
this
purpose
the
application
will
consist
of
an
easy
to
use
and
understand
interface
that
will
enable
a
user
to
create
her/his
own
worlds.
Once
the
modeling
of
the
world
has
been
done,
the
data
generated
by
the
‘World
Editor’
can
then
be
stored
in
a
file.
These
worlds
can
then
be
explored
in
any
of
the
previously
mentioned
ways
by
making
loading
these
files
into
the
viewing
application.
Files:
The
files
that
will
be
needed
to
store
all
the
data
needed
to
describe
a
world
are:
1. Mesh
Files:
Mesh
files
store
the
architectural
structures
like
pillars,
walls,
staircases,
etc
along
with
their
material
properties.
2. Texture
Files:
Image
files
needed
to
give
a
realistic
texture
to
the
objects
inside
the
virtual
world.
3. Furniture
Files:
Files
to
store
the
data
for
modeling
and
drawing
the
furniture
inside
the
rooms.
4. Lighting
Files:
File
containing
information
about
the
lighting
for
the
premises.
5. Node
File:
File
containing
details
of
the
strategic
locations,
turns
and
junctions
in
the
premises.
Portal
Rendering
and
Sectors:

4. To
view
the
world,
the
world
will
first
have
to
be
loaded
into
the
application
by
reading
from
the
data
files
and
then
generating
their
respective
data
structures.
At
this
point
of
time,
all
the
data
that
is
currently
loaded
will
reside
in
the
main
memory,
it
will
also
be
present
in
the
Rendering
list.
Thus,
with
the
increase
in
the
size
of
the
world,
there
will
be
a
significant
increase
in
the
required
memory
and
processing
power.
Only
a
small
part
of
the
world
will
be
visible
at
any
time,
but
a
lot
of
hidden
geometry
will
have
to
be
processed.
To
reduce
these
overheads,
we
divide
larger
worlds
into
smaller
regions
called
‘Sectors’.
Thus
the
geometry
for
the
entire
world
is
distributed
into
these
sectors.
Each
sector
has
its
own
mesh
file,
furniture,
lighting
file
and
textures.
However,
only
a
single
node
file
is
maintained
for
the
entire
world.
This
is
to
help
in
searching
locations
that
may
be
scattered
across
different
sectors.
Components
of
the
Virtual
Reality
Explorer
The
routine
repository:
This
is
a
collection
of
different
multipurpose
routines
which
can
be
used
for
input,
window
handling,
GUI
building
and
some
other
frequently
used
functions
for
mathematics
calculations
etc.
1. Input
Repository:

5. Input
routines
have
been
given
a
separate
paradigm
because
of
the
possibility
of
various
input
events
like
hovering,
dragging,
discrete
clicks,
key
press,
key
release,
differentiating
between
ASCII
keys
and
special
keys.
It
also
provides
flexibility
to
port
the
system
to
new
hardware
like
touch
screens
etc.
2. Window
Handling:
The
window
handling
routines
will
help
in
doing
important
tasks
like
window
creation
registration
of
the
window
handler,
obtaining
a
device
context,
establishing
a
rendering
context,
validating
the
pixel
format
etc.
Keeping
this
section
independent
helps
in
making
the
application
easily
portable
to
other
platforms.
3. GUI:
This
routine
repository
will
provide
classes
to
create
elementary
user
interface
elements
like
buttons,
radio
buttons,
check
boxes,
text
boxes,
combo-­‐boxes,
scroll
bars,
sliders,
selectors,
dialog
boxes
etc.
Keeping
this
section
independent
makes
it
easy
to
give
the
entire
interface
a
whole
new
look
with
the
minimum
necessary
modifications
as
well
as
implementing
further
optimizations.
4. Mathematics
and
other
elementary
routines
:
These
routines
will
do
tasks
like
calculating
normals,
dot
products,
cross
products,
angles
between
vectors,
distances,
lengths
etc.
5. Graphics
API
conversion
routines:
This
set
of
routines
is
needed
to
provide
ease
in
case
of
changing
the
low
level
graphics
API.
For
example,
we
could
use
OpenGL
or
Direct
3D
or
3DFX
etc.
This
module
will
provide
one
set
of
functions
for
use
within
the
application
and
will
interface
these
with
the
other
implementation’s
functions.
Editor
Interface:
This
provides
an
interface
using
the
routine
repositories,
to
help
in
the
creation
of
worlds.
It
assembles
the
primitives
available
for
use
in
its
toolkit
to
make
a
world
and
passes
on
the
map
to
the
“Input
Logic
Validator”.
Input
Logic
Validator:
This
component
validates
the
world
being
developed
by
the
world
editor.
It
prompts
the
user
in
cases
of
invalid
input
and
illogical
constructions.
It
finally
writes
all
the
data
to
mesh,
nodes,
furniture
and
lighting
files.
It
also
helps
in
associating
material
properties
and
textures
with
the
objects
of
the
world.

6. Files:
The
various
kinds
of
files
used
to
maintain
the
data.
This
area
is
accessed
by
the
loader
to
prepare
the
trees,
linked
lists
and
graphs
for
the
Render
list
and
the
Timing
and
Control
module.
Viewer
Interface:
The
interface
that
helps
the
user
to
choose
the
viewing
mode
and
take
in
other
details
like
source
and
destination
(if
required).
This
interface
passes
on
the
details
to
the
timing
and
logic
control
unit.
Timing
and
Logic:
This
module
is
the
brain
of
the
entire
system.
It
takes
variables
as
inputs
from
the
viewer
interface
and
based
upon
these
inputs
it
takes
decisions
such
as
which
world’s
node
file
to
load,
which
current
sector
in
to
be
rendered,
where
the
camera
has
to
be
placed,
how
fast
it
has
to
be
moved.
It
creates
a
graph
from
the
node
list
and
using
shortest
path
algorithms,
figures
out
what
is
the
best
way
to
reach
from
one
strategic
location
to
the
other.
It
can
also
be
used
to
control
rendering
options,
for
example,
we
may
not
want
the
furniture
to
be
displayed
or
we
might
want
to
disable
lighting
or
attenuation
etc.
Loader:
This
module
loads
the
appropriate
files
as
defined
by
the
timing
and
Logic
control.
It
opens
the
node
file,
makes
it
into
a
graph
and
passes
the
pointer
to
timing
and
control,
opens
the
mesh
file,
forms
an
appropriate
tree
and
passes
the
root
pointer
to
render
list,
opens
the
lighting
and
furniture
files
and
forms
the
appropriate
linked
list
and
passes
them
to
render
list.
Render
List:
It
is
the
collection
of
all
objects
to
be
rendered
which
may
be
architectural
structures,
lights,
furniture
and
textures.
It
receives
these
lists
from
the
loader.
Camera:
It
is
essentially
the
function
that
handles
the
viewing
transformations.
It
is
governed
by
the
timing
and
control
module.
Rendering:
The
rendering
core,
mostly
it
will
be
the
standard
rendering
done
by
OpenGL
but
it
can
be
custom
made
too.
Final
View:
The
simulation
as
seen
by
the
viewer.

7.
Viewer:
The
person
who
uses
the
virtual
reality
explorer
through
the
viewer
interface.