supporting animation and interaction ingo wald sci institute, university of utah [email protected]
TRANSCRIPT
Supporting Animationand Interaction
Supporting Animationand Interaction
Ingo Wald
SCI Institute, University of Utah
Supporting Animation and InteractionSupporting Animation and Interaction
• Motivation
• Types of Animations
• Alternative Approaches
• Animated Scenes in OpenRT
• Practical Examples
The Need for Dynamic ScenesThe Need for Dynamic Scenes
• Part I: “How to achieve maximum performance ?”
– Fast ray-surface intersection
– CPU-Friendly implementation
– AND: High-quality acceleration data structures (ADS).
• Problem: Building ADS takes time
– Up to minutes for “realistically” complex models (1MTri)
• For Walkthrough applications: Not a problem
– Build once (preprocess), reuse in following frames
• BUT: Can’t change geometry
The Need for Dynamic ScenesThe Need for Dynamic Scenes
• Depend on Precomputed, high-quality ADS Can’t change geometry
Probably (one of) the most important problems in ray tracing today !
The Need for Dynamic ScenesThe Need for Dynamic Scenes
• Static Geometry: Still many practical applications
– Architecture: Global illumination walkthroughs
– Engineering: Visualizing massively complex models(usually not animated, anyway)
– Industry: Interactive design reviews (only “inspect”/review existing static model)
• Simulation of reflection/refraction in glass/headlights/…
• Visualizing complete cars/planes/… with HQ shading
The Need for Dynamic ScenesThe Need for Dynamic Scenes
• Static Geometry: Already many practical applications
– Design reviews, massive engineering models, architecture, lighting/reflection simulation …
• But: Not applicable to today’s typical “low-end”/”mainstream” use of graphics
– Games … (the main driving force of 3D graphics!)
– Can’t do even simple editing (switching variants, moving parts,…)
• Future scenario: RTRT as mainstream 3D graphics ?
– MUST offer ability to interact with model
• If only for games …
Kinds of Dynamic ScenesKinds of Dynamic Scenes
Need to differentiate between different kinds of “dynamics”
• Hierarchical Animation
– Typical application: Scene graphs (VRML)
• Deformable Objects
– “Relatively” small, but non-hierarchical deformations of a mesh
– Typical application: Skinning
– “Mostly” hierarchical: Skeleton + skinning
• Unstructured Motion
– Typical application: Brownian motion, explosions, …
• Timestepped Animation
– One out of k discrete poses per frame (game characters)
• …
Ray Tracing Dynamic ScenesFirst approachesRay Tracing Dynamic ScenesFirst approaches
• Alternative 1: Handle dynamic objects separately
– Already used in 98/99 [Parker]
• Keep dynamic objects out of ADS, intersect separately
– Only works for very few ‘dynamic’ objects
• Alternative 2: Rebuild ADS every frame
– (Super-)linear in #objects
– Only applicable to tiny scenes
– Note: This might change for future HW…
Ray Tracing Dynamic ScenesFirst approachesRay Tracing Dynamic ScenesFirst approaches
• Alternative 3: Progressively build ADS
– Motivation: Often only parts of scene visible
• Might only need small part of ADS
– Build hierarchical ADS lazily and progressively
• E.g., split node only once ray reaches that node
– Problem:
• Even initial split (for kd-tree) already O(N) Too costly already
– Not really used in practice…
Ray Tracing Dynamic ScenesFirst approachesRay Tracing Dynamic ScenesFirst approaches
• Alternative 4: Update ADS for dynamic objects
– Problem 1: How to avoid degradation of ADS ?
– Problem 2: How to efficiently update ADS ?
– Kd-trees: Quite problematic
• Original cost estimates (SAH) wrong/useless after geom. changes
• Updating often not (easily) possible
– E.g., can’t move root split: would need to rebuild all sibling nodes
• Similar for other hierarchical ADS
– But: works reasonably well for grids [Reinhard01]
Reinhard’s Approach: Dynamically update virtual GridReinhard’s Approach: Dynamically update virtual Grid
• Basic Idea: Use (regular) grid, update dynamically
• Efficient updates: Maintain different grid resolutions
– Large primitives on coarse levels, small primitives on fine levels
• Each prim. Covers few cells remove/add/move primitive in ~O(1)
• Avoiding degeneracy: Grid “wraps around”:
– Objects moving out of right side re-enter on left side
• No rebuild required even if scene’s bounds changes
– Same for rays (slightly different traversal)
– Still: Rebuild from scratch every few frames...
Reinhard’s Approach: Dynamically update virtual GridReinhard’s Approach: Dynamically update virtual Grid
• Results: Works well for many scenes
• But: Only works for grid-like ADS
– Traversal performance relatively low…
– Problematic for large scenes with varying primitive distribution
– Does not easily generalize to more efficient ADS
• Plus: quite problematic for hierarchical animation
– E.g., slight rotation of scene costs O(N) update…
Dynamic Scenes in OpenRTDynamic Scenes in OpenRT
Main observations:
• Prefer kd-trees for high performance and complex scenes
– Problematic for update/rebuild operations
– But: interactive rebuild possible for few dynamic “objects”
• Update/rebuild approaches problematic for hierarchical animation (small change triggers complete rebuild)
• Most practical scenes use (mostly) hierarchical animation
• Scene changes often localized
– In particular: Unstructured motion often very localized(e.g., explosion in complete game level...
Dynamic Scenes in OpenRTHierarchical Scene OrganizationDynamic Scenes in OpenRTHierarchical Scene Organization
OpenRT approach [PGV 2003]:
• Application groups geometry into ‘objects’
– Wrt same properties concerning dynamic updates
– Similar to building display lists
– Each object has its own acceleration structure
• Objects can be re-used in subsequent frames
– No rebuild necessary
• Application can redefine object(s) any time
Dynamic Scenes in OpenRTHierarchical Scene OrganizationDynamic Scenes in OpenRTHierarchical Scene Organization
• Objects are ‘instantiated’ into the scene
• Each instance has a transformation attached to it
– Hierarchical Animation: Inversely transform rays instead of objects
Can keep object itself “static”
Only need to update instance transformation
• Instances are organized in additional hierarchy level
– With its own acceleration structure (kd-tree of instances)
– Only this has to be rebuilt every frame
• Rebuild complete from scratch
Dynamic Scenes in OpenRTHierarchical Scene OrganizationDynamic Scenes in OpenRTHierarchical Scene Organization
Special Case: Timestepped Animation
• Can be realized quite simply
– Build one object for every pose
• All kd-trees built in advance
– Hide all but current pose’s instance
• Simply switch instance per frame, no rebuild at all.
– Sufficient for many game-like applications
• Extension to (simple) skinning possible
– No details here (not yet published)
Dynamic Scenes in OpenRTUnstructured MotionDynamic Scenes in OpenRTUnstructured Motion
• Support for unstructured motion
– Build special object for dynamic triangles
– Rebuild (only) this object ever frame
• Rebuild tolerable for few (~1k-10k) objects
• Use cheap, low-quality kd-trees for these objects
– Trade object’s traversal performance for construction time
• Can have multiple “dynamic object”s
• Problem: Parallelization framework
– Need to send each dynamic triangle to each client
• Huge bandwidth required for many clients and dyn. triangles
Dynamic Scenes in OpenRTSummaryDynamic Scenes in OpenRTSummary
• Two-level object/instance approach
– Transform rays, not objects, plus top-level kd-tree
• Status
– “Limited” support for unstructured motion
– Perfect for hierarchical animation
• (up to few 1000 instances, #tris less important)
– Timestepped animation works as well
Results: Hierarchical AnimationResults: Hierarchical Animation
• Hierarchical Animation: Perfect…
– Rebuild for <10,000 instances: Not a problem at all…
– Standard OpenRT feature: Used in almost any application
– Example: BART Benchmark (images from 2002…)
Results: Multiple InstantiationResults: Multiple Instantiation
• Side Effect: Multiple Instantiation is for free !
– Different instances simply share same geometry
– Example: “Forest” (150,000 instances, ~1.5 billion triangles)
• [Dietrich, EGWNP05]
Results: Unstructured MotionResults: Unstructured Motion
• Unstructured Motion: Possible, but costly
– Rebuild for <10,000 instances: Tolerable, but costly
– Main bottleneck: Network bandwidth…
• Need to transfer each updated triangle to each client in turn
• Not worked on since 02/03: Few practical applications…
Results: Practical ApplicationsResults: Practical Applications
• Totally sufficient for typical VR applications(simple editing and variant switching)
• Note: Cost only depends on #instance, not on #triangles
– UNC Powerplant (12.5 MTri), single PC
Game Example 1: Quake3/RT(Joerg Schmittler, Daniel Pohl)Game Example 1: Quake3/RT(Joerg Schmittler, Daniel Pohl)
• Quake3 bots/scenes, self-written game engine
• Fully ray traced (using OpenRT API)
• Dynamic bots, monsters: timestepped animation
• Plus: Lots of small moving objects, missiles, cartridges,…
Game Example 2: “Oasen”(Tim Dahmen et al.)Game Example 2: “Oasen”(Tim Dahmen et al.)
• Completely ray traced “magic carpet” clone
• Special emphasis on image quality:
– Many lights, underwater caustics, atmospheric effects, water, …
– Highly complex geometry (huge terrain, “real” trees, …)
• With multiple instantiation
– Animated carpet: timestepped animation plus hierarchical transf.
Handling Dynamic ScenesSummary and ConclusionsHandling Dynamic ScenesSummary and Conclusions
What to take home from this talk:
• OpenRT’s two-level approach can already do a lot
– … and it’s easy to implement as well… Try it !
• Research on dynamic RT important for tomorrow’s graphics
– Still too few attention to that problem…