1 of 12 Scene Graphs: the 50,000 ft View

2 of 12 Traditional Definition Historical roots: Sketchpad  linear display lists  hierarchical display lists Retained (cached) data structure created by application, (stored and) processed by graphics subsystem Is a displayable subset of application data structure / database –need to keep two representations in sync Primary purpose: offload main system, improve performance Secondary purpose: provide portable library of common functionality

3 of 12 Traditional Definition (cont.) DAG with geometry at leaves and transformations and rendering attributes at interior nodes Optionally grouping operators Basic event handling mechanisms (interrupts and callbacks (e.g., for picking), polled device registers, logical devices) Can typically edit pieces of DAG to get dynamic behavior Secondary use as file format for API interchange Big traditional users: CAD, Sci/Info Viz,... Ex: Core, GKS, PHIGS+, HOOPS

4 of 12 For Which Apps is a Traditional SG Useful? When application database large and want to view largely structurally static subset Example: architectural walkthrough SG not useful if little frame-to-frame coherence Need to amortize cost of creating and retaining data over time Additionally, SG is a higher level of abstraction that can provide performance and functionality benefits not easily duplicated by application programmer

5 of 12 Modern SG Library Can Provide Optimized Runtime: Akin to high level optimizing compiler: platform independent API w/ hardware optimized driver implementation Written by professionals who know algorithms and hardware As hardware supports geometry and lighting (becomes more complex), more of the rendering pipeline will be handled by library/drivers, less by application More than a retained data structure and more part of application: OO, traversers, renders, etc. CB: “They compete for the computational center of attention”

6 of 12 Modern SG Library Can Provide Optimized Runtime (cont.): High level traversal/rendering: cell-based culling, view-frustum culling, level-of-detail selection, occlusion culling, … Parallelism: multi-threading and multi-processor support Resource management, e.g., database management: storing, fetching, scheduling of geometry, textures

7 of 12 Wheel of Reincarnation: Tradeoffs Keep Changing Sufficiently powerful SG becomes application database in limit Generality vs. efficiency, e.g., hardwiring functionality vs. providing extensible framework Degree to which you can access lower level layers CPU vs. graphics system Hardware vs. software Hard to benchmark low level, let alone SGs Development time vs. execution time

8 of 12 Some Axes for Contrasting Different Existing SGs Functionality both runtime and development time Performance / optimization Behavior specification Resource management Portability Completeness of specification + reference implementation

9 of 12 Modern Scene Graphs Inventor / OpenInventor - event handling via fields, routes (dataflow wiring), widgets e.g., manipulators, ExaminerViewer VRML(X3D)- web-based file format, based largely on Inventor, multiple browsers, no reference implementation IRIS Performer - strong parallel support, provides analysis tools, extensive LOD and performance tuning Java3D - geometry compression, VR support Fahrenheit(?) - FSG based on Performer, FLM based on OpenGL Optimizer and HP DirectModel, COM based Application-specialized, e.g., LM E, G E

10 of 12 Some Modern Features Open to Further Research Resource abstraction and management Newer rendering techniques (e.g., IBR) Event management, animation and behavior (e.g., proximity and collision detection) –Temporal optimization LOD and procedural nodes (geometry and behavior) Spatialized audio rendering, other sensory channels Distribution across processors and network

11 of 12 Individual Object Geometry Stored, e.g., as: Polygon soup General mesh with connectivity info Procedurally generated spline or subdivision patch LOD - implicit (e.g., subdivision surfaces, geometry compression) and explicit (switch nodes) Image-based depth fields Volumetric data

12 of 12 Collections of Geometric Objects Stored, e.g., as: Flat lists Hierarchical scene graphs BSP-trees, octrees Cell-portal graphs Regularly gridded terrain (area of interest in Vis- Sim) Large scale database

13 of 12 What About a Standard SG?!? To create a de facto "standard" need –open, extensible specification –interoperability with peer systems –reference, preferably multi-platform, implementation Should standards only be based on broadly accepted codes of practice, or should they innovate? Do current languages and object models suffice?