visibility cs 446: real-time rendering & game technology david luebke university of virginia

Visibility

CS 446: Real-Time Rendering& Game Technology

David LuebkeUniversity of Virginia

Real-Time Rendering 2 David Luebke

Happy Valentines Day!


Bittersweets: Dejected sayings

• I MISS MY EX• PEAKED AT 17• MAIL ORDER• TABLE FOR 1• I CRY ON Q• U C MY BLOG?• REJECT PILE• PILLOW HUGGIN

• ASYLUM BOUND• DIGNITY FREE• PROG FAN• STATIC CLING• WE HAD PLANS• XANADU 2NITE• SETTLE 4LESS• NOT AGAIN


Bittersweets: Dysfunctional sayings

• RUMORS TRUE• PRENUP OKAY?• HE CAN LISTEN• GAME ON TV• CALL A 900#• P.S. I LUV ME• DO MY DISHES• UWATCH CMT

• PAROLE IS UP!• BE MY YOKO• U+ME=GRIEF• I WANT HALF• RETURN 2 PIT• NOT MY MOMMY• BE MY PRISON• C THAT DOOR?


Demo Time: Ken Arthur


Homework

• The pitch, round 2– Many ideas way too hard

• Art assets • (Much) character animation• Elaborate AI/gameplay

– Some of my favorites so far:• Gallery • Mariokart• Pirates (but just the ships)• Combat billiards• Orb (a la marble madness)• Waverace

– Too hard:• Total War• (Full-blown) RPG• Ninjas• UVA v. VaTech

– Yes to:• Terrain LOD, mocap data,

NPR, Shadows– No to:

• Combat animations, AI, big worlds– Out-of-the-box ideas?


Project preview

• Next 48 hours: – Pitch a few more ideas on forum– Submit “signup sheet” by e-mail

• List 3 project ideas you’d be happy to work on• I assign groups on Thursday based roughly on interest overlap

– Note: I assign groups, not project ideas!

– Assignment 3: • Groups build a basic engine• Groups propose their final idea

– Later may reorganize groups, allow 3rd-party engines


5 Steps to Efficient Rendering

• Step 1: reduce #vertices/triangle• Step 2: reduce overhead of each vertex• Step 3: recognize the existence of the vertex cache• Step 4: display lists (deprecated re: performance)• Step 5: learn about the hardware

• Meta-step 0: profile and analyze code


Other things you should know

• Most interesting stuff in OpenGL isn’t in red book– Extension registry

• http://oss.sgi.com/projects/ogl-sample/registry/• Extensions you should know:

– ARB_multitexture– EXT_framebuffer_object– ARB_occlusion_query– ARB_point_sprite– ARB_texture_rectangle– ARB_draw_buffers– ARB_texture_float (_framebuffer_float, _half_float_pixel, etc)– ARB_depth_texture– ARB_vertex_buffer_object (_pixel_buffer_object)


Other things you should know

• Most interesting stuff in OpenGL isn’t in red book– Extension registry

• http://oss.sgi.com/projects/ogl-sample/registry/

– Developer sites• http://developer.nvidia.com • http://www.ati.com/developer • Find demos, tools, tutorials, presentations, white papers


Visibility Calculations

• Motivation– Avoid rendering redundant geometry

• Complements LOD, potentially even more powerful

– Basic idea: don’t render what can’t be seen• Off-screen: view-frustum culling• Occluded by other objects: occlusion culling


Motivation

• The obvious question: why bother?– Off-screen geometry:

solved by clipping– Occluded geometry:

solved by Z-buffer

• The (obvious) answer: efficiency– Clipping and Z-buffering take time linear to the number

of primitives


The Goal

• Our goal: quickly eliminate large portions of the scene which will not be visible in the final image– Not the exact visibility solution, but a quick-and-dirty

conservative estimate of which primitives may be visible• Z-buffer& clip this for the exact solution

– This conservative estimate is called the potentially visible set or PVS


View-Frustum Culling

• An old idea (Clark 76):– Organize primitives into clumps– Before rendering the primitives in a clump, test a

bounding volume against the view frustum• If the clump is entirely outside the view frustum, don’t render

any of the primitives• If the clump intersects the view frustum, add to PVS and render

normally


Efficient View-Frustum Culling

• How big should the clumps be?– Choose minimum size so:

cost testing bounding volume << cost clipping primitives

– Choose minimum size so primitives can be rendered efficiently • At least 500 triangles/clump on today’s hardware

– Organize clumps into a hierarchy of bounding volumes for more efficient testing

• If a clump is entirely outside or entirely inside view frustum, no need to test its children


Efficient View-Frustum Culling

• What shape should bounding volumes be?– Spheres and axis-aligned bounding boxes:

simple to calculate, cheap to test– Oriented bounding boxes converge

asymptotically faster in theory– Lots of other volumes have been proposed

• Capsules, ellipsoids, k-DOPs– …but most use spheres or AABBs.


Cells & Portals

• Goal: walk through architectural models (buildings, cities, catacombs)

• These divide naturally into cells– Rooms, alcoves, corridors…

• Transparent portals connect cells– Doorways, entrances, windows…

• Notice: cells only see other cells through portals


Cells & Portals

• An example:


Cells & Portals

• Idea: – Cells form the basic unit of PVS– Create an adjacency graph of cells– Starting with cell containing eyepoint, traverse graph,

rendering visible cells – A cell is only visible if it can be seen through a

sequence of portals• So cell visibility reduces to testing portal sequences for a

line of sight…


Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA


Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

?

?


Cells & Portals

A

D

H

FCB

E

G

H

B C D F G

EA

X

X


Cells & Portals

• View-independent solution: find all cells a particular cell could possibly see:

C can only see A, D, E, and H

A

D

H

FCB

E

G

A

D

H

E


Cells & Portals

• View-independent solution: find all cells a particular cell could possibly see:

H will never see F

A

D

H

FCB

E

G

A

D

CB

E

G


Cells and Portals

• Questions:– How can we detect whether a given cell is visible from a

given viewpoint?– How can we detect view-independent visibility between

cells?

• The key insight: – These problems reduce to eye-portal and portal-portal

visibility


Cells and Portals: History

• Airey (1990): view-independent only– Portal-portal visibility determined by ray-casting

• Non-conservative portal-portal test resulted in occasional errors in PVS

– Slow preprocess– Order-of-magnitude speedups



• Teller (1993): view-independent + view-dependent– Portal-portal visibility calculated by line stabbing using

linear program• Cell-cell visibility stored in stab trees • View-dependent eye-portal visibility stage further refines PVS

at run time– Slow preprocess– Elegant, exact scheme



• Luebke & Georges (1995): view-dependent only– Eye-portal visibility determined by intersecting

portal cull boxes– No preprocess (integrate w/ modeling)– Quick, simple hack– Now-archaic public-domain library: pfPortals


pfPortals Algorithm

• Depth-first adjacency graph traversal– Render cell containing viewer– Treat portals as special polygons

• If portal is visible, render adjacent cell• But clip to boundaries of portal!• Recursively check portals in that cell against new clip

boundaries (and render)

– Each visible portal sequence amounts to a series of nested portal boundaries

• Kept implicitly on recursion stack


pfPortals Algorithm

• Recursively rendering cells while clipping to portal boundaries is not new– Visible-surface algorithm (Jones 1971):

general polygon-polygon clipping• Elegant, expensive, complicated

– Conservative overestimate (pfPortals): use portal’s cull box

• Cull box = x-y screenspace bounding box• Cheap to compute, very cheap to intersect

visibility cs 446: real-time rendering & game technology david luebke university of virginia

Documents

ideas way

project ideas youd

box ideas

oni assign groups

opengl isnt

interesting stuff

terrain lod

zbufferthe obvious answer