• Save
Structural organization and architecture of a virtual reality explorer
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Structural organization and architecture of a virtual reality explorer

on

  • 402 views

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 ...

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

Statistics

Views

Total Views
402
Views on SlideShare
363
Embed Views
39

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 39

http://www.linkedin.com 34
https://www.linkedin.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Structural organization and architecture of a virtual reality explorer Document Transcript

  • 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  Bachelors  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  users  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.