Visibility

Visibility

Aaron BloomfieldCS 445: Introduction to Graphics

Fall 2006(Slide set originally by David Luebke)

2

Overview

Analytic Visibility Algorithms BSPs Warnock's Algorithm Z-Buffer Algorithm Visibility Culling Cells and Portals Occlusion Culling Hierarchical Z-Buffer Modern Occlusion Culling Fog

3

Occlusion

For most interesting scenes, some polygons will overlap:

To render the correct image, we need to determine which polygons occlude which

4

Painter’s Algorithm

Simple approach: render the polygons from back to front, “painting over” previous polygons:

Draw blue, then green, then pink Will this work in general?

5

Painter’s Algorithm: Problems

Intersecting polygons present a problem Even non-intersecting polygons can form a cycle

with no valid visibility order:

6

Analytic Visibility Algorithms

Early visibility algorithms computed the set of visible polygon fragments directly, then rendered the fragments to a display:

Now known as analytic visibility algorithms

7


What is the minimum worst-case cost of computing the fragments for a scene composed of n polygons?

Answer: O(n2)

8


So, for about a decade (late 60s to late 70s) there was intense interest in finding efficient algorithms for hidden surface removal

We’ll talk about two analytic visibility algorithms: Binary Space-Partition (BSP) Trees Warnock’s Algorithm

9

Overview


10

Binary Space Partition Trees (1979)

Basic algorithm For each triangle (or polygon) t in the scene

Find the plane that t implicitly forms Let the eyepoint be on one side of t Then t can be drawn before all triangles on the other side of t So we draw the “far” stuff first, then t, then the “near” stuff

Restrictions Only works on a scene where no polygons crosses a

plane defined by another polygon This also means you can’t have a cycle

This restriction is relaxed by a preprocessing step Split up such triangles into multiple triangles

11

Binary Space Partition Trees

BSP tree: organize all of space (hence partition) into a binary tree Preprocess: overlay a binary tree on objects in the

scene This includes the step of splitting a primitive that crosses a

plane into multiple primitives Runtime: correctly traversing this tree enumerates

objects from back to front Idea: divide space recursively into half-spaces by

choosing splitting planes Splitting planes can be arbitrarily oriented Notice: nodes are always convex

12

BSP Trees: Objects

1 2 3

45

6 78

9

13

BSP Trees: Objects

1 2 3

45

6 78

9

5 6 7 8 9 1 2 3 4

14

BSP Trees: Objects

1 2 3

45

6 78

9

5 67 8 9 2 3 4 1

15

BSP Trees: Objects

1 2 3

45

6 78

9

1

3 2 456978

16

BSP Trees: Objects

1 2 3

45

6 78

9

1

3568

7 9 2 4

17

Rendering BSP Trees

renderBSP(BSPtree *T)

BSPtree *near, far;

if (eye on left side of T->plane)

near = T->left; far = T->right;

else

near = T->right; far = T->left;

renderBSP(far);

if (T is a leaf node)

renderObject(T)

renderBSP(near);

18

Rendering BSP Trees

1 2 3

45

6 78

9

1

3568

7 9 2 4

19

Rendering BSP Trees

1 2 3

45

6 78

9

1

3568

7 9 2 4

20

Polygons: BSP Tree Construction

Split along the plane containing any polygon Classify all polygons into positive or negative half-

space of the plane If a polygon intersects plane, split it into two The aforementioned preprocessing step

Recurse down the negative half-space Recurse down the positive half-space

21

Polygons: BSP Tree Traversal

Query: given a viewpoint, produce an ordered list of (possibly split) polygons from back to front:

BSPnode::Draw(Vec3 viewpt)

Classify viewpt: in + or - half-space of node->plane?

// Call that the “near” half-space

farchild->draw(viewpt);

render node->polygon; // always on node->plane

nearchild->draw(viewpt);

Intuitively: at each partition, draw the stuff on the farther side, then the polygon on the partition, then the stuff on the nearer side

22

Discussion: BSP Tree Cons

No bunnies were harmed in my example But what if a splitting plane passes through an

object? Split the object; give half to each node:

Worst case: can create up to O(n3) objects!

Ouch

23

BSP Trees

A BSP Tree increases storage requirements by splitting polygons What is the worst-case storage cost of a BSP tree on n

polygons? But rendering a BSP tree is fairly efficient

What is the expected cost of a single query, for a given viewpoint, on a BSP tree with m nodes?

24

BSP Demo

Nice demo: http://symbolcraft.com/graphics/bsp/index.html Also has a link to the BSP Tree FAQ

25

Summary: BSP Trees

Pros: Simple, elegant scheme Only writes to framebuffer (i.e., painters algorithm)

Thus once very popular for video games (but no longer, at least on PC platform)

Still very useful for other reasons (more later)

26

Summary: BSP Trees

Cons: Computationally intense preprocess stage restricts

algorithm to static scenes Worst-case time to construct tree: O(n3) Splitting increases polygon count

Again, O(n3) worst case

27

Overview


28

Warnock’s Algorithm (1969)

Elegant scheme based on a powerful general approach common in graphics: if the situation is too complex, subdivide Start with a root viewport and a list of all primitives Then recursively:

Clip objects to viewport If number of objects incident to viewport is zero or one, visibility

is trivial Otherwise, subdivide into smaller viewports, distribute primitives

among them, and recurse

29

Warnock’s Algorithm

What is the terminating condition?

How to determine the correct visible surface in this case?

30

Warnock’s Algorithm

Pros: Very elegant scheme Extends to any primitive type

Cons: Hard to embed hierarchical schemes in hardware Complex scenes usually have small polygons and high

depth complexity Thus most screen regions come down to the single-pixel case

31

Overview


32

The Z-Buffer Algorithm

Both BSP trees and Warnock’s algorithm were proposed when memory was expensive

Ed Catmull (mid-70s) proposed a radical new approach called the z-buffer (He went on to help found a little company named Pixar)

The big idea: resolve visibility independently at each pixel

33


We know how to rasterize polygons into an image discretized into pixels:

34


What happens if multiple primitives occupy the same pixel on the screen? Which is allowed to paint the pixel?

35


Idea: retain depth (Z in eye coordinates) through projection transform Recall canonical viewing volumes Can transform canonical perspective volume into

canonical parallel volume with:

010011

100

0010

0001

min

min

min z

z

z

M

36


Augment framebuffer with Z-buffer or depth buffer which stores Z value at each pixel At frame beginning initialize all pixel depths to When rasterizing, interpolate depth (Z) across polygon

and store in pixel of Z-buffer Suppress writing to a pixel if its Z value is more distant

than the Z value already stored there “More distant”: greater than or less than, depending

37

Edge equations: Z is just another planar parameter:

z = Ax + By + C Look familiar? Total cost:

1 more parameter to increment in inner loop

3x3 matrix multiply for setup See interpolating color

discussion from aprevious lecture

Edge walking: can interpolate Z along edges and across spans

Interpolating Z

38


How much memory does the Z-buffer use? Does the image rendered depend on the drawing

order? Does the time to render the image depend on the

drawing order? How much of the pipeline do occluded polygons

traverse? What does this imply for the front of the pipeline? How does Z-buffer load scale with visible polygons?

With framebuffer resolution?

39

Z-Buffer Pros

Simple!!! Easy to implement in hardware Polygons can be processed in arbitrary order Easily handles polygon interpenetration Enables deferred shading

Rasterize shading parameters (e.g., surface normal) and only shade final visible fragments

When does this help?

40

Z-Buffer Cons Lots of memory (e.g. 1280x1024x32 bits) Read-Modify-Write in inner loop requires fast memory Hard to do

analytic antialiasing

Hard to simulate translucent polygons

Precision issues (scintillating, worse with perspective projection)

41

Overview


42

Visibility Culling

The basic idea: don’t render what can’t be seen Off-screen: view-frustum culling

Solved by clipping Occluded by other objects: occlusion culling

Solved by Z-buffer

The obvious question: why bother? The (obvious) answer: efficiency

Clipping and Z-buffering take time linear to the number of primitives

43

The Goal

Our goal: quickly eliminate large portions of the scene which will not be visible in the final image Not the exact visibility solution, but a quick-and-dirty

conservative estimate of which primitives might be visible

Z-buffer & clip this for the exact solution This conservative estimate is called the potentially

visible set or PVS

44

Visibility Culling

The remainder of this talk will cover: View-frustum culling (briefly) Occlusion culling in architectural environments General occlusion culling

45

View-Frustum Culling

An old idea (Clark 76): Organize primitives into clumps Before rendering the primitives in a clump, test a

bounding volume against the view frustum If the clump is entirely outside the view frustum, don’t render

any of the primitives If the clump intersects the view frustum, add to PVS and render

normally

46

Efficient View-Frustum Culling

How big should the clumps be? Choose minimum size so:

cost testing bounding volume << cost clipping primitives

Organize clumps into a hierarchy of bounding volumes for more efficient testing

If a clump is entirely outside or entirely inside view frustum, no need to test its children

47

Efficient View-Frustum Culling

What shape should the bounding volumes be? Spheres and axis-aligned bounding boxes: simple to

calculate, cheap to test Oriented bounding boxes converge asymptotically faster

in theory Lots of other volumes have been proposed, but most

people still use spheres or AABBs.

48

Overview


49

Cells & Portals

Goal: walk through architectural models (buildings, cities, catacombs)

These divide naturally into cells Rooms, alcoves, corridors…

Transparent portals connect cells Doorways, entrances, windows…

Notice: cells only see other cells through portals

50

Cells & Portals

An example:

51

Cells & Portals

Idea: Cells form the basic unit of PVS

PVS = potentially visible set Create an adjacency graph of cells Starting with cell containing eyepoint, traverse graph,

rendering visible cells A cell is only visible if it can be seen through a sequence

of portals So cell visibility reduces to testing portal sequences for a line of

sight…

52

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

53

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

54

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

55

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

56

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

57

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

?

?

58

Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

X

X

59

Cells & Portals

View-independent solution: find all cells a particular cell could possibly see:

C can only see A, D, E, and H

A

D

H

FCB

E

G

A

D

H

E

60

Cells & Portals

View-independent solution: find all cells a particular cell could possibly see:

H will never see F

A

D

H

FCB

E

G

A

D

CB

E

G

61

Cells and Portals

Questions: How can we detect whether a given cell is visible from a

given viewpoint? How can we detect view-independent visibility between

cells? The key insight:

These problems reduce to eye-portal and portal-portal visibility

62

Cells and Portals

Airey (1990): view-independent only Portal-portal visibility determined by ray-casting

Non-conservative portal-portal test resulted in occasional errors in PVS

Slow preprocess Order-of-magnitude speedups

63

Cells and Portals: History

Teller (1993): view-independent + view-dependent Portal-portal visibility calculated by line stabbing using

linear program Cell-cell visibility stored in stab trees View-dependent eye-portal visibility stage further refines

PVS at run time Slow (?) preprocess Elegant, exact scheme

64

Cells and Portals: History

Luebke & Georges (1995): view-dependent only Eye-portal visibility determined by intersecting portal

cull boxes No preprocess (integrate w/ modeling) Quick, simple hack Now-archaic public-domain library: pfPortals

65

Overview


66

General Occlusion Culling

When cells and portals don’t work… Trees in a forest A crowded train station

Need general occlusion culling algorithms: Aggregate occlusion Dynamic scenes Non-polygonal scenes

67

General Occlusion Culling

I’ll discuss two algorithms: Loose front-to-back sorting Hierarchical Z-Buffer

Ned Greene, SIGGRAPH 93

… and current hardware support

68

Loose Front-To-Back Sorting

Can sort your geometry in roughly front-to-back order, e.g. by: Using an octree/BSP tree Sorting centroids or near points of bounding volumes

Why would this help? A: Early rejection helps whole fragment pipeline

69

Image-Space Occlusion Culling

Many general occlusion culling algorithms use an image-space approach

Idea: solve visibility in 2D, on the image plane

70

Overview


71

Hierarchical Z-Buffer

Replace Z-buffer with a Z-pyramid Lowest level: full-resolution Z-buffer Higher levels: each pixel represents the max depth of

the four pixels “underneath” it Basic idea: hierarchical rasterization of the

polygon, with early termination where polygon is occluded

72


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

73


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

74


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

75


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

76

Hierarchical Z-Buffer: Discussion

HZB needs hardware support to be really competitive Hardware vendors haven’t entirely bought in:

Z-pyramid (and hierarchies in general) unfriendly to hardware Unpredictable Z-query times generate bubbles in rendering pipe

But we’re getting there… ATI HyperZ Similar technology in NVIDIA Both “under the hood”, not exposed to programmer

At the user level, hardware now supports occlusion queries

77

Overview


78

Modern Occlusion Culling

Support from hardware would be nice Want an “occlusion test”: would this polygon be visible if

I rendered it? How could you use such a test?

Test portal polygons before rendering adjacent cell Test object bounding boxes before rendering object

Yay! GL_HP_OCCLUSION_TEST extension But only returns non-visibility

Problems: CPU/GPU synchronization == bad Might want to know “how visible” is the polygon

79

Modern Occlusion Culling

GL_NV_OCCLUSION_QUERY to the rescue Non-blocking query

“Is this occlusion query done yet?” Multiple queries in flight

Returns number of fragments visible Note: can actually render object or not Supports object-space coherence, temporal

coherence Still lots of issues for efficient culling

80

111 uses for Occlusion Queries

Occlusion culling (duh) Others?

Approximate culling LOD size estimation Lens flare effects Transparency Collision detection (!) Convergence testing

Side note: GL_ARB_OCCLUSION_QUERY is latest incarnation Fixes a possible race condition in NV_occlusion_query

logic

81

Overview


82

Fog filters – what’s wrong with it?

http://www.cs.mtu.edu/~shene/DigiCam/User-Guide/filter/filter-fog.html

83

Haze and the Z-buffer

84

Fog and the Z-buffer

http://www.cnykayakclub.com/pictures2003.htm

85

Water and the Z-buffer

86

Fog filters – what’s wrong with it?

http://www.cs.mtu.edu/~shene/DigiCam/User-Guide/filter/filter-fog.html

Date post:	22-Jan-2016
Category:	Documents
Upload:	varick
View:	34 times
Download:	0 times

Visibility

Documents