Why John Carmack Drives A Ferrari

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 Developers role

• Everyone wants games to approximate the vision
  of the designers as closely as possible.
• It is the developers job to figure out how to
  make the hardware do it.

4
The Game Developers 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 cant get away with just drawing
  all the surfaces with a z-buffer (or painters
  algorithm, etc., etc.), like youve been doing so
  far.
• An idea Dont draw things if they arent visible.

7
Hmmmm

• Thats 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.
• Whats 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
• Youll fall in love with raycasting later in the
  semester

13
Raycasting? Whats that?
14
The Result
15
So thats 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 werent 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 were raycasting, were 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, were 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

29
Quake

• Quake does exactly this
• In general, we dont 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
• Theres lots that I glossed over about these
  engines, mostly related to actual rasterization
• These days, the hardware takes care of it for us,
  but its 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?