Supporting Animation and Interaction Ingo Wald SCI Institute, University of Utah

Supporting Animation and Interaction Motivation Types of Animations Alternative Approaches Animated Scenes in OpenRT Practical Examples

The 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 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 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 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 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 Scenes First 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 Scenes First 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 Scenes First 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 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 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 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 OpenRT Hierarchical 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 OpenRT Hierarchical 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 OpenRT Hierarchical 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 OpenRT Unstructured 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 OpenRT Summary 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 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 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 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 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) 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.) 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 Scenes Summary 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…