Concepts in
Computer Graphics
Subodh KumarPrem Kalra
Dept of Computer Sc. & Engg., IIT Delhi
Visibility Computation
Focus on scenes with opaque objects Find the “front-most” layer of the
objects From the eye: a single point
Really a sequence of points
Also, eliminate objects off-camera Assumed you know:
Clipping Z-buffer
Why is that not enough?
Problem Statement
Eliminate large parts of invisible objects
Does not need to be ‘exact’ Is Z-buffer/Clipping exact?
conservative visibility culling OK to not cull invisible parts Never cull visible part Generate “potentially visible set”
Subsequently, Z-buffer and clipping will still be employed
Types of Visibility Culling
View-frustum culling Off-camera
Occlusion culling Hidden by other geometry
Back-face culling
View-Frustum Culling
Cull each primitive? Too slow
Cull a group of primitives i.e., Cull a bounding volume of the group Box, Sphere, …
What should the size of these groups be? Clearly, cost to test volume << cost to clip Bigger the volume, less likely the culling
Hiererchical Culling
Use a hierarchy of groups Quit if a group is entirely outside or
entirely inside view frustum Otherwise, subdivide into smaller groups
and recurse You have already seen BVH
OBBs work well AABBs are popular due to simplicity
Spatial partitioning can also be used
Back-face culling
Works for solid models The ‘back-side’ is invisible
Sphere Back half was never drawn
Back-face culling
Works for solid models Cull the ‘back-side’
Consider, first, the case of triangles Can use winding rule Or, outward normal’s direction
Can we choose any point, p?
p
Hierarchical Back-face Culling
ev.n > 0
Polygon Groups
Back-space
Hierarchical Back-face Culling Eye location problem
VIDEORobustness is a big problem
Polygon Groups
Back-space
Hierarchical Back-face Culling Eye location problem Cluster proximate polygons
Keep orientations similar too For a group, find its half-space
intersection If the eye lies in the common HS
Cull group Coherence in traversal
Subdivide half-space into partitions Query which partition eye lies in
VIDEORobustness is a big problem
Back-side Culling
p.n > e.n for all p c-e.n > r|n|
Back-patch Visibility
p
e
n
Back-Patch Culling
Create bounding volume for object Compute planes tangent to volume
passing through eye
Compute half-space intersection of these planes
Compute bounding cone of normals of the object
If normal cone lies in common half-space Cull Object
Occlusion Culling
Back-faces are occluded But a local test suffices
In general, one must test if some other triangle is in front of this one
One could sort the triangles Hard in general
Trace rays to find visibility in known directions Still slow
Cells & Portals
Consider restricted environments Architectural models 2D problem in a simple setting
Objects visible through doors
Comprise cells containing objects Rooms, corridors…
And, portals through which you see into other cells Doorways, windows…
Cells & Portals Example
Section courtesy of David Luebke
Cells & Portals Algorithm
Add all objects in a visible cell to PVS The cell eye lies in is always visible
Create an adjacency graph of cells Portals are edges
Start graph traversal at eye-cell Find paths to other cells through a
sequence of visible portals Amounts to testing if a path is in the
line of sight
Cells & Portals
AD
H
FCB
E
G
H
B C D F G
EA
Cells & Portals
AD
H
FCB
E
G
H
B C D F G
EA
Cells & Portals
H
B C D F G
EA
AD
H
FCB
E
G
Cells & Portals
E
H
B C D F G
EA
FD
A
H
CB
E
G
Cells & Portals
H
B C D F G
EA
A E
FD
H
CB
E
G
F
Cells & Portals
H
B C D F G
EA
?
EA
A ED
H
CB
E
G?
Cells & Portals
H
B C D F G
EA
X
EA
A E
FD
H
CB
E
GX
Cells & Portals
One can find is a ray from the eye intersecting all portals in the sequence
More efficient to solve an View-cell variant: find all cells a particular cell could potentially
see:
AD
H
FCB
E
G
AD
H
E
A viewer in C may only ever see A, D, E, and H
Cells & Portals
A cell is visible iff any of its portals are visible
A viewer in H can never see any of F
F
AD
H H
CB
E
G
AD
E
Ray Casting [Airey 90]
Sample many rays Non-conservative
Results in occasional errors in PVS Slow, but a preprocess An order-of-magnitude speed-up in
rendering
Cells and Portals [Teller 93]
view-point based as well as cell based Compute portal-portal visibility by
solving the line stabbing problem Does any line pass through all given line
segments i.e., Does there exist a line that separates
each segment’s vertices i.e., The two points lie on different sides of
the line
Line separating vertices
ax + by + c = 0ax0 + by0 + c < 0
(x1,y1)ax1 + by1 + c > 0
(x0,y0)
• Two such equations per segment: Linear constraints• Check for feasibility using linear programming
• Orient segments by path in the graph• Or, simply by sorting by their coordinates
Orienting Segments
AD
H
FCB
E
G
AD
CB
E
G
Stab Oriented Segments
Solving Portal Visibility
Existence of stabbing line computed by using a linear program Cell-cell visibility stored in a stab tree
representing the graph traversal View-based PVS computed by refining
Cell-based PVS at rendering time Reduction to 2D for ‘rooms’ and ‘doors’ Slow pre-process Elegant, exact scheme 3D stabbing line a bit more complicated
View-point based PVS
Constrained DFS of stab tree View cone is clipped to portal Visible area is union of cones
AD
H
FCB
E
G
AD
CB
E
G
Quick Cells and Portals [Luebke 95]
Only view-point based Eye-portal visibility determined by
intersecting portal cull boxes Render portals to see if its visible No preprocessing to compute cell PVS
But portal and cell organization still needed
Simple to implement, works reasonably well, but can be inefficient in theory
Luebke’s Algorithm
Render objects in the view cell Render portal as a ‘special’ polygons Compute it’s visibility
If portal is visible, render adjacent cell But clip to boundaries of the portal!
Recursively check portals in that cell against new clip boundaries (and render) DFS traversal allows implicit pushing and popping
of sequence of portals
Compute Portal Visibility
[Luebke] uses axis aligned bounding rectangle for each portal
Checking portal visibility by Testing Z values inside the rectangle
More efficient to use occlusion query Draw portal inside a query
Cells and Portals Usage
Both Teller’s and Luebke’s techniques work well for architectural models
If the extra pre-processing is possible, Teller’s technique is a better option
Luebke’s technique is competitive for “3D” portals i.e., windows
Teller’s technique supports efficient pre-fetching for large environment walkthrough
General Occlusion Culling
Often ‘rectangular’ portals do not exist No clearly delineated cells either For example, airport or outdoors
General conservative occlusion culling Find occluding geometry Discard geometry behind occluders
Imagine culling primitives in frustum of another Aggregate occlusion
Object or Image space occlusion
General Occlusion Culling
Many techniques in literature, e,g, Object-space region partitioning Hierarchical Z-Buffer Hierarchical occlusion Maps Hierarchical occlusion Query General-cell based Visibility
Hardware Support
Occlusion Culling
Multi-level Z-buffer Generally 2
Occlusion Query HW mechanism to determining
“visibility” of a set of geometry After rendering a group of geometry
Query if Z-buffer was/could be modified If Query answer is “false”
geometry could not have affected Z-buffer
Else, it could have / did modify Z buffer
Ex: Render bounding box, Query
Occlusion Query
Returns pixel count the number of pixels that pass Z-test
May issue multiple queries at once before asking for the result of any one
Applications can overlap the time it waits for the queries to return with other CPU work
Occlusion Query: Usage (Optional) Disable Depth/Color Buffers
(Optional) Disable any other irrelevant state
Generate occlusion queries Begin ith occlusion query Render ith (bounding) geometry End occlusion query
Do other CPU computation now (Optional) Enable Depth/Color Buffers
(Optional) Re-enable any other state
Get pixel count of ith query If (count > MAX_COUNT) render ith geometry
Occlusion Query: OpenGL Generate occlusion queries Gluint queries[N]; GLuint pixelCount; glGenOcclusionQueriesNV(N, queries);
Loop over queries for (i = 0; i < N; i++) { glBeginOcclusionQueryNV(queries[i]); // render bounding box for ith geometry glEndOcclusionQueryNV(); }
Occlusion Query: How to Use
Get pixel counts for (i = 0; i < N; i++) { glGetOcclusionQueryuivNV(
queries[i], GL_PIXEL_COUNT_NV,&pixelCount);
if (pixelCount > MAX_COUNT) // render ith geometry }
Occlusion Query Summary
Render scene (roughly) from front to back Large occluders (walls) are drawn first
Issue queries for other objects in the scene Could be bounding volume, Tree node Better if these “covers” are model geometry
If query returns 0, skip the primitives of object Works best in multi-pass rendering
Object Space Occlusion Computation
Find occludes objects Amounts to view-frustum culling Each occluder forms a culling volume
Find regions from where a given object is visible Usually requires pre-proceeing
Eye-in-Region containment query
General Object Space
Choose large occluders at render-time from a pre-computed set of possibilities
Cull kd-tree nodes against the chosen occluders
Fast culling using separating planes and supporting planes
Supporting plane
Separating plane
Partially Occluded
Occluded
Fully visible
Partially Occluded
Object (node)
Occluder
Good occluders cover large areas of the image Large area Close to the viewer Aligned front on
Associate a set of occluders with each leaf node Choose the set at the leaf containing the viewer Combine occluders sharing non-silhouette edge
i.e, ignore supporting planes through common edge
Cache supporting planes for subsequent frames
Choosing Occluders
V N
Area A
Deye
Hierarchical Z-Buffer
Image-space technique Replace Z-buffer with a Z-pyramid
Lowest level: full-resolution Z-buffer Higher levels: each pixel represents the
maximum depth of the four pixels “underneath” it
Basic idea: hierarchical rasterization of the polygon, with early termination where polygon is occluded
Hierarchical Z-Buffer
Idea: test polygon against highest level first If polygon is further than distance
recorded in pixel, stop—it’s occluded If polygon is closer, recursively check
against next lower level If polygon is visible at lowest level, set new
distance value and propagate up
Hierarchical Z-Buffer
Z-pyramid exploits image-space coherence: Polygon occluded in a pixel is probably
occluded in nearby pixels HZB also exploits object-space
coherence Polygons near an occluded polygon are
probably occluded
Hierarchical Z-Buffer
Exploiting object-space coherence: Subdivide scene with an octree All geometry in an octree node is
contained by a cube Before rendering the contents of a node,
“render” the faces of its cube (i.e., query the Z-pyramid)
If cube faces are occluded, ignore the entire node
Hierarchical Z-Buffer
HZB can exploit temporal coherence Most polygons affecting the Z-buffer last
frame will affect Z-buffer this frame HZB also operates at max efficiency when
Z-pyramid already built So start each frame by rendering
octree nodes visible last frame
From 2.5D Region Visibility
2.5 D => Occluders are walls Visibility reduced to visibility on plane T
Are Segments s1 and s2 occluded by other segments
58
6
FA FB
A B
R
L
(top view)
FA FB
BA
V
T
(side view)
Fig. 2. The construction involved in the reduction to a planar problem. The shaft is shownfi lled.
5 Planar visibility determination
Given two segments and in the plane, and a collection of occluding segments ,we wish to determine whether is visible from . We first provide a simple analyticalgorithm for this problem, which is then converted into a rapid hardware-assisted one.
5.1 Exact analytic algorithm
We define a bounded two-dimensional space, the dual ray space, such that every rayoriginating on and intersecting corresponds to a point in this space. Our algorithm“marks” all points in the ray space that represent rays that pass through occluding seg-ments. Visibility is then detected by checking whether there is at least one point thathas not been “marked”.
More precisely, parameterize and as and ,respectively. Let be the unit square , such that a pointin corresponds to the ray originating at and passing through .
Define a mapping that maps each point to the collection of pointsin that correspond to rays passing through . For any , is a line segmentin . For a segment , parameterized as , is defined to bethe continuous collection of segments . This collection is boundedby the segments and that correspond to the end-points of . In general,it forms either a trapeze (Figure 3(a)) or a double-triangle (Figure 3(b)), depending onwhether the line containing intersects the interior of or not.
This implies a simple exact algorithm for determining whether is visible from: Map each segment to and compute the union of the resulting trapezes and
double-triangles (i.e. ). This computation can be performed in worst-caseoptimal time without employing complex data structures [6]. If and aremutually visible, there is a point that is not contained in this union. The pointcorresponds to a visibility ray (see Figures 3(c) and 3(d)).The dual ray space mapping bears similarities to other duality transforms, such as
the standard duality transform in computational geometry [6] and the Hough transform,
View-Cell
Dual Ray Space
parameterize segments s1 and s2
au + b(1-u) and a’v + b’(1-v)
Now each point in the unit square U: 0 <= (u,v) <= 1
represents a ray from s1 to s2
Rays passing through a point p lie on a line in U
And segment p1p2 maps to a wedge or pyramid
59
Ray-Space
60
7
y
x
RS
s2
s1
T(v)
v
T(v )
T(v )
v0
v1
(1,1)
(0,0) (1,0)
(0,1)
0
1
(a)
y
x
RS
s2
s1
v
T(v)
T(v)
(1,1)(0,1)
(0,0) (1,0)
(b)
y
x
s2
s1
RS(1,1)(0,1)
(0,0) (1,0)
(c)
s2
s1
x
y
(1,1)(0,1)
(1,0)(0,0)
RS
(d)
Fig. 3. Simple scenes (top) and their dual ray space (bottom). In this fi gure, each trapeze in theray space has the color of the segment it corresponds to. (a) and (b) each show an occludingsegment. is occluded from in (c) and is visible in (d); the black point in the ray space of (d)corresponds to the dashed visibility ray.
which is used for line detection in image analysis [16]. However, the dual ray spaceis a bounded region (as opposed to the infinite dual planes of the above-mentionedtransforms) that can be efficiently discretized. This is a crucial advantage that servedas the main motivation for the current definition of the dual ray space. In this sense,the dual ray space is similar to the lumigraph [10] and the light field [17]. (Notice thatGortler et al. [10] also use the term “ray space”.) In the context of related work incomputational geometry, our exact algorithm corresponds to local computation of oneface of the visibility complex [20]. The visibility complex has been previously appliedto ray-tracing [2] and radiosity [19].
5.2 Hardware-accelerated algorithm
We wish to determine whether covers the unit square . This can be ac-complished conservatively by discretizing into a bitmap and rendering allonto this bitmap using graphics hardware. All are drawn in white, without z-buffering or shading, onto an initially black background. If a black pixel remains, thesegments and are reported to be mutually visible. This algorithm avoids the com-plex analytic computation of the union and alleviates robustness problems common ingeometric algorithms.
The default behavior of OpenGL is to color a pixel if its center is inside a drawnpolygon. This may cause inaccuracy, since our algorithm is conservative provided thatonly the pixels that are completely covered by are colored white. This be-havior is ensured by “shrinking” the double-triangles and trapezes prior to rendering.Their edges are moved inward by , where is half the pixel size (see Figure 4).The center of a pixel is inside after shrinking, only if the pixel was completelycovered by it prior to shrinking [27].
Paint all occluders in dual space If there remains an unpainted region, s1 and s2 are
visible
From Region Visibility
View Segment
OccludingSegment
Rest of the SceneEquivalent center
of projection
Visibility From Region in 3D
Supportingplanes
Do not necessarily meet at an apex in 3D
Occluder
Viewer
Visibility From Region in 3D
Find all supporting planes occluder and occludee in the same half-
space Find a COP in that half-space of planes Clip occluders with planes parallel to
supporting planes Render Scene
Render clipped triangles Re-render triangles with occlusion query
From-point Visibility
Viewpoint
Occluder
Occludee
From-point Visibility
Viewpoint
Occluder
Occluder
From-region Visibility
From-region Visibility
From-region Visibility
From-region Visibility
From-region Visibility
From-region Visibility
Occlusion Computation
Group Occluders by direction from cell Find common point for each group
Maximize volume Shrink each occluder Render shrunk occluders Render all polygons
Z-write disabled Occlusion Query
Occlusion culling
How much effort to put in
Enough, but not too much Cells and portals:
relatively cheap, with large potential speedups
View-frustum Culling Cannot avoid for realistic scenes
View-region based Expensive pre-processing Manageable in simpler 2.5D cases
Idle CPUs ask for aggressive CPU-based culling
If you do nothing..
Do this, in that order: Enable backface culling Implement Hierarchical view-frustum
culling Use a K-d Tree
For complex (High Depth Complexity) scenes: Render scene roughly from front to back
Why should that make a difference
Use Occlusion Query
Rough Front-To-Back Sorting
All spatial partitioning techniques sort geometry
Render near to far Why should that make a difference
Later fragments can get culled early Zcull/Early Z
Top Related