Why John Carmack Drives A Ferrari John Ketchpaw

Why John Carmack Drives A Ferrari John Ketchpaw 15 -462: Computer Graphics 1 February 28, 2002

Administrative Junk ® Turn in your homework ® The Midterm is on Tuesday ® Assignment 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 (30 Hz)

Some Stats (from 1998) ®A Quake 3 level – 8 k-12 k 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. ), like you’ve been doing so far. ® An idea: Don’t draw things if they aren’t visible.

Hmmmm ® That’s ® Any not as simple as it lets on. thoughts on how to do it?

Some Methods ® Distance 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 Interiors ® For the most part, ceilings are horizontal and at standard height ® Walls are vertical ® Most walls are at right angles to each other

Enter Wolfenstein 3 D (1992) ® Wolfenstein stored the world on a grid. ® Each grid location stored a wall, a door, an object, or an enemy

“Sliver” Rendering ® Shoot a ray out for each column of pixels ® Intersections were very cheap and wellordered ® Worked 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 faster ® Suddenly, 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 viewpoint ® World is broken up into convex polygons ® Doom used this very effectively

Doom (1993)

But I want more! ® As long as we’re raycasting, we’re stuck faking it with 2 dimensions ® 320 x 200 image is 64, 000 rays ® 640 x 480 is 307, 200 rays! ® As a result, we have to try render from geometry-pixels instead of pixelsgeometry

So what can we do? ® Squares got us a lot of mileage in 2 d…. maybe cubes work in 3 d. ® 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 cube ® For each connecting face, clip view frustrum and recurse if appropriate ® This was done with a beam tree

Descent (1994)

The Good ® Walls and ceilings no longer have any restriction on orientation ® No overdraw

The Bad ® Try 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 occluded ® Why not do something in preprocessing?

Dr. Funk ® Thomas Funkhouser wrote his Ph. D thesis on this back in ’ 93 ® www. cs. princeton. edu/~funk/thesis. pdf a good read for

Quake ® Quake 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 2 d, we can use a BSP tree to do this

Quake

Pros ® Constant time to determine potentially visible polys ® Can use BSP to draw front to back and eliminate overdraw

Cons ® Geometry is “more” static ® Pre 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 onwards ® This is still an open area of research ® Games 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 Yeah ® This Lecture was all about Visible Surface Determination ® There’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 Yeah ® Other really fascinating stuff going on w/ real-time gaming ® Level of Detail ® Programmable Graphics Hardware ® Vertex and Pixel Shaders

Acknowledgements ® Paul Constant (I ripped off his diagrams) ® Adrian Perez (CMU ’ 01, now at Bungie Studios) ® Google

Questions?