Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Supporting Animation and Interaction Ingo Wald SCI Institute, University of Utah"— Presentation transcript:

1 Supporting Animation and Interaction Ingo Wald SCI Institute, University of Utah wald@openrt.de

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

3 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

4 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 !

5 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

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

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

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

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

10 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]

11 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...

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

13 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...

14 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

15 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

16 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)

17 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

18 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

19 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…)

20 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]

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

22 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

23 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,…

24 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.

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


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

Similar presentations


Ads by Google