Z-buffer Kurt Akeley CS248 Lecture 13 6 November 2007

Z-buffer

Kurt Akeley

CS248 Lecture 13

6 November 2007

http://graphics.stanford.edu/courses/cs248-07/

CS248 Lecture 13 Kurt Akeley, Fall 2007

Painter’s algorithm

Initial OpenGL behavior is “painter’s algorithm”

Fragment color values overwrite sample color values

Sequence is guaranteed

Result at each sample is the color of the last fragment

Painter’s algorithm (ordered rendering) is useful:

2-D rendering (especially pre-filter triangle antialiasing)

Volumetric rendering (future lecture)

But painter’s algorithm puts a huge burden on the application for general 3-D rendering

Want “nearest” geometry to be visible

But sorting in the application is difficult, sometimes very difficult …


Sorting difficulties

Topological Interpenetrating


Z-buffer

Vertex operations

Project ze to zc

Primitive operations

Homogenize

Z viewport (glDepthRange) generates zw

Rasterization

Assign a zw value to each fragment sample

Fragment / framebuffer operations

Conditionally replace pixel sample values (color and depth) with fragment sample values

Depth comparison specified by glDepthFunc

Typically replace if fragment is nearer to viewer than pixel


Naming conventions

Depth buffer and Z-buffer have the same meaning

OpenGL uses “depth” rather than “z”

Emphasized notion of depth attribute rather than 3-D window coordinates

Resulted in nice name syntax

I’ve reverted to “z”

I prefer to think of window coordinates as a 3-D system

Z-buffer is in more common usage (maybe)


Outline

Z-buffering example

Culling

Other approaches to the hidden surface problem

Numerical issues

Selected topics


Pipeline Example


Walk through the vertex pipeline

Z-buffering enabled

Multi-sample antialiasing enabled

This is simple to setup:

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer

glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH | GLUT_MULTISAMPLE);

…glEnable(GL_DEPTH_TEST);glEnable(GL_MULTISAMPLE);


Vertex operations

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer


Perspective projection

Specify a frustum:

glMatrixMode(GL_PROJECTION);

glLoadIdentity();

glFrustum(l,r,b,t,n,f);

20 0

20 0

20 0

0 0 1 0

n r l

r l r ln t b

t b t bf n fn

f n f n

æ ö+ ÷ç ÷ç ÷ç - - ÷ç ÷ç ÷ç ÷+ç ÷÷ç ÷ç ÷¢ - -= ×ç ÷ç ÷ç ÷ç + ÷ç ÷- - ÷ç ÷ç - - ÷ç ÷ç ÷ç ÷÷ç -è ø

P P

c e

c e

c e

c e

x x

y y

z z

w w

æ ö æ ö÷ ÷ç ç÷ ÷ç ç÷ ÷ç ç÷ ÷ç ç÷ ÷ç ç÷ ÷= ×ç ç÷ ÷ç ç÷ ÷÷ ÷ç ç÷ ÷ç ç÷ ÷ç ç÷ ÷ç çè ø è ø

P

n and f are distances, not coordinates. Both must be positive.


The frustum

xe

ye

ze

( )l b n-

( )r t n-

f fl t f

n n

æ ö÷ç × × - ÷ç ÷çè ø

2

c e

c e e

e

w z

f n fnz z w

f n f n

C z D

=-

+=- × - ×

- -

= × +

zc is projected

Assuming we is 1.0



Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer


Homogenization of Z

xe

ye

ze

( )l b n-

( )r t n-

f fl t f

n n

æ ö÷ç × × - ÷ç ÷çè ø

1

2

c e

c e e

e

cd

c

e

e

e

w z

f n fnz z w

f n f n

C z D

zz

w

C z D

z

C D z -

=-

+=- × - ×

- -

= × +

=

× +=

-

=- - ×


Viewport transformation

Transform the [-1,1] range device coordinates to window coordinates:

0 02 2

0 02 2

0 02 2

w d

w d

w d

w wl

x xh h

y y b

z zf n f n

æ ö æ ö÷ ÷ç ç +÷ ÷ç ç÷ ÷ç ç÷ ÷ç çæ ö æ ö÷ ÷ç ç÷ ÷÷ ÷ç çç ç÷ ÷÷ ÷ç ç÷ ÷ç ç÷ ÷ç ç÷ ÷÷ ÷= + +ç çç ç÷ ÷÷ ÷ç çç ç÷ ÷÷ ÷ç çç ç÷ ÷÷ ÷ç ç÷ ÷ç ç÷ ÷è ø è øç ç÷ ÷- +ç ç÷ ÷ç ç÷ ÷÷ ÷ç ç÷ ÷ç çè ø è ø

glViewport(int l, int b, int w, int h);

glDepthRange(double n, double f);

( )0 0 0

glViewport(0, 0, 10, 6);

glDepthRange(0.0, 1.0);

( )10 6 1

One pixel


Z arithmetic

( )

1

1

1

2

2 2

2 2

ˆ ˆ

ˆ

cd

c

e

vp vp vp vpw d

vp vp vp vpe

e

we

e

zz

w

C D z

f n f nz z

f n f nC D z

C D z

dzDz

dz

-

-

-

-

=

=- - ×

æ ö æ ö- +÷ ÷ç ç÷ ÷= × +ç ç÷ ÷ç ç÷ ÷ç çè ø è ø

æ ö æ ö- +÷ ÷ç ç÷ ÷= ×- - × +ç ç÷ ÷ç ç÷ ÷ç çè ø è ø

= + ×

=-

This will be a problem!


Rasterization

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer


Perspective-correct attribute evaluation

( ) ( ) ( )0 1 0 1 1 2 1 2 2 0 2 0a y x x y y x x y y x x y= - + - + -

0 1 20 1 2

0 1 2

0 1 20 1 2

1 1 1

f f fb b b

w w wf

b b bw w w

+ +=

+ +

(x0 y0 w0 f0)

(x1 y1 w1 f1)

(x2 y2 w2 f2)

(x y f )

a2

a1

a0

( ) ( ) ( )( ) ( ) ( )( ) ( ) ( )

0 1 1 1 2 1 2 2 2 0 0

1 2 2 2 0 2 0 0 0 1 1

2 0 0 0 1 0 1 1 1 2 2

,

,

,

a yx xy y x x y y x x y b a a



= - + - + - =

= - + - + - =

= - + - + - =

All w’s are wc’s


Perspective-correct zw evaluation

( ) ( ) ( )0 1 0 1 1 2 1 2 2 0 2 0a y x x y y x x y y x x y= - + - + -

0 0 1 1 2 2w w w wz b z b z b z= + +

(x0 y0 zw0)

(x1 y1 zw1)

(x2 y2 zw2)

(x y zw)

a2

a1

a0

( ) ( ) ( )( ) ( ) ( )( ) ( ) ( )

0 1 1 1 2 1 2 2 2 0 0

1 2 2 2 0 2 0 0 0 1 1

2 0 0 0 1 0 1 1 1 2 2

,

,

,




= - + - + - =

= - + - + - =

= - + - + - =

zw was projected during

homogenization


Perspective-correct zw evaluation

zw is not linearly related to ze

We’ll plot the relationship later when considering precision

But this doesn’t matter for hidden-surface calculations

zw has been projected

So it interpolates linearly

So comparison yields the nearest fragment sample We don’t care about the actual distances


Mask generation

Single Pixel

struct { short x,y; bool mask[n]; // 01110110 float depth[n]; // as required float r,g,b,a; // 1,0,0,1} fragment;


7 6 5 4 3 2 1 0

Mask bitsTwo triangles, first red, second

green:


Fragment / pixel operations

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer


Fragment / pixel operations



7 6 5 4 3 2 1 0

Resolved color

5/8, 0, 0, 1

Resolved color

3/8, 1/4, 0, 1

All samples initially black, farthest:


Multi-sample antialiasing

Requires a lot of state: Fragment

Mask Full depth value for each sample (but this can be

optimized)

Pixel Full color and depth values for each sample Additional front and back resolved color values

But it works really well: Handles arbitrary fragment sequences Handles interpenetrating triangles Satisfies rule 1 (no frame-to-frame discontinuities) Has no unpredictable or ill-mannered behaviors

Other less expensive (and more clever) antialiasing approaches are not so well behaved …


Culling


Culling

Culling: elimination of primitives or fragments that will not affect the final image

Andrew discussed culling last week

Frustum culling

Portal culling (a special case of occlusion culling)

Basic idea: eliminate work as early in the sequence as possible

But with a reasonable pay-off for the effort


Culling

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer

Frustum culling

Occlusion culling

Portal culling

Back-face culling

HierarchicalZ culling


Frustum culling


Occlusion culling

Active research topic

Difficult for sparse scenes (e.g., oil refinery)

Introduces notion of “depth complexity”

Average number of fragments generated per pixel

Portal culling is a special case of occlusion culling

OpenGL includes acceleration support

“reduction” query (any pixel samples modified?)

glBeginQuery(GL_SAMPLES_PASSED, id);

// render proxy object (e.g., a bounding cuboid)

glEndQuery(GL_SAMPLES_PASSED, id);

glGetQueryObjectiv(id, GL_QUERY_RESULT, *params);


Back-face culling

Eliminate triangles that face away from the point of projection

Such triangles are never visible if they compose proper solids

How to identify?

OpenGL has no facet normals So cannot compute dot product with

eye-to-vertex vector

Could compute plane equation in eye coordinates and substitute (0, 0, 0, 1) But no other area computations are

done in eye coordinates

Compute signed area in window coordinates Shares math with rasterization setup

Compute in order of vertex specification

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer


Signed area calculation

( ) ( ) ( )0 1 0 1 1 2 1 2 2 0 2 0a y x x y y x x y y x x y= - + - + -

(x0 y0)

(x1 y1)

(x2 y2)

Usual rule: CCW vertex rotation on outside of solid volume


OpenGL triangle facing commands

glFrontFace(GL_CW | GL_CCW);

glEnable(GL_CULL_FACE);glDisable(GL_CULL_FACE);glCullFace(GL_FRONT | GL_BACK | GL_FRONT_AND_BACK);

glMaterialfv(GL_FRONT | GL_BACK | GL_FRONT_AND_BACK, …);glLightModeli(GL_LIGHT_MODEL_TWO_SIDE, GL_TRUE | GL_FALSE);


Hierarchical Z culling

Fragment ops build a multi-resolution, conservative z-buffer

Much like a MIPmap

But max value rather than filtered value

Entire primitives are culled against this multi-resolution z-buffer

Optimal use requires front-to-back rendering order

Opposite of painter’s algorithm

Will be covered again in Dave Oldcorn’s Tuning and Debugging lecture

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application


Framebuffer

HierarchicalZ culling


Z-buffer as a back stop

Ideal goal:

z-buffer rejects no samples

Practical goal:

z-buffer sees a minimal depth complexity

e.g., 2-3

Z-buffer back stop allows efficient, conservative culling


Other hidden-surface algorithms

Application level

Binary space partition (BSP) tree

Various analytical approaches

Application/OpenGL

Convex solids Sort at application level using plane equations

Render each solid with back-facing triangles culled

Hidden-line rendering Future lecture


Z-buffering is a brute-force technique

And this is good!

Never solves the “hidden-surface” problem

Instead resolves visibility one sample (ray) at a time


Numerical Issues


Z-buffer punch through

When surfaces are too close, the z-buffer may not sort them accurately

Here’s an example of the resulting “punch through” for near-parallel red and green surfaces:


Z arithmetic

( )

1

1

1

2

2 2

2 2

ˆ ˆ

ˆ

cd

c

e

vp vp vp vpw d

vp vp vp vpe

e

we

e

zz

w

C D z

f n f nz z

f n f nC D z

C D z

dzDz

dz

-

-

-

-

=

=- - ×

æ ö æ ö- +÷ ÷ç ç÷ ÷= × +ç ç÷ ÷ç ç÷ ÷ç çè ø è ø

æ ö æ ö- +÷ ÷ç ç÷ ÷= ×- - × +ç ç÷ ÷ç ç÷ ÷ç çè ø è ø

= + ×

=-


Z-buffer mapping (eye-to-window coords)

zw

ze

Normalized to Zfar = 1


Z-buffer mapping (log10 ze)

zw

ze


Zfar = 50 milesZnear = 26 feet

Normalized to Zfar = 1

Bad

Good

ze

Difference between adjacent zw

representations near the specified ze, mapped back to eye coordinates


Resolution loss

Rules of thumb:

log2(f/n) bits are lost in the far field

There are roughly 216 inches in a mile

Solutions:

Minimize f/n ! Push n as far away as possible (draw vehicle

separately)

Pull f in (e.g., fog)

Adjust n and f dynamically

Use a different

ze to zw mapping and/or

zw representation



16-bit reverse mapped, floating-point z-buffer

16-bit integerz-buffer

Zfar = 50 milesZnear = 26 feet

Bad

Good

ze

24-bit integerz-buffer


Z-buffer resolution summary

This is a rich topic

We’ve just scratched the surface May return to this topic in one of the last lectures

Good practice:

Minimize f/n !

Use back-face cull and model LOD to avoid tiny triangle-to-triangle separations

If possible use reversed-mapped (complementary) floating-point z-buffer There are problems with this in OpenGL

– zc is clipped to +/- wc, rather than 0 <= zc <= wc

I believe it works well in Direct3D 10


Selected Topics


Transparent surfaces and the z-buffer

Z-buffer finds the nearest surface

It cannot sort front-to-back or back-to-front for blending

A-buffer can do this, but is expensive to implement I know of no hardware that does so

Two good solutions:

Depth peeling Multi-pass sort, renders one transparent surface per pass

Can use occlusion reduction to terminate the loop

– Or just render a fixed number of passes

Pre-filtered point and line antialiasing algorithm Render all opaque triangles first

– Builds opaque z-buffer

Then render all transparent triangles in arbitrary order

– Disable z-buffer write so all tests are of the opaque z-buffer


Fade model LOD

Switching suddenly from one model LOD to another violates rule 1

Viewers will see a jarring transition

Need to fade between model LODs over several frames

But blending and z-buffering don’t cooperate in this case

Cannot render in-place in the scene Need to resolve visibility within each LOD model

But blend between the resulting “images”

Solutions:

Render separate off-screen images, then composite to scene

Morph geometrically between two models

Fade “spatially” rather than blending …


OpenGL sample-coverage fade

Use standard z-buffer semantics for each sample

Allocate a fraction of the samples to one model, and the remaining fraction to the other

Fade by transitioning the allocation frame-to-frame

Works best with multi-sample antialiasing:

glSampleCoverage(value, invert);

glEnable(GL_SAMPLE_COVERAGE);


Sample coverage example

Single Pixel

7 6 5 4 3 2 1 0

Mask bits

glSampleCoverage(0.25, GL_FALSE);

// possible mask is 00100100

glSampleCoverage(0.25, GL_TRUE);

// corresponding mask is 11011011


Outlined polygons

Why is this a problem?

What are possible solutions?


Summary

Use Z-buffer as a backstop, cull earlier if at all possible

Visibility cull (frustum, occlusion)

Back-face cull

Z-cull (optimize by rendering front-to-back, prepass)

Arithmetic precision is a critical Z-buffer issue

Minimize far/near ratio

Prefer floating-point Z-buffer with reverse mapping

Use back-face cull and model LOD to avoid punch through

Z-buffer mechanism is an imperative “tool”

Render transparent tris last: Z compare, blend, no Z write

Blend model LODs with SAMPLE_COVERAGE


Assignments

Next lecture: Graphics Hardware

Reading assignment for Thursday’s class

David Blythe, Rise of the Graphics Processor, to be published.


End

Date post:	22-Dec-2015
Category:	Documents
View:	220 times
Download:	1 times

Z-buffer Kurt Akeley CS248 Lecture 13 6 November 2007

Documents