Construction of an open geometry server for client server virtual environments
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

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


  • 79 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

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

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


    Examples online 3 3

    Examples - Online 3/3


    Examples offline

    Examples - Offline


    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


  • Login