Interactive Ray Tracing of Point-based Models

1. Interactive Ray Tracingof Point-based Models Ingo Wald MPI Informatik, Saarbrücken, Germany wald@mpi-inf.mpg.de

2. Motivation • Why point-based rendering ? • Many advantages, but no details here at PBG • But: Why point-based ray tracing ? • Actually, two different questions: • Q1: Why ray tracing for point-based models ? • Q2: Why use point-based techniques in ray tracing ?

3. Q1: Why Ray Tracing ? • Reason 1: Logarithmic scalability to large models • Very handy for today‘s huge models • But: For PBR not that important (multiresolution)… • Reason 2 : Image quality / shading quality • Ray traced image quality not yet standard in PBG… • But would benice to have

4. Q2: Why Point-based techniques in Ray Tracing? • Native point-based data (acquisition) • Direct ray tracing avoids tesselation • Much simpler • And for native triangular models ? • Triangular model  Point-based model  PBRT • Does this make sense ? • Highly controversial issue amongst ray tracing researchers • RT is log. in #tris, anyway. Don‘t need multiresolution… • Many new problems with points as primitives • Consistency, efficiency, loss of information…

5. Q2: Why Point-based techniques in Ray Tracing? Interactive ray tracing: Three recent examples

6. Q2: Why Point-based techniques in Ray Tracing? Interactive ray tracing: Three recent examples • Example 1: Boeing 777 (350 million triangles, 40 GB data)

7. Q2: Why Point-based techniques in Ray Tracing? Interactive ray tracing: Three recent examples • Example 2: Lawrence Livermore isosurface (8 billion voxels)

8. Q2: Why Point-based techniques in Ray Tracing? Interactive ray tracing: Three recent examples • Example 3: Forest landscape (1.5 billion triangles)

9. Q2: Why Point-based techniques in Ray Tracing? Interactive ray tracing: Three recent examples • Yes, can render all three already today without PB techniques • But: Doesn‘t make sense (>1G prim. for <1M pixels ?) • Too much data: Tiny camera movetotally different data • Even though image doesn‘t change at all… • Sample only every 1000th pixel  Severe aliasing • Aliasing: THE most important problem of RTRT today • Need multiresolution approach also for RT • Probably best via PB approach • Current results only intermediate step… • … towards long-term goal of multiresolution (PB)RT

10. How to ray trace PB models ? • Problem: Zero ray-point hit probability • Rays infinitely thin • Points infitnitely thin, too • Two possible solutions • Use „thick“ rays that have volume (cones, beams, …) • Reconstruct from all points overlapping ray‘s volume • „Grow“ points to have a surface • can then be found by „thin“ ray • Long history of debate on which is better…

11. How to ray trace PB models ? • Alternative 1: Growing rays • Experience: Tracing beams very costly (much more than rays)

12. How to ray trace PB models ? • Alternative 1: Growing rays • Many un-answered questions • Where exactly is the hit point ? • E.g., where to start the shadow ray from ? points gathered by beam Position A Hitpoint position ?

13. How to ray trace PB models ? • Alternative 1: Growing rays • Many un-answered questions • Where exactly is the hit point ? • How stable is the decision ? points gathered by beam Position A Hitpoint position ?

14. How to ray trace PB models ? • Alternative 1: Growing rays • Many un-answered questions • Where exactly is the hit point ? • How stable is the decision ? • Is it consistent ? • E.g., when viewed from different angle (shadow ray) Position B (Light ?) Position A surface seen from A Same surface, different viewpoint: Same hitpoint ? Is it in shadow ? Hitpoint position ?

15. How to ray trace PB models ? • Alternative 1: Growing rays • Many un-answered questions • Where exactly is the hit point ? • How stable is the decision? • Is it consistent ? • Too many open questions

16. How to ray trace PB models ? • Alternative 2: Growing points • Define unique surface through points • Always consistent • Most trivial solution: Use disks/ellipses/… • Trivial

17. How to ray trace PB models ? • Alternative 2: Growing points • Define unique surface through points • Always consistent • Most trivial solution: Use disks/ellipses/… • Trivial, but shading discontinuities (worse w/ shadows)

18. How to ray trace PB models ? • Better: Define smooth surface • Use Adamson/Alexa‘s model • Each point xi has normal ni and radius ri of influence • Influence wi falls off with distance to xi • With wi(xi)=1 and wi(x)=0 for all |x-xi|>ri • Define weighted average position X(x) and N(x) • Define „distance“ function F(x) := ((x-X(x)).N(x) • Implicit fct F(x)=0 is smooth surface • Need: • Useful ri ‘s (not given) • Fast ray/surface intersection framework

19. Choosing Splat Radii • Step 1: Choosing the splat radii • Too small  Holes in the model • Too large  Many regions of influence will overlap (slow) • Use Wu et al.‘s optimal subsampling technique • Wu [EG04]: Determine ri such as to • Optimally cover surface • Achieve minimal overlap Optimal solution: Use exactly that technique • Note: Can also use ‚other‘ radii • e.g., user-specified… • Might just be slower or contain holes

20. Intersecting the Surface • Step 2: Determining the splats to intersect with • Each point x always influenced by only few xi C B D A

21. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box C B D A

22. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes C B D A

23. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes C B D A

24. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes C B D A

25. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes C B D A

26. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes • Leaves: Store list of splats whose ROI overlaps cell C - - C B B B,C - A A,B A,B,C (right side incomplete) D A A -

27. Intersecting the Surface • Step 2: Determining the splats to intersect with • Enclose each splat‘s ROI with tight fitting box • Build kd-tree over those AA boxes • Leaves: Store list of splats whose ROI overlaps cell • KD-Tree: Inherit advantages of fast triangular ray tracing • Fast traversal, occlusion culling, good kd-trees (SAH)… C - - C B B B,C - A A,B A,B,C D A A -

28. Intersecting the Surface • Step 3: Ray/surface intersection in each voxel • Find distance t : F(t)=0 • Equidistant sampling along t • Have intersection if sgn(F(ti+1)) != sign(F(ti)) • But: Too coarse sampling can miss the surface • Optimizations: Fast SSE implementation (no details) • Quite fast, but: Still main cost factor • Further optimize kd-tree to minimize F(x) calls • Need to take closer look at kd-tree

29. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Reason: KD-tree was built over ROI‘s • ROI‘s bound surface, but not closely

30. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Example from before C - - C B B B,C - A A,B A,B,C A,B,C A A A,B,C

31. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Actual surface only touches few voxels C - - C B B B,C - A A,B A,B,C A,B,C A,B,C A A A,B,C

32. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Many non-empty cells that are not necessary C - - C B B B,C - A A,B A,B,C A,B,C A,B,C A A A,B,C

33. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Many non-empty cells that are not necessary • Can make quite a difference C - - C B B B,C - A A,B A,B,C A,B,C A,B,C A A A,B,C

34. KD-Tree Post-optimizations • Observation 1: Many full cells don‘t contain surf. • Fix: Determine min(F()) and max(F()) in each cell • Cull cells with min > 0 or max < 0 • Currently: Sample F with random x • Can produce false culling (holes) • Better: Interval arithmetic (Not implemented yet)

35. KD-Tree Post-optimizations • Observation 2: Most cells too large • Reason: Only split planes at ROI borders • Example from earlier-on: C - - C B B B,C - A A,B A,B,C A A

36. KD-Tree Post-optimizations • Observation 2: Most cells too large • Reason: Only split planes at ROI borders • Example from earlier-on: Green regions would suffice… C - - C B B B,C - A A,B A,B,C A A A

37. KD-Tree Post-optimizations • Observation 2: Most cells too large • Reason: Only split planes at ROI borders • Example from earlier-on: Green regions would suffice… • Fix: Post-shrinking of cells • Cut voxel into slices, cull slices • Same problem as before: False culling… • Important: Not only fewer cell intersections… • Also: Cells much thinner: Finer sampling, fewer artifacts

38. KD-Tree Post-optimizations • Observation 3: After shrink/cull, many cells empty • Example from earlier-on: Most cells empty after cull/shrink - - C B B,C - A A,B A,B,C A

39. KD-Tree Post-optimizations • Observation 3: After shrink/cull, many cells empty • Example from earlier-on: Most cells empty after cull/shrink C B,C A,B A

40. KD-Tree Post-optimizations • Observation 3: After shrink/cull, many cells empty • Example from earlier-on: Most cells empty after cull/shrink • Optimization: Post-collapse • Undo splits that don‘t make sense any more C B,C A,B A

41. Results • Overall Framerate:1Dual-Opteron 2.4GHz, 512x512

42. Results • Overall Framerate: ~5-15 fps @ 1PC • Nice scalability to very complex models • „ManyIffis“: 24M points w/ shadows  ~2fps@1PC

43. Results • Overall Framerate: ~5-15 fps @ 1PC • Nice scalability to very complex models • High-quality shading • Global Illumination

44. Results • Overall Framerate: ~5-15 fps @ 1PC • Nice scalability to very complex models • High-quality shading • Problems and limitations: • Sometimes small holes (false culling, undersampling, …) • All is static: Can‘t move points, can‘t change radii • Assumes continuous surface: • Not applicable to random point cloud (forest leaves…)

45. Summary & Future Work • Summary • Motivated/Argued for Point-based Ray Tracing • Discussed „thin rays“ vs „thick rays“ issue • Outlined framework for Interactive PBRT • Future work • Performance & Stability • Bounding the surface, interval arithmetic, … • Multiresolution PBRT • In particular, for massively complex models

46. Questions ?

47. Questions ?

48. Q1: Why Ray Tracing ? • Impact of Shadows and Reflections: Example

49. Q2: Why Point-based techniques in Ray Tracing? • Need multiresolution approach also for RT • Trivial for „nice“ (manifold) meshes (Progressive meshes,…) • But: „problematic“ for real-world models (Forest, Boeing, …) • Should be much easier for point-based representation • Eventual goal of (our) PBRT activities • Not ray tracing (nice) point-based models • Rather: Multiresolution ray tracing using a PB approach • Reduce (in-core) data • Fight aliasing • Current activities only first step in that direction…

50. Adamson&Alexa‘s model • Observations • Need position and normal for each point  assume as given • Need radius of influence for each point • For each x, most wi(x) will be zero • Fast computation: Need to know which... • Evaluating F(x) will be costly • Need to minimize F(x) calls • Need to quickly determine where surface can NOT be • Need to minimize number of points contributing to x  Need to minimize regions of influence (minimize ri !)