supporting animation and interaction ingo wald sci institute, university of utah [email protected]

Supporting Animationand Interaction

Supporting Animationand Interaction

Ingo Wald

SCI Institute, University of Utah

[email protected]

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


• Depend on Precomputed, high-quality ADS Can’t change geometry

Probably (one of) the most important problems in ray tracing today !


• 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


• 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…


• 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…


• 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


• 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


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…

supporting animation and interaction ingo wald sci institute, university of utah [email protected]

Documents