Why John Carmack Drives A Ferrari

John Ketchpaw

15-462: Computer Graphics 1

February 28, 2002

Administrative JunkTurn in your homeworkThe Midterm is on TuesdayAssignment 5 (roller coasters) should

go out Wednesday

The Game Developer’s role

Everyone wants games to approximate the vision of the designers as closely as possible.

It is the developer’s job to figure out how to make the hardware do it.

The Game Developer’s role

We want our games to have as much graphical detail as possible.

We also want the game to run at interactive frame rates (30Hz)

Some Stats (from 1998)A Quake 3 level – 8k-12k triangles

visible at any moment (pretty close to the number possible per frame)

There are several hundred thousand triangles in a normal level

This ratio will remain high until the end of time.

Some Stats (from 1998)This means we can’t get away with just

drawing all the surfaces with a z-buffer (or painter’s algorithm, etc., etc.), like you’ve been doing so far.

An idea: Don’t draw things if they aren’t visible.

HmmmmThat’s not as simple as it lets on.

Any thoughts on how to do it?

Some MethodsDistance metric

Great for outdoor scenes, but no good for interiors.

Always fighting with “pop in”Human annotation (“these rooms are

visible from here”) Labor intensive, often non-optimal and

error prone

More thinking If we know certain things about the

geometry of the world, we can come close.

What’s common about interiors?

Building InteriorsFor the most part, ceilings are horizontal

and at standard heightWalls are verticalMost walls are at right angles to each

other

Enter Wolfenstein 3D (1992)Wolfenstein stored the world on a grid.Each grid location stored a wall, a door,

an object, or an enemy

“Sliver” RenderingShoot a ray out for each column of

pixels Intersections were very cheap and well-

orderedWorked great on my 286

You’ll fall in love with raycasting later in the semester

Raycasting? What’s that?

The Result

So that’s great and all…But we still want to be able to render

things with different heights for the horizontal surfaces…

We would also like walls that weren’t axis aligned

Computers get a little fasterSuddenly, we can do more per column

of pixels Intersection with arbitrarily aligned line

segments, dealing with variable heights now possible…

But what can we do to efficiently determine which line segments to deal with?

BSP Trees (quick and dirty)Pick a k-1 d hyperplane in our kd world,

and separate the other primitives onto either side

Recurse

This will likely be covered in more detail in an upcoming lecture

What does get us?Very cheap (typically) ordering of the

world, based on the current viewpointWorld is broken up into convex

polygonsDoom used this very effectively

Doom (1993)

But I want more!As long as we’re raycasting, we’re stuck

faking it with 2 dimensions 320x200 image is 64,000 rays 640x480 is 307,200 rays!

As a result, we have to try render from geometry-pixels instead of pixels-geometry

So what can we do?Squares got us a lot of mileage in

2d….maybe cubes work in 3d.

Actually a really good idea.

Descent (1994)Built world geometry from lots and lots

of cubes Each cube face stored texture

information and/or connection to an adjacent cube

Descent (1994) Render opaque faces in current cubeFor each connecting face, clip view

frustrum and recurse if appropriateThis was done with a beam tree

Descent (1994)

The GoodWalls and ceilings no longer have any

restriction on orientationNo overdraw

The BadTry building a room with a column in the

middle In general, algorithm assumes world

has spherical topology (like cubes and other convex polyhedra), does OK if the donut holes are big compared to view

Lots of time spent clipping if surfaces have much geometric detail

Could possibly do better In Descent, we’re dynamically figuring

out which surfaces are occludedWhy not do something in pre-

processing?

Dr. FunkThomas Funkhouser wrote his Ph.D

thesis on this back in ’93 www.cs.princeton.edu/~funk/thesis.pdf for a

good read

QuakeQuake does exactly this In general, we don’t need the world to

be built out of cubes, just convex polyhedra

Just like in Doom did in 2d, we can use a BSP tree to do this

Quake

ProsConstant time to determine potentially

visible polysCan use BSP to draw front to back and

eliminate overdraw

ConsGeometry is “more” staticPre calc time can grow to be enormous

Necessitates marking of certain features as “details” to keep out of VSD calculation

Big loss on doors

And onwardsThis is still an open area of researchGames today still use variations on the

portal-rendering/BSP theme to solve this problem Halo clusters BSP leaves into room size

chunks and does portals in between

So YeahThis Lecture was all about Visible

Surface DeterminationThere’s lots that I glossed over about

these engines, mostly related to actual rasterization

These days, the hardware takes care of it for us, but it’s important to be aware of what things were done.

So YeahOther really fascinating stuff going on w/

real-time gaming Level of Detail Programmable Graphics Hardware

Vertex and Pixel Shaders

AcknowledgementsPaul Constant (I ripped off his

diagrams)Adrian Perez (CMU ’01, now at Bungie

Studios)Google

Questions?