construction of an open geometry server for client server virtual environments
Download
Skip this Video
Download Presentation
Construction of an Open Geometry Server for Client-Server Virtual Environments

Loading in 2 Seconds...

play fullscreen
1 / 18

Construction of an Open Geometry Server for Client-Server Virtual Environments - PowerPoint PPT Presentation


  • 127 Views
  • Uploaded on

Construction of an Open Geometry Server for Client-Server Virtual Environments. Chris Faisstnauer, Werner Purgathofer Vienna University of Technology. Jean-Dominique Gascuel Imagis, Grenoble. Michael Gervautz Imagination, Vienna. Introduction.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Construction of an Open Geometry Server for Client-Server Virtual Environments' - umay


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
construction of an open geometry server for client server virtual environments

Construction of an Open Geometry Server for Client-Server Virtual Environments

Chris Faisstnauer,

Werner Purgathofer

Vienna University of Technology

Jean-Dominique Gascuel

Imagis, Grenoble

Michael Gervautz

Imagination, Vienna

introduction
Introduction
  • Client-server architecture to integrate of incompatible graphics systems/applications
  • Detailed explaination of construction process
    • Put together system based on known techniques
  • Case study - Provide help in construction of such systems
    • Categorization of clearly distinct default components
    • Provide insights about design decisions
    • Good relation between cost/performance concerning development and implementation)
  • "Implementation" talk/paper
the pavr project
The PAVR-project
  • European union project: 10 universities
  • Ease collaboration and exchange of know-how concerning virtual reality / animation
  • (Software-) “Platform for Animation and Virtual Reality”
  • Problem:
    • Incompatible systems (software/hardware)
    • Stand-alone applications
  • Goal:
    • Link (existing) applications into common environment
    • Little effort, minor code changes
approach
Approach
  • Existing systems
    • RING, NPSNET, DIVE, SPLINE, SPLINE,NETEFFECT, PARADISE, AVIARY,...
  • Client-server system
    • Common communication protocol
    • Clients replicate environment using own routines / data structures
    • Integration: translate data structures protocol  client
  • Components
    • Simple/generic protocol
    • Flexible parser (easy integration into clients)
    • Efficient server (geometric data / transmission service)
geometry server components 1 2
Geometry Server Components 1/2
  • Communication layer: provide network connections
    • Easy to integrate, small (Sockets, TCP/IP)
  • Communication protocol
    • Transmit geometry objects + commands modify properties
    • Easy to interpret for server / clients
  • Lexical parser / pre-determined callback functions
    • Defined headers, proprietary implementation server/clients
    • Modify protocol without changes in program code
  • Scene database:
    • Hierarchical scene graph (nodes describe objects)
    • History list (describe graph changes)
  • Client list:
geometry server components 2 2
Geometry Server Components 2/2
  • Flow control
  • Message filtering
  • Time management: online vs. offline mode
online vs offline mode
Online Vs. Offline Mode
  • Online mode:
    • "Real-Time" mode (typical for VR-applications)
    • Time continuously progressing (controlled by server)
    • Scene modification processed / distributed immediately
    • Animation / scene viewing happen at same time
    • No history of scene changes required
  • Offline mode:
    • No progressing/actual time
    • Query/modify scene graph at any specific point on time-line
    • Animation / scene viewing happen at different times
    • Must store whole history of scene graph changes
    • E.g. collaborative construction keyframing animation / CAD
communication protocol
Communication protocol
  • Receive / transmit messages: common protocol
  • Environment described using nodes  node tree (graph)
    • Describe concrete / abstract objects
    • Node type/name, field type/name/value
  • Geometry of objects: subset of VRML (descriptive language)
  • Commands to modify scene graph
    • UPDATE: modify node field (\'value\' VS. \'pointer\')
    • ADD / REMOVE: add node/tree to \'grouping\' node
    • SETTIME: specify time of modification (offline mode)
    • GETTIME: specify time of query (offline mode)
    • SET: setting flags
data structures scene nodes
Data Structures – Scene Nodes
  • Scene graph implemented as node tree
  • Create/insert nodes:
    • ADD, UPDATE
    • Node description
    • Check node table
  • Remove/delete nodes:
    • REMOVE
    • \'Empty\' UPDATE
  • Online mode: actual state  creation time = actual time
  • Offline mode: no actual state  creation time = SETTIME
    • No nodes deleted: assign \'lifespan\'
data structures history list
Data Structures – History List
  • Each element corresponds to ADD / REMOVE / UPDATE
  • Modification of a determined node field
  • Creating: referencing / creating
  • Removing: referencing/ destroying
  • Modify pointer -> reference counter
  • Timestamp=actual time (online) / SETTIME (offline)
  • Traversed to generate update messages for clients
integration parser
Integration Parser
  • Data structures client communication protocol
  • Translate incoming commands  trigger callback-functions
  • Parser platform independent  fixed set of callback headers
    • Make: Create node of given type/name

Called by \'creating\' add/update

    • Add: Append child-node to parent-node
    • Remove: Remove child-node from scene graph
    • Update: Change determined node field to specific value Field types: pointer, boolean, float, string
  • Callbacks generate element in history list
    • Timestamp: actual time (online) / SETTIME (offline)
    • History list sorted by timestamp
server main loop online
Server Main Loop - Online
  • On message receipt: collect/send outstanding messages
    • New client:
      • Transmit scene graph
      • Generate entry in client-list
    • Existing client:
      • Generate updates since last trigger
      • Traverse history-list (from last transmitted message)
  • Parse message (ADD/REMOVE/UPDATE)
      • Modify scene graph
      • Generate history element
  • Delete history-elements sent to all clients
  • Remove nodes from scene graph (\'destroying remove\')
server main loop offline
Server Main Loop - Offline
  • Parse incoming message
    • GETTIME time:
      • Update scene graph of client (as specified by last query)
      • Match state of common scene graph at time
      • Traverse scene graph/collect messages:
      • Timestamp  [last query,time]
      • From last sent message: direction specified by time
    • SETTIME time:
      • Use as timestamp for future ADD/REMOVE/UPDATE
    • ADD/REMOVE/UPDATE:
      • Generate history element
      • (Scene graph reflects state specified by SETTIME)
  • Store whole history - memory bottleneck
examples online 1 3
Examples - Online 1/3
  • Integration heterogeneous applications
    • Facial models (Photogrammetry)
    • Human model (Keyframe animation)
    • Human model (SoftImage)
    • Cartoon model (CreaToon)
    • Animated facial model
    • Body reconstruction
    • Boundary recovery algorithm (visualize evolution of potentials)
    • Animated robot (Inventor)
  • Time needed to integrate into environment:  1 evening !
examples online 2 3
Examples - Online 2/3
  • Optimization techniques:
    • Remove redundant updates from history-list
    • Visibility culling (PVS: potentially visible set)
  • 100 objects
    • Movement along randomized paths
    • Translated 5 times per second
    • Duration 100 seconds
    • 50.000 history elements generated
  • Client requests updates 2 / 3 times per second
    • 30000 / 20000 history elements redundant
conclusion
Conclusion
  • Construction simple / generic geometry server
  • "User\'s manual": implementation aid
  • Reflecting design decisions
  • Categorizing default components
  • Future work:
    • Include Levels of Detail (LOD)
    • Prioritized management of update messages
    • Evaluation of perceptual error metrics
  • Sponsor: TMR Network of European Community
ad