concepts in computer graphicssubodh/courses/csl859/pdfslides/visibility.pdf · view-frustum culling...

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

More on this soon

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