Ray Space Factorization for From-Region VisibilityRay Space Factorization for From-Region Visibility
Tommer LeyvandOlga SorkineDaniel Cohen-Or
Tel-Aviv University, Israel
From-Region VisibilityFrom-Region VisibilityFrom-Region VisibilityFrom-Region Visibility
Problem of identifying which parts are visible from a region (viewcell)
Problem of identifying which parts are visible from a region (viewcell)
Entire Model Visibility SetValid from within the viewcell
AbstractAbstract
• Conservative occlusion culling method – Factorizing 4D visibility problem in to
horizontal and vertical components
• Two components is solved asymmetrically• Horizontal component
– Parameterization of the ray space
• Vertical component– Incrementally merging umbrae
AbstractAbstract
• Efficiently realized together by modern graphics hardware
• Occlusion map to encode visibility
• Culling time and size of the computed PVS→ depend on the size of the viewcell
• For moderate viewcells– Occlusion culling of large urban scenes:
< 1 sec– Size of the PVS = 2 * size of the exact VS
From-Region visibility is 4D• A ray exists the viewcell through a 2D surface and
enters the target region through a 2D surface
From-Region visibility is 4D• A ray exists the viewcell through a 2D surface and
enters the target region through a 2D surface
Dimensionality ofDimensionality ofFrom-Region VisibilityFrom-Region VisibilityDimensionality ofDimensionality ofFrom-Region VisibilityFrom-Region Visibility
viewcell
Our FactorizationOur FactorizationOur FactorizationOur Factorization
Factor the 4D visibility problem into horizontal and vertical components
Factor the 4D visibility problem into horizontal and vertical components
Horizontal direction Vertical direction
Ray Space ApproachRay Space Approach Umbra Merging ApproachUmbra Merging Approach
Form-Pint vs. From-RegionForm-Pint vs. From-Region
• Complexity of models keeps growing• Occlusion culling can effectively reduce the
rendering depth complexity• Visibility from-point: compute each frame
• Visibility from-region: valid for a region rather than a single point
– Advantage of time and spatial coherence– Computational cost is amortized over
consecutive frames
• Compute from-region visibility on-the-fly,not having to resort to off-line methods
4-Dimensional Problem4-Dimensional Problem
• Decide: whether an object S is (partially) visible or occluded from a region C
• Requires detecting:whether there exists at least a single ray thatleaves C and intersects S before it intersects an occluder
CS
occluder
?
regionobject
SolutionsSolutions
• Exact solutions are possible: [Nirenstein et al. 2002…]
! overly expensive !• Conservative solutions: [Durand et al. 2000…]
gain speed-up by overestimating the exact VS• Dealing with 2.5D scenes: [Koltun et al. 2001…]
2.5D occluders is quite reasonable in practice(especially in walkthrough applications)
• For more general scenes– Necessary to have a culling method that
can deal withthe occlusion of a larger domain of shapes
Graphics HardwareGraphics Hardware
• Advanced graphics cards: visibility featureindicates whether a just drawn polygon is visible or hidden by polygons already drawn
• The technique this paper present here:utilizes capabilities of the latest graphics hardware to accelerate the performance for from-region visibility
Occlusion Culling MethodOcclusion Culling Method
• Occlusion cast: arbitrary 3D models• Idea: 4D visibility problem → two 2D components
– Horizontal: parameterization of the ray space
– Vertical: maintained by pairs of occluding angles
• Key point:– Horizontal components → polygonal shapes
– Each point in polygonal footprints → vertical slice
– Modern graphics hardware → polygonal footprints can be
drawn
– Applying per-pixel visibility calculations →significant speed-up
From-region MethodFrom-region Method
• Early generic from-region methods:occlusion of a single occluder or approximated
• Better capture the occlusion and reduce the VS: detect objects – hidden by a group of occluders
• Advanced from-region methods:aggregating individual umbrae into a large umbra capable of occluding larger parts of the scene
Aggregating UmbraeAggregating Umbrae
• Ray-parameterization:– capture the visibility of an object into some
geometric region (a polygonal footprint)– Apply Boolean operations (visibility)
• Fuses individual intersecting umbrae into large umbrae
• Combines these two approaches !
Occlusion ProblemOcclusion Problem
• Visibility problems: (in particular occlusion problem)
→ problems in line spaces • Example: basic occlusion problem
Given a segment C, an object A is occluded from any point on C by a set of objects Bi
→if all the lines intersecting C and A also intersect the union of Bi
AC
Occlusion Problem – SolutionOcclusion Problem – Solution
• Using the line space,lines in the primal space mapped to points
• Mapping: 2D line vs. pointDefine: By coefficients of the lines (primal space)
line y = ax + b is mapped to point (a, -b) (in the line parameter
space)
AC
footprint
Occlusion Problem – AnalysisOcclusion Problem – Analysis
• Not optimal: vertical lines are mapped to infinity
• Problem: all lines with large coefficients
• Practical reason: dual space must be bounded
• Solution: moving to higher dimensions– Loses the simplicity and efficiency
of operating in image space
Occlusion Problem – AnalysisOcclusion Problem – Analysis
• Ideas to 3D case: not as easy as in 2Dthe parameter space of 3D lines has high D
• In general, 3D lines have four DOF• Rays: origin of the lines
• Visibility in 2D flatland: limited interest
• Note: most of objects are detected as occluded in flatland, while actually being visible in 2.5D due to their various heights
Occluder FusionOccluder Fusion
• Different approach for occluder fusion:incrementally construct an aggregate
umbrain primal space
• Occluder fusion occurs whenever:individual umbrae intersect
• Note: umbra intersection is a sufficient condition but not necessary one
OverviewOverview
• Bounded nonsingular parameterization:2D component by a vertical projection of the objects onto the ground (z=0)
• Footprint: composed of a polygons (parameter space)
• Rays in 3D primal space = (s,t) direction define a vertical slice (directional plane)
OverviewOverview
Line segment: casts a directional umbra→ each directional plane: aggregated umbra (occluder)→ aggregated umbra (all): maintained in occlusion map
OverviewOverview
• Hierarchical front to back traversal of objects– Perform visibility queries– Update the occlusion map
• Footprint of objects– Conservatively discretized– Drawn by the graphics hardware
• Occlusion map– Represented by a discrete ray space
Ray ParameterizationRay Parameterization
• Duality of RR2 is a correspondence between– 2D lines y=ax+b in the primal space– Points (a,-b) in the dual space
• Different parameterization of 2D lines– Only the oriented lines (rays)
(emerge from a given 2D square viewcell)
– Not have singularity– Parameter space is bounded– Rays (leave the viewcell) intersect a triangle
• Form a footprint in the parameter space– Can be represented by a few polygons
Primal SpacePrimal Space
• s, t: associated with the inner, outer squares
• r(sr, tr) : ray r intersects with inner and outer squares
s=0
t=0
1/4
1/2
1/23/4
1/4
3/4 Primal Space
Footprint of a 2D TriangleFootprint of a 2D Triangle
• Footprint: a geometric primitiveas the set of all points in the parameter spacethat refer to rays that intersect the primitive
s=0
t=0
1/4
1/2
1/23/4
1/4
3/4
Primal Space Ray Parameter Space1/4 1/2 3/4 10 s
t
1/4
1/2
q1
q2
A
ttqq11(1/4)(1/4)
ttqq11(1/2)(1/2)
ttqq11(1)(1)
ttqq11(3/4)(3/4) ttqq11(1/2)(1/2)
ttqq11(1/4) (1/4)
-- For a fixed value of s: { (s,t) : t [-- For a fixed value of s: { (s,t) : t [ttqq11(s), (s), ttqq22(s)(s)] }] }
Footprint of a 2D TriangleFootprint of a 2D Triangle
s=0
t=0
1/4
1/2
1/23/4
1/4
3/4
t=1/4
t=1/2s=1/4 s=1/2
Visibility within a Vertical PlaneVisibility within a Vertical Plane
• Traverse the cells of a kd-tree in a front-to-back order interleave occlusion tests against the occlusion map andumbra merging to maintain it
• How to perform visibility queries?• How to perform occluder fusion?
The visibility is solved within each vertical sliceThe visibility is solved within each vertical slice
Horizontal direction Vertical direction
A vertical sliceA vertical slice Within a vertical sliceWithin a vertical slice
Vertical SliceVertical SliceVertical SliceVertical Slice
Vertical Visibility QueryVertical Visibility QueryVertical Visibility QueryVertical Visibility Query
• B cast a directional umbra with respect to K within P(s,t)
• Supporting-angles encode the directional umbra of B within the vertical plane P(s,t)
• Angle values are represented by their tangentsas functions of (s,t)
s t
R
R ‘
Horizontal direction
Vertical slice P(s,t) : vertical planeB = p1p2
, : supporting line , : supporting angle
B
p1
p2
K
t bt b
t b
t
b
Vertical Visibility QueryVertical Visibility Query• Q: line segment within P(s,t) that’s behind B
(according to the front-to-back order with respect to the viewcell)
• Determining whether Q is occluded by B→Testing whether the umbra of B contains Q
• Front-to-back order guarantees– tested segment is always behind the occluders
→supporting lines are sufficient for the visibility test
Q is occluded: Both of their endpoints are within the accumulated umbra
i.e. bbtt and
Directionalaccumulated
umbra
Within a slice: Test occlusion by comparing supporting angles
Merging UmbraeMerging Umbrae
• In the vertical direction plane– umbra aggregation is performed by testing
umbra intersection and fusing occluders
• Supporting lines alone do not uniquely describe the umbra
Adding separating lines → defining the umbra uniquely
Merging Umbrae (1)Merging Umbrae (1)
bbtt and
“throw out” the contained segment and keep just the other one
Umbra of one segment is contained in the area between the supporting lines of the other segment
Merging Umbrae (2)Merging Umbrae (2)
No umbra intersection occurs
bbtt or
Merging Umbrae (3)Merging Umbrae (3)
If (1)(2) tests fail as well → umbra intersection
},max{ ttt },min{ bbb
},min{ ttt },max{ bbb
Replace the two segments by a new “virtual” occluder segment
Insert into the occlusion map the following angles:
Occluder FusionOccluder Fusion
• Note:– Fused umbra is valid only for testing occlusion
of ocludees placed behind all the occluders that created the umbra
– Merging umbra is order-independent• an approximate ordering of the occluders is more
efficient
– Typically man-made scenes have a strong vertical coherence andafter some umbra-merging steps, the umbra grows to capture most of the occlusion
Putting It All TogetherPutting It All Together
• Combine: horizontal footprint, vertical visibility – Exploiting - all the directional (vertical)
computations can be performed in parallel
• Footprints are conservatively discretized before rendering– adding four values {v0,v1,v2,v3} to each pixels– represent the four supporting and separating
angles
• For each vi:– footprint F(R’) is augmented into a 3D (s,t,v)
parameter space, yielding four 3D footprints– these footprints are surface
Vertical direction
Horizontal direction
v
s
t
Parameter Space
(s,t)
top
bottom
top
bottom
Umbra EncodingUmbra Encoding
Hierarchical VisibilityCullingHierarchical VisibilityCulling
• Original objects of the scene are inserted into a kd-tree
• During the algorithm, kd-tree has two functions– traverse the scene in a front-to-back order– allows culling of large portions of model
Kd-tree traverseKd-tree traverse
• Kd-tree is traverse top-down– large cells can be detected as hidden
and culled with all their sub-tree– if a leaf node is still visible
• the visibility of each bounding box associated with it is tested
– if a bounding box is visible• the triangles bounded in it are defined as
potentially visible
OcclusionOcclusion
• In scenes with significant occlusion– objects close to the viewcell rapidly fill the
occlusion map– most of the back larger kd-cells are detected as
hidden
• From-region front-to-back order of the kd-cells is a strict order rather than approximate– guaranteed by using large kd-cells whose splitting
planes never intersect any viewcells
Merging UmbraMerging Umbra
• Merging umbra is applied while traversing the kd-tree front-to-back– a leaf node is detected as visible
• the polygons in that leaf are considered as occludersand their footprint are inserted into the occlusion map(possibly merging with the existing umbrae created so far)
• Merging umbrae simplifies the occlusion map and increases the occlusion– optionally, before updating the occlusion map,
the visibility of individual polygons in the PV leaf can be tested to tighten the PVS
AlgorithmAlgorithmPVS←CalculateVisibility(kd-tree.root)
CalculateVisibility(curr_kd_cell) if TestVisibility(curr_kd_cell) //current kd-cell is visible if cur_kd_cell.IsLeaf() PVS←PVS curr_kd_cell.getTriangles() AugmentOcclusionMap(curr_kd_cell.getRriangles()) else foreach kd_child curr_kd_cell.children in f2b order CalculateVisibility(kd_child) end foreach endif else return //current kd-cell occluded->terminateend
2.5D Occluders2.5D Occluders
• 2.5D occluders: “half-umbra”– only top supporting angle is stored– bottom supporting angle is always zero– encode using the z-coordinate of the 2D
footprint
• Testing visibility of an occludee– testing the visibility of its footprint (disabling z-
buffer)
• Umbra fusion by– enabling z-buffer updates– drawing the occluder footprint
t
3D Occluders3D Occluders
• Use a series of top and bottom supporting and separating angles
• Occlusion map stores only a single directional umbra per direction (hardware limitation)
• Testing visibility of an occludee– testing whether the top or bottom supporting
footprints are visible
• Umbra fusion by– testing whether the new umbra intersects the
current umbra in the occlusion map
ImplementationImplementation
• Cg implementation:– 32bit floating-point PBuffer
• store the global occlusion map
– Fragment shader functionality• calculation of the directional umbra within
each slice• testing occlusion• merging umbra
Urban ModelUrban Model• 2GHz P4 machine with Nvidia GeForce4 Ti
graphics card• A randomly generated urban model:
– Large set of parameters– Increasing vertical complexity– Not axis-aligned
Non-realistic ModelNon-realistic Model
• Box-field: consists of randomly generated boxes– Not too dense → geometry deep inside the box-field is visible– Reducing the effectiveness of the use of a hierarchy
Result-Urban SceneResult-Urban Scene
Viewcell size
Off-junction viewcells In-junction viewcells
Time PVS / VS Time PVS / VS
3 0.31 2412 / 1760 0.40 8832 / 6824
9 0.41 2840 / 2632 0.51 12184 / 9072
14 0.58 3592 / 2894 0.96 13576 / 9184
20 0.71 4568 / 2928 1.56 18340 / 9888
25 0.78 5224 / 2960 2.01 21608 / 10072
• 26.8M triangles• Height of viewcells: 2.5 units• PVS and VS size is given in triangles• Time: refers to culling-time (seconds)• Off-junction viewcells: within some city block• In-junction viewcells: on the junction of two long avenues
Result- Box-fieldResult- Box-field
Viewcell size
Near viewcell Far viewcell
Time PVS / VS Time PVS / VS
5 0.93 4864 / 1312 3.22 35456 / 14224
10 1.10 6032 / 1424 3.45 37072 / 14256
15 1.27 7184 / 1552 3.59 38912 / 14304
20 1.39 8176 / 1632 3.71 40080 / 14416
30 1.87 13136 / 2400 4.04 43248 / 14672• 20.7M triangles• Height of viewcells: 10 units• Near viewcell: viewcell located from within the field• Far viewcell: viewcell located outside and far from the field
• When the viewcell is closer to the scene,the objects are larger and occlude much more
Result-Culling effectivenessResult-Culling effectiveness
Viewcell size
VS size
Half-umbra Full umbra
PVS size Time PVS size Time
3 7536 28296 0.996 18968 1.354
9 7720 31936 1.149 22368 1.704
14 7808 33504 1.184 22576 1.745
25 8304 36480 1.253 24520 1.845
• Comparison between: 2.5D vs. 3D occluders• 20M triangles (urban city model)• Maintaining a single full umbra reduces the size of the PVS,
at the expense of longer computation time
ResultResult
• Culling time is directly dependent on two interdependent factors– number of visibility queries– number of visible triangles (occluders)
• The technique can deal with a huge model– due to the hierarchy– but only as long as the size of the VS is small
• only a small number of triangles is visible• implies that only a small number of kd-cells in the
hierarchy is tested
ResultResult
• PVS: quite conservative– Absolute size of the PVS is relatively small
(less than 0.1% of the full model)
• Effectiveness– Not measured for a single view– Over time, for a large number of frames– 30FPS->at least hundreds of frames are
generated within one viewcell– actual cost of generating the PVS can be
amortized over time
Result-Resolution of Ray SpaceResult-Resolution of Ray Space
• 26.8M triangles• viewcell size: 25x25x2.5 units• VS size: 10072 triangles• Takes more time to render in high resolution• Cost of hardware-based visibility test: proportional to the
resolution• High resolution ray space -> less conservative PVS• 512x512: effective resolution
Resolution PVS size Percentage Time (sec.)
128x128 36936 0.14% 0.626
256x256 27920 0.10% 1.217
512x512 21608 0.08% 2.011
1024x1024 14168 0.05% 5.335
Result-Culling effectivenessResult-Culling effectiveness
Small viewcells Large viewcells
Size Time PVS/VS Size Time PVS/VS
3 0.18 946 / 424 50 0.36 3396 / 502
14 0.19 1216 / 514 100 0.45 4424 / 744
25 0.22 1546 / 592 150 0.58 5720 / 930
• Vienna200 model: 3x3 km of the city• Height of buildings: 2.2-50.8m (18.6m on average)• Size: viewcell in meters (height of viewcells is 2m)• For smaller viewcells: PVS is tight (2-2.6)• For large viewcells: PVS/ VS ratio grows to about 6-7
The EndThe EndThe EndThe End
Before After
Procedural CityProcedural CityProcedural CityProcedural City
XML configured city generation engine• Simple building blocks
– 3D boxes and pyramids
– Rotation and scaling operators
– Texture groups
– Instantiation parameters within user defined random limits
• Exports city to VRML 2.0
XML configured city generation engine• Simple building blocks
– 3D boxes and pyramids
– Rotation and scaling operators
– Texture groups
– Instantiation parameters within user defined random limits
• Exports city to VRML 2.0