Ray Space Factorization for From-Region Visibility

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 eD
• 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, a)
  where a 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 a not valid anymore

21
3D Umbra

• Need to keep four angles (a1, a2, a3, a4) 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 (a1, a2, a3, a4)
• 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