1 / 18

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.

umay
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

  6. Geometry Server Components 2/2 • Flow control • Message filtering • Time management: online vs. offline mode

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

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

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

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

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

  12. 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')

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

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

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

  16. Examples - Online 3/3

  17. Examples - Offline

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

More Related