CS-378: Game Technology Lecture #11: Visibility Prof. Okan Arikan University of Texas, Austin Thanks to James O’Brien, Steve Chenney, Zoran Popovic, Jessica Hodgins V

Cell Portal Algorithms Identify portals that we can see through Portals connect two disconnected cells How can we use portals for efficient visibility ? Luebke and Georges (1995)

Potentially Visible Cells Generating For any two cells, find out if they are visible Occluders ? Tradeoffs Memory Computation Aggressive / Conservative Quake

Algorithms for Combining Occluders Occlusion Horizons work for 2.5D scenes Great for cities and the like An extension exists for relatively simple 3D scenes (eg bridges) Green’s Hierarchical Z-Buffer builds occluders in screen space and does occlusion tests in screen space Requires special hardware or a software renderer Zhang et.al. Hierarchical Occlusion Maps render occluders into a texture map, then compare objects to the map Uses existing hardware, but pay for texture creation operations at every frame Allows for approximate visibility if desired (sometimes don’t draw things that should be) Schaufler et.al. Occluder Fusion builds a spatial data structure of occluded regions

Problems These methods mostly work for indoors Natural scenes Terrain A forest ? (can not find good occluders) Halo

Slight Digression Level of Detail (LOD) Have multiple representations of the same object Draw the simplest one you can get away with Lord of the Rings

Terrain Terrain is obviously important to many games As a model, it is very large Creating every point explicitly by hand is not feasible, so automated terrain generation methods are common When rendering, some of the terrain is close, and other parts are far away, leading to terrain LOD algorithms

Representing Terrain The base representation for terrain is usually a height field z=f(x,y) for (x,y) within the limits of the space Precludes things like caves and overhangs, which must be treated specially There are two common ways to represent the function f(x,y) Explicitly store the value of f(x,y) for a discrete grid of (x,y) locations Generally interpolate (bilinear) or triangulate to get points not on the grid Easy to figure out what the height of the terrain is at any given (x,y) Expensive to store the entire terrain Store a polygonal mesh Cheaper if the terrain has large flat areas Harder to figure out what the height is under the player (have to know which triangle they are in)

Terrain is Easier! Assumption: We are starting with a height field defined on a regular grid Assume it’s a square to make it easier We can mesh it by forming triangles with the data points The data is highly structured Every data point has the same number of neighbors Every triangle can be the same size Hence, the tree of possible simplifications is very regular Still, multiple possibilities exist for the triangulation and the simplification operations

Rendering Terrain Coarser Finer

Rendering Terrain Adaptive Representation Bilinear Patch

Rendering Terrain Adaptive Representation T-Junction

Triangle Bintrees Binary trees in which: Each node represents a right-angled isosceles triangle Each node has two children formed by splitting from the right angle vertex to the midpoint of the baseline The leaf nodes use vertices from the original height field Another way to build a spatial partitioning tree, but particularly well suited to simplification algorithms Easy to maintain neighbor information Easy to avoid T-vertices

Triangle Bintree Example

Bintree Data Structure Parent and child pointers Neighbors A left neighbor, a right neighbor, and a base neighbor Note that the base and right angle give us a way to orient the triangle Neighbors are not necessarily at your own level Later, error bounds that say how much variation in height there is in your children

Cuts

Neighbors 5: left neighbor 6, right neighbor 9 6: left neighbor 8, right neighbor 5 7: left neighbor 8, base neighbor 10 8: base neighbor 6, right neighbor 7 9: base neighbor 5, left neighbor 10 10: base neighbor 7, right neighbor 9 Note that 8 is 6’s left neighbor but 6 is 8’s base neighbor If you are someone’s left/right/base neighbor they are not always your right/left/base neighbor In other words, neighbors need not come from the same level in the tree 6 5

Not All Cuts Are Created Equal Note the T-vertex - causes cracks in rendering

Generating Cuts Cuts are generated by a sequence of split or merge steps Split: Drop the cut below to include your children Merge: Lift the cut up above two children To avoid T-vertices, some splits lead to other, forced, splits An LOD algorithm chooses which steps to apply to generate a particular triangle count or error rate

A Split A split cuts a triangle in two by splitting its base edge If the base edge is on a boundary, just split, as shown If the base edge is shared, additional splits are forced Add a new triangle to the mesh 6

Forced Splits Triangles are always split along their base Hence, must also be able to split the base neighbor Requires neighbors to be mutual base neighbors If they are not base neighbors, even more splits are needed Simple recursive formulation

Merges A diamond is a merge candidate if the children of it’s members are in the triangulation The children of the 7-10 diamond below are candidates Look for parents of sibling leaf nodes that are base neighbors or have no base neighbors Reduces the triangle count

Refinement LOD Algorithm Start with the base mesh Repeatedly split triangles until done Stop when a specific triangle count is reached, or … Stop when error is below some amount To guide the split order, assign priorities to each split and always do the one with the highest priority After each split, update priorities of affected triangles Sample priority: High priority to splits that will reduce big errors What is the complexity of this? (Roughly) A similar algorithm works by simplifying the mesh through merge operations. Why choose one over the other?

Refinement Notes If the priorities are monotonic, then the resulting terrain is optimal Monotonic: Priorities of children are not larger than that of their parent Priorities can come from many sources: In or out of view, silhouette, projected error, under a vehicle, line of sight, … Does not exploit coherence: As the view moves over the terrain, the triangulation isn’t likely to change much We should be able to start with the existing triangulation, and modify it to produce the new optimal triangulation

Projected Error Metrics Idea is to figure out how far a sequence of merges moves the terrain from its original correct location Measured in screen space, which is what the viewer sees Start with bounds in world space, and then project the bounds at run-time World space bounds are view independent Projected screen space bounds are view dependent

Performance Bottlenecks Storing and managing priorities for out-of-view triangles is a waste of time Do standard frustum culling to identify them Sending individual triangles is wasteful Build strips as triangles are split and merged Naively, at every frame, wedgies must be projected, new priorities computed and the queues re-sorted Use the viewer’s velocity to bound the number of frames before a priority could possibly make it to the top of a heap Delay recomputation until then Priority queue: Bin priorities to reduce sorting cost At low priorities, order within bins doesn’t matter

Additional Enhancements Stop processing after a certain amount of time Easily done: just stop processing the next split or merge Result no longer optimal, but probably not bad Cost of dual queue algorithm depends on the number of steps required to change one mesh into another Check ahead of time how many steps might be required If too may, just rebuild mesh from scratch using refinement algorithm Can get accurate line-of-sight or under-vehicle height by manipulating priorities to force certain splits

Combining Indoors and Outdoors ? Halo 2