Ferrari Parts · Parts Department (920) 725-4688 / . Ferrari Parts
Why John Carmack Drives A Ferrari John Ketchpaw 15-462: Computer Graphics 1 February 28, 2002.
-
Upload
austin-clarke -
Category
Documents
-
view
213 -
download
0
Transcript of Why John Carmack Drives A Ferrari John Ketchpaw 15-462: Computer Graphics 1 February 28, 2002.
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?