Viewing and Perspective Kurt Akeley CS248 Lecture 9 23 October 2007

Viewing and Perspective

Kurt Akeley

CS248 Lecture 9

23 October 2007

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

CS248 Lecture 9 Kurt Akeley, Fall 2007

Projection

Projection

Transforms points from an n to an n-1 coordinate system

Other definitions? …

Surface of projection

Typically a plane (“planar”)

Curved in special cases E.g., dome simulator

Projectors (connect points through the center of projection)

Typically straight lines (“geometric”)

Curved in special cases Cartographic (e.g., Mercator)

Fish-eye lens (e.g., Omnimax)

Image courtesy of Wikipedia

Image courtesy of Wikipedia


Planar geometric projections

Straight lines project to straight lines

p1, p2, and c define a plane The intersection of this plane and the plane of projection is a

line

But distances may be distorted

Center of projection(aka point of projection,

viewpoint)

p1

p2

Plane of projection

c


Taxonomy of planar geometric projections

Planar geometric

Parallel Perspective

1-point 2-point 3-pointOrthographic Oblique

CabinetTop CavalierFront Side

True projection type

Viewing transformation


The vertex pipeline

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application

Primitive operations

struct { float x,y,z,w; float nx,ny,nz; float r,g,b,a;} vertex;

Framebuffer


OpenGL coordinate systems

Vertex operations

Transform vo by MTransform no by M-1

Transform ve by P

Object coordinates

Eye coordinates(lighting calculations)

Clip coordinates

vo

ve

vc

no

ne

“Model-view” transformation

(non-rigid)

Projection transformation

(non-rigid)


The vertex pipeline

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application



Framebuffer

struct { float x,y,z,w; float r,g,b,a;} clipvertex;



Vertex operations

Transform ve by P

Object coordinates


Clip coordinates(clip to unit cube)

vo

ve

vc

no

ne

Model-view transformation


vd

Divide by wc

Map to Window


Homogenize

Normalized device coordinates

vw Window coordinates

Viewport transformation


Primitive assembly


Coordinates systems are convenientObject coordinates

Defined by modeler

Eye coordinates Eye is at the origin, looking down the -z axis, +x to the

right Convenient for lighting calculations

Clip coordinates Unit cube (+/- 1) centered at the origin Convenient for clipping calculations (plane equations are

trivial)

Normalized device coordinates Homogenized clip coordinates Convenient for rasterization and frame buffer arithmetic

Window coordinates Pixels are unit squares, origin at lower-left corner of

window Z values fill available depth-buffer range


Orthographic Projection(the complete sequence)


Viewing transformation

Puts eye at origin looking down the -z axis, +x to the right

Transformation is rigid, one rotation and one translation

GLU helper routine is available (next slide)

x

y

zˆ

e o

e o

e o

e o

x x

y y

z z

w w

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

= ×

M

M V M


gluLookAt

gluLookAt(double ex, double ey, double ez, // eye

double cx, double cy, double cz, // center

double ux, double uy, double uz); // up

= -

¢=

¢=

¢ ¢= ´

¢= ´

f c e

ff

f

uu

u

s f u

t s f

0 1 0 00 0 1 0

0 0 100 0 0 10 0 0 1

x y z x

x y z y

zx y z

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

s s s et t t e

M Mef f f


Light positions

Specified position is transformed by the modelview matrix

glMatrixMode(GL_MODELVIEW);

glLoadIdentity();

gluLookAt(ex,ey,ez,cx,cy,cz,ux,uy,uz);

// now in world coordinates

Float vec[4] = {px, py, pz, pw};

glLightfv(GL_POSITION, vec, 4); // specify in world coordinates

…glMultMatrixf(…);

glLightfv(GL_POSITION, vec, 4); // specify in object coordinates


Orthographic projection

Only scaling is required

But the interface supports scaling and translation:

glMatrixMode(GL_PROJECTION);

glLoadIdentity();

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

20 0

20 0

20 0

0 0 0 1

r l

r l r lt b

t b t bf n

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 signed distances, not coordinates


The orthographic view volume

xe

ye

ze

( )l b n-

( )r t f-


Clip testing

vc is within the unit cube centered at the origin if:

Assuming wc is positive,

this is equivalent to:

c c c

c c c

c c c

w x w

w y w

w z w

- £ £

- £ £

- £ £

1 1

1 1

1 1

c

c

c

c

c

c

x

w

y

w

z

w

- £ £

- £ £

- £ £

xc

yc

zc

( )1 1 1- -

( )1 1 1-


Clipping arithmetic

Points outside the unit cube are discarded

Lines (or edges) that straddle a face of the unit cube are clipped

A new vertex is location is computed at the intersection

Appropriate attribute values are assigned to this vertex

p1

p2

p

( )( )

1 2

1 2

Find (on the clipping plane) and such that 1

Then set the attributes of to 1

t t t

f t f t f

= × + - ×

= × + - ×

p p p p

p


Clipping details

The calculation of p must be invariant to the order of p1 and p2

An edge shared by two triangles must not “crack”

Easiest implementation is canonical: Sort the vertexes into canonical order, then

compute p

Line clipping never generates more than two vertexes

Triangle clipping can generate a vertex for each clipping plane

E.g., Sutherland-Hodgman Later in this lecture

SGI paid royalties on this


Homogenization

1

c cd

c cd

c cd

c c

d

d d

d

x wx

y wy

z wz

w w

x

y

z

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

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

v

Divide by wc:

Discard wd:



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


The vertex pipeline

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application



Framebuffer


struct { float x,y,z; float r,g,b,a;} winvertex;

struct { winvertex v0,v1,v2 } triangle;


Window coordinates

Window coordinates are:

Continuous, not discrete

Not homogeneous Can be used directly for rasterization

3-D, not 2-D Projection did not reduce 3-D to 2-D

3-D homogeneous was reduced to 3-D non-homogeneous

– But this was done by homogenization, not by the projection transformation

Where did the parallel “projection” happen?


Oblique projection


glLoadIdentity();


float s = 0.5; // Cabinet

float m[16] = {1,0,0,0, 0,1,0,0, -s,-s,1,0, 0,0,0,1};

glMultMatrixf(m);

1 0 0

0 1 0

0 0 1 0

0 0 0 1

s

s

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

m


Perspective Projection


Change only the projection matrix

Vertex operations

Transform ve by P

Object coordinates



vo

ve

vc

no

ne



vd

Divide by wc

Map to Window


Homogenize


vw Window coordinates



Primitive assembly


Orthographic projection

Only scaling is required

But the interface supports scaling and translation:


glLoadIdentity();


20 0

20 0

20 0

0 0 0 1

r l

r l r lt b

t b t bf n

f n f n

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

P P

c e

c e

c e

c e

x x

y y

z z

w w


P


Perspective projection

Specify a frustum:


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

cd

c

e

e

w z

f n fnz z w

f n f n

c z d

zz

w

c z d

z

=-

+=- × - ×

- -

= × +

=

× +=

-


Where does projection happen?

There are two ways to think about this:

In the projection transformation “Thinking homogeneously”

Setting wc= –ze warps the eye-coordinate system

– From a frustum in eye coordinates

– To the unit cube in clip coordinates

Homogenization doesn’t really change anything further

Hence “projection transformation”

During homogenization and the discarding of the wd

“Thinking geometrically”

Dividing by –ze causes the projection

This is where coordinates are reduced from 4D to 3D


Remaining topics

Perspective-correct attribute parameterization

Sutherland-Hodgman clipping

Near-plane clipping

The “direction” of a projection

Wide field-of-view projection (planar doesn’t work well)


Rasterization revisited

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application



Framebuffer


struct { float x,y,z; float r,g,b,a;} winvertex;



Planar geometric projection

Straight lines project to straight lines

Only vertexes need to be transformed

That’s why we’re interested in lines and polygons

But distances and parameterizations are warped:


Incorrect attribute interpolation

f2

f1

f

f2

f1

F f

Linearinterpolation

F f¹


Linear (barycentric) 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 0 1 1 2 2f c f c f c f= + +

(x0, y0, f0)

(x1, y1, f1)

(x2, y2, f2)

(x, y, f )

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

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 c a a



= - + - + - =

= - + - + - =

= - + - + - =

a2

a1

a0

( ) ( ) ( )0 1 1 1 2 1 2 2 2 0 0, a yx xy y x x y y x x y c a a= - + - + - =


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 fc c c

w w wf

c c cw w w

+ +=

+ +

(x0, y0, w0, f0)

(x1, y1, w1, f1)

(x2, y2, w2, f2)

(x, y, f )

a2

a1

a0

Requires a division for each fragment

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

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

,

,

,




= - + - + - =

= - + - + - =

= - + - + - =

All w’s are wc’s


Rasterization requires access to wc

Vertex assembly

Primitive assembly

Rasterization

Fragment operations

Display

Vertex operations

Application



Framebuffer


struct { float x,y,z,w_c; float r,g,b,a;} winvertex;




Vertex operations

Transform ve by P

Object coordinates



vo

ve

vc

no

ne



vd , wc

Divide by wc

Map to Window


Homogenize


vw , wc Window coordinates



Primitive assembly


Sutherland-Hodgman clipping

Approach: clip against each plane in sequence

Simplified example clips a triangle to a square, 2-D frustum:


Near-plane clipping

Is required …

To limit zw values to the range of the depth buffer

To avoid division by wc= 0 To avoid rendering objects behind the viewpoint

But clipping assuming wc> 0 accomplishes this too


The “direction” of a projection

Yes, we spoke of a view direction in eye coordinates

Specifically, down the –ze axis, +xe to the right

And yes, the plane of projection is perpendicular to the –ze axis by convention

But, once the projection has been specified, it is not valid to treat it as implying a true viewing direction (the orientation of the eye): Parallel projections have a meaningful direction that

is distinct from the normal to the plane of projection, but this direction is not the view direction.

Perspective projections have no meaningful direction at all. Once specified, they are fully characterized by a center of projection and a plane of projection. The normal to the plane of projection has no meaning.

Bottom line: once a projection has been specified, it implies nothing about the orientation of the viewer’s eye. Only the location of the eye’s optical center is specified (the center of projection).


Projection does not imply viewing direction!


Wide field-of-view display

Assume equal-size pixels

Problem:

Center-field pixels are most important (foveal gaze)

But wide-field pixels have much greater “resolution”


Ratio of perceived pixel sizes

0

5

10

15

20

25

30

35

0 20 40 60 80 100 120 140 160

Field of view (degrees)

Rati

o o

f perc

eiv

ed

siz

e o

f ce

nte

r p

ixel to

ed

ge p

ixel


Piece-wise linear projection

Note: there is one view direction, but three planes of projection


Summary

Perspective projection can be understood two different ways: Warping of eye coordinates by the projection

transformation Consistent with orthographic transformation Consistent with 3-D result Consistent with name “projection transformation”

Division by -ze and discarding of wd Consistent with attribute evaluation

Perspective projection warps distances and attribute evaluation Must interpolate only “projected” values Requires division for attributes of each fragment

Projections do not specify the true orientation of the viewer’s eye Perspective projections don’t really have a direction Parallel projections do, but it’s not the viewing direction


Assignments

Reading assignment for Thursday’s class FvD 17.4

OpenGL chapter 9

Optional: Heckbert, P., A Survey of Texture Mapping, IEEE Computer Graphics, 6:11, pp. 56-67, 1986.

Project 2:

Due tonight at midnight

Midterm

Monday 7 pm to 9 pm, Gates B01


End

Date post:	21-Dec-2015
Category:	Documents
View:	217 times
Download:	1 times

Viewing and Perspective Kurt Akeley CS248 Lecture 9 23 October 2007

Documents