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

2. Administrative Junk  Turn in your homework  The Midterm is on Tuesday  Assignment 5 (roller coasters) should go out Wednesday

3. 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.

4. 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)

5. 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.

6. 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.

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

8. 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

9. More thinking  If we know certain things about the geometry of the world, we can come close.  What’s common about interiors?

10. 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

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

12. “Sliver” Rendering  Shoot a ray out for each column of pixels  Intersections were very cheap and well- ordered  Worked great on my 286  You’ll fall in love with raycasting later in the semester

13. Raycasting? What’s that?

14. The Result

15. 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

16. 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?

17. 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

18. 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

19. Doom (1993)

20. 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

21. So what can we do?  Squares got us a lot of mileage in 2d….maybe cubes work in 3d.  Actually a really good idea.

22. Descent (1994)  Built world geometry from lots and lots of cubes  Each cube face stored texture information and/or connection to an adjacent cube

23. 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

24. Descent (1994)

25. The Good  Walls and ceilings no longer have any restriction on orientation  No overdraw

26. 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

27. Could possibly do better  In Descent, we’re dynamically figuring out which surfaces are occluded  Why not do something in pre- processing?

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

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

30. Quake

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

32. 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

33. 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

34. 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.

35. So Yeah  Other really fascinating stuff going on w/ real-time gaming  Level of Detail  Programmable Graphics Hardware  Vertex and Pixel Shaders

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

37. Questions?