1 / 25

Supporting Animation and Interaction

Supporting Animation and Interaction. Ingo Wald SCI Institute, University of Utah wald@openrt.de. Supporting Animation and Interaction. Motivation Types of Animations Alternative Approaches Animated Scenes in OpenRT Practical Examples. The Need for Dynamic Scenes.

xia
Download Presentation

Supporting Animation and Interaction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Supporting Animationand 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 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…

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

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

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

  15. Dynamic 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

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

  17. Dynamic 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

  18. Dynamic 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

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

More Related