140 likes | 257 Views
Scene Graphs: the 50,000 ft View. Traditional Definition. Historical roots: Sketchpad linear display lists hierarchical display lists Retained (cached) data structure created by application, (stored and) processed by graphics subsystem
E N D
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
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
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
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”
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
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
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
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
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
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
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
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?