visible

Uploaded from authorPOINTLite
Views:
 
Category: Entertainment
     
 

Presentation Description

No description available.

Comments

Presentation Transcript

Why John Carmack Drives A Ferrari: 

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

Administrative Junk: 

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

The Game Developer’s role: 

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: 

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): 

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): 

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.

Hmmmm: 

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

Some Methods: 

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: 

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

Building 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 3D (1992): 

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” Rendering: 

“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

Raycasting? What’s that?: 

Raycasting? What’s that?

The Result: 

The Result

So that’s great and all…: 

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: 

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): 

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?: 

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): 

Doom (1993)

But I want more!: 

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?: 

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): 

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) : 

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): 

Descent (1994)

The Good: 

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

The Bad: 

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: 

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

Dr. Funk: 

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

Quake: 

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

Quake: 

Quake

Pros: 

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

Cons: 

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: 

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: 

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: 

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

Acknowledgements: 

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

Questions?: 

Questions?