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. 2 / 18 Introduction n Client-server architecture to integrate of incompatible graphics systems/applications n Detailed explaination of construction process l Put together system based on known techniques n Case study - Provide help in construction of such systems l Categorization of clearly distinct default components l Provide insights about design decisions l Good relation between cost/performance concerning development and implementation) n "Implementation" talk/paper

3. 3 / 18 The PAVR-project n European union project: 10 universities n Ease collaboration and exchange of know-how concerning virtual reality / animation n (Software-) “Platform for Animation and Virtual Reality” n Problem: l Incompatible systems (software/hardware) l Stand-alone applications n Goal: l Link (existing) applications into common environment l Little effort, minor code changes

4. 4 / 18 Approach n Existing systems l RING, NPSNET, DIVE, SPLINE, SPLINE, NETEFFECT, PARADISE, AVIARY,... n Client-server system l Common communication protocol l Clients replicate environment using own routines / data structures l Integration: translate data structures protocol  client n Components l Simple/generic protocol l Flexible parser (easy integration into clients) l Efficient server (geometric data / transmission service)

5. 5 / 18 Geometry Server Components 1/2 n Communication layer: provide network connections l Easy to integrate, small (Sockets, TCP/IP) n Communication protocol l Transmit geometry objects + commands modify properties l Easy to interpret for server / clients n Lexical parser / pre-determined callback functions l Defined headers, proprietary implementation server/clients l Modify protocol without changes in program code n Scene database: l Hierarchical scene graph (nodes describe objects) l History list (describe graph changes) n Client list:

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

7. 7 / 18 Online Vs. Offline Mode n Online mode: l "Real-Time" mode (typical for VR-applications) l Time continuously progressing (controlled by server) l Scene modification processed / distributed immediately l Animation / scene viewing happen at same time l No history of scene changes required n Offline mode: l No progressing/actual time l Query/modify scene graph at any specific point on time-line l Animation / scene viewing happen at different times l Must store whole history of scene graph changes l E.g. collaborative construction keyframing animation / CAD

8. 8 / 18 Communication protocol n Receive / transmit messages: common protocol n Environment described using nodes  node tree (graph) l Describe concrete / abstract objects l Node type/name, field type/name/value n Geometry of objects: subset of VRML (descriptive language) n Commands to modify scene graph l UPDATE: modify node field ('value' VS. 'pointer') l ADD / REMOVE: add node/tree to 'grouping' node l SETTIME: specify time of modification (offline mode) l GETTIME: specify time of query (offline mode) l SET: setting flags

9. 9 / 18 Data Structures – Scene Nodes n Scene graph implemented as node tree n Create/insert nodes: l ADD, UPDATE l Node description l Check node table n Remove/delete nodes: l REMOVE l 'Empty' UPDATE n Online mode: actual state  creation time = actual time n Offline mode: no actual state  creation time = SETTIME l No nodes deleted: assign 'lifespan'

10. 10 / 18 Data Structures – History List n Each element corresponds to ADD / REMOVE / UPDATE n Modification of a determined node field n Creating: referencing / creating n Removing: referencing/ destroying n Modify pointer -> reference counter n Timestamp=actual time (online) / SETTIME (offline) n Traversed to generate update messages for clients

11. 11 / 18 Integration Parser n Data structures client communication protocol n Translate incoming commands  trigger callback-functions n Parser platform independent  fixed set of callback headers l Make: Create node of given type/name Called by 'creating' add/update Called by 'creating' add/update l Add: Append child-node to parent-node l Remove: Remove child-node from scene graph l Update: Change determined node field to specific value Field types: pointer, boolean, float, string n Callbacks generate element in history list l Timestamp: actual time (online) / SETTIME (offline) l History list sorted by timestamp

12. 12 / 18 Server Main Loop - Online n On message receipt: collect/send outstanding messages l New client: u Transmit scene graph u Generate entry in client-list l Existing client: u Generate updates since last trigger u Traverse history-list (from last transmitted message) n Parse message (ADD/REMOVE/UPDATE) u Modify scene graph u Generate history element n Delete history-elements sent to all clients n Remove nodes from scene graph ('destroying remove')

13. 13 / 18 Server Main Loop - Offline n n Parse incoming message l l GETTIME time: u u Update scene graph of client (as specified by last query) u u Match state of common scene graph at time u u Traverse scene graph/collect messages: u u Timestamp  [last query,time] u u From last sent message: direction specified by time l l SETTIME time: u u Use as timestamp for future ADD/REMOVE/UPDATE l l ADD/REMOVE/UPDATE: u u Generate history element u u (Scene graph reflects state specified by SETTIME) n n Store whole history - memory bottleneck

14. 14 / 18 Examples - Online 1/3 n Integration heterogeneous applications l Facial models (Photogrammetry) l Human model (Keyframe animation) l Human model (SoftImage) l Cartoon model (CreaToon) l Animated facial model l Body reconstruction l Boundary recovery algorithm (visualize evolution of potentials) l Animated robot (Inventor) n Time needed to integrate into environment:  1 evening !

15. 15 / 18 Examples - Online 2/3 n Optimization techniques: l Remove redundant updates from history-list l Visibility culling (PVS: potentially visible set) n 100 objects l Movement along randomized paths l Translated 5 times per second l Duration 100 seconds l 50.000 history elements generated n Client requests updates 2 / 3 times per second l 30000 / 20000 history elements redundant

16. 16 / 18 Examples - Online 3/3 Without redundant messages With redundant messages Without visibility culling 19.495 / 28.801 50.000 / 50.000 With visibility culling 3.167 / 4.766 8.070 / 8.078

17. 17 / 18 Examples - Offline

18. 18 / 18 Conclusion n Construction simple / generic geometry server n "User's manual": implementation aid n Reflecting design decisions n Categorizing default components n Future work: l Include Levels of Detail (LOD) l Prioritized management of update messages l Evaluation of perceptual error metrics n Sponsor: TMR Network of European Community