1. Ray Space Factorization for From-Region Visibility Authors: Tommer Leyvand, Olga Sorkine, Daniel Cohen-Or Presenter: Alexandre Mattos

2. Goal Real-time walkthroughs of large 3D scenes Server contains all world geometry and needs to transmit it to clients Only send geometry that is visible to client Reduce network traffic Client needs to compute what geometry to render

3. Strategy Point-wise visibility What user can see from their exact current location Needs to be calculated every time player moves Will not work due to network latency Might not work on client either

4. Strategy Divide scene into view cells As user moves around, calculate visible geometry for that view cell and adjacent cells

5. From-Region Visibility Given a view cell, compute what is visible from that view cell An object is visible if there is at least one ray exiting the view cell that intersects that object

6. From-Region Visibility

7. Assumptions Scenes are largely 2.5 + εD Not much vertical complexity Example – Sky scrapers of varying heights Will first explain algorithm assuming 2.5D

8. Dividing Up the Problem Paper splits the problem into easier-to-solve vertical and horizontal components Determine if objects occlude each other vertically or horizontally and then combine the results Build K-d Tree over entire scene Allows front to back traversal of scene

9. View Cell Parameterization Define two concentric squares One is view cell One is outside view cell Parameterize inner and outer square with S and T respectively

10. Rays (S,T) Can define all rays (view directions) leaving view cell with (S, T)

11. Horizontal Component Orthographically project all geometry onto the ground Geometry has a mapping to parameter space

12. Key Insight Render geometry in parameter space front to back If parameter space for geometry is already rendered, then geometry is occluded

13. Vertical Component (S, T) define a plane Intersection of a plane and a triangle defines a vertical line and casts a directional umbra

14. Vertical Component Object is occluded if it is contained within vertical umbra

15. Vertical Component One way to solve the problem: Traverse scene front to back and maintain aggregated umbra

16. Video In the 2.5D only Objects are visible if the slope of their umbra is larger than the current umbra

17. Putting It Together For all geometry render it in 3D as (S, T, α) where α is angle of the umbra at that point Using graphics hardware, we can do occlusion tests for all geometry

18. Hardware Implementation Disable Z-buffer updates and render geometry If a single pixel renders, it is visible To update occlusion map, render geometry with Z-buffer updates enabled

19. Algorithm Traverse K-d tree

20. Extension from 2.5D to 3D Only comparing α not valid anymore

21. 3D Umbra Need to keep four angles (α1, α2, α3, α4) to represent umbra uniquely

22. Merging Umbra Many cases Umbrae may be disjoint

23. Hardware Implementation For all geometry render it in 3D as (S, T, V) where V = (α1, α2, α3, α4) Use a pixel/fragment shader that checks whether a pixel is visible based on V Pass V values to graphics card in a buffer Render (S, T, X) where X is index into buffer for V

24. Hardware Limitations Can only maintain one aggregated umbra per vertical slice Pack 16 bit floats into 32 bit floats to allow two aggregated umbrae Use many buffers to store multiple umbrae Paper claims that one umbra is sufficient because umbrae merge rapidly

25. Results Buildings are 9-12 units and rotated at most 30 degrees Box model contains random boxes in random orientation Vienna model

26. Results City Model Half-umbra VS Full-umbra Box Model Resolution Effect VS is 10,072 triangles Vienna Model

27. Discussion Algorithm is sensitive to how much it has to render Works well for dense scenes because occlusion map quickly occludes entire scene For a minor cost of rendering one extra K-d tree node they can double model size If the VS is large, then a lot of geometry is rendered and algorithm slows down Can calculate PVS over several frames

28. Discussion No tests done for sparse models Umbrae will not converge rapidly Many K-d tree nodes need to be tested Algorithm prefers horizontal occlusion over vertical occlusion Horizontal occlusion is exact up to rendering Vertical occlusion is conservative based on how many umbrae are used