280 likes | 447 Views
Today. Runtime LOD Choosing a model to display Progressive meshes and view dependent simplification Spatial Data Structures Overview. Selecting LOD Models. For any given frame, we have to decide which model to display for each object
E N D
Today • Runtime LOD • Choosing a model to display • Progressive meshes and view dependent simplification • Spatial Data Structures Overview CS 638, Fall 2001
Selecting LOD Models • For any given frame, we have to decide which model to display for each object • Assume that we have a discrete set of models for each object, at varying resolutions • Option 1: Choose each model for each object independently based on some error tolerance • Typically assume error depends on distance from viewer or similar • The current standard practice: fast, simple • Potential problem: You still might have too many polygons, in total • Option 2: Choose a number of polygons you can display, and find a set of models that lead to minimum error • Ensures near constant frame rate, but harder to implement CS 638, Fall 2001
LOD Switching • Switching is the process of changing the model used for an object • Leads to popping - the sudden visual change from frame-to-frame • Particularly poor if the object is right at the switching distance – may flicker badly • For switching based on distance from viewer, there are several options: • Leave the popping but try to avoid flicker: Textbook Ch 4.9 • Show a blended combination of two models: • Image blend – render two models with alpha < 1 • Geometric blend – define a way to geometrically morph from one model to the next, and blend the models • Have more models that are so similar that the popping is not evident CS 638, Fall 2001
Fixed Cost Rendering • Independent model selection causes problems if the scene complexity varies greatly • Consider a chair object: The amount of detail you can use in a classroom is different to that in a lecture hall • In games, biggest problem is in character rendering: • You may be facing two or twenty enemies at any time • The designer does not know ahead of time how to set the switching thresholds to optimize the appearance • Typically reduce detail to make sure that the worst case is tractable, which adversely affects quality of best case • Solutions are algorithms that fix the cost and find the best set of models to meet that cost CS 638, Fall 2001
Approximate Bin PackingFunkhouser and Sequin 93 • Assign a cost and a benefit with each model of each object • Maximize the benefit subject to a maximum total cost • Continuous multiple-choice knapsack problem – NP-complete • Approximation algorithm can get within a factor of 2 of maximum benefit with low running time • Define Value=Benefit/Cost • Sort possible models based on Value, repeatedly insert highest Value model that increases cost, removing higher detail versions if in the set, until cost met • A modified algorithm exploits coherence between frames by starting with previous set, and incrementing and decrementing detail level until finished CS 638, Fall 2001
Fix Cost Example Target Cost: 2000 Final Set: 1a, 2c, 3a Note: As stated, some objects may not be drawn (e.g.. if cost was 1000, object 2 would not be drawn) CS 638, Fall 2001
Limitations of Static Models • The LOD schemes we have discussed assume a fixed set of models • There are reasons to improve upon this: • Objects that are both near and far at the same time, such as terrain, must have varying LOD over a single surface • Static representations waste resolution on back-facing polygons - they are view-independent • Different machines have different processing power - hard to adjust LOD switching appropriately • We desire models that adapt to context: • Viewer location, viewer direction, machine load, … CS 638, Fall 2001
Progressive Meshes (PMs) • Store more than just final approximations • Sequence of contractions • Implicitly, corresponding intermediate approximations • Re-encode as progressive mesh (PM) [Hoppe] • Start with the final approximation • Reverse of contraction sequence is split sequence • A single vertex is split into two, and triangles are created • Can reconstruct any intermediate model • Allow for progressive transmission & compression • Textbook chapter 4.12 CS 638, Fall 2001
PM Details • Modification to contraction operation: • Make a record of which vertices were contracted • Record information to reverse the contraction • Original vertex locations, where the edges go, normals, … • Store final approximation and the sequence of contraction records • Implicitly have a many meshes as there were contractions • At run time, perform contractions until target number of triangles, or until error bound is met • Various optimizations to reduce storage cost • For example, always contract to one of the original vertices CS 638, Fall 2001
Improving PMs • Progressive meshes fix the order of contractions • Still a fixed sequence of meshes • Based on an error metric that ignored runtime context • We would like to be able to vary the contraction order • If we have a view dependent error metric we will want a different collapse sequence depending on the view • Want less error at silhouettes, more in front facing, don’t care about back facing • For terrain, we want to contract distant edges first - care about how big error appears on screen CS 638, Fall 2001
Structure Induced on Surface • Every vertex on approximation corresponds to • A connected set of vertices on the original - all the vertices belonging to edges collapsed to this vertex • Hence a region on the surface: the union of neighborhoods • Initial conditions • every vertex set is a singleton, every region a neighborhood CS 638, Fall 2001
Structure Induced on Surface • A contraction merges corresponding vertex sets • remaining vertex accumulates larger surface region • When merging regions, can link them by mesh edge • as shown on left hand side CS 638, Fall 2001
Structure Induced on Surface • Links within single region form spanning tree • links within all regions form spanning forest • any contraction order within regions is (topologically) valid • Regions always completely partition original surface CS 638, Fall 2001
Structure Induced on Surface • Pair-wise merging forms hierarchy • binary tree of vertices • also a binary tree of surface regions CS 638, Fall 2001
Example:Initial Vertex Neighborhoods CS 638, Fall 2001
Example:99% of vertices removed Regions of constant color contain vertices that have all been contracted to a single vertex CS 638, Fall 2001
Example:99.9% of vertices removed CS 638, Fall 2001
Vertex Hierarchies • After the entire mesh has been contracted down to a single point, all the vertices lie in a tree • Generally, stop sooner and get a forest • A set of trees, one per final vertex • We can talk about a cut through the tree • A curve that never crosses a descendent of an edge it’s already crossed CS 638, Fall 2001
Cuts and Valid Models • If we contract every edge below a cut, we get a valid approximation • Vertices just above the cut are said to be active • Different cuts give different approximations • The vertex hierarchy encodes dependencies • Better than PMs, because there is no fixed order to perform the contractions • Each sub-tree can be treated independently, because no collapses in one sub-tree depend on collapses in other sub-trees • But have to be careful of mesh folding over itself CS 638, Fall 2001
View-Dependent Refinement • Use an error metric that depends on the viewing direction • Use a cut through the vertex hierarchy as the approximation • incrementally move the cut between frames[Xia-Varshney, Hoppe, Luebke-Erickson] • move up/down where less/more detail needed • relies on frame-to-frame coherence - best approximation probably doesn’t change much from one frame to next • can accommodate geomorphing [Hoppe] • More flexibility than discrete LOD, but more overhead • Have to re-assess approximation at every frame, figuring out where to add detail and where to remove it CS 638, Fall 2001
View Dependent Example Sorry for the fuzz, I couldn’t find a better picture CS 638, Fall 2001
View Dependent Addendum • The entire world can be one vertex tree • Good for very large models such as stadiums • Can build strips out of the vertices as the cut is moved • Speeds rendering • Also works for error metrics involving lighting reproduction • Don’t want to simplify near specularities, for instance • Not used in games (to my knowledge) • Too slow, and mesh changes on every frame, so hard to utilize vertex arrays and other speed optimizations CS 638, Fall 2001
More On Error Metrics • Always include a geometric component: • Vertex-Vertex distance • Vertex-Plane Distance • Point-Surface Distance • Surface-Surface Distance • May include attribute metrics • Aim to preserve pixel colors • Components for normal vectors, texture coordinates… CS 638, Fall 2001
Vertex-Vertex Distance v3 • E=max(||v3-v1||, ||v3-v2||) • Works during topological changes • Vertex clustering, Vertex pair • Rossignac and Borrel 93, Luebke and Erikson 97 • A loose metric for collapse type operations • Vertices don’t move very far, but surface deviation may be high v2 v1 CS 638, Fall 2001
Vertex-Plane Distance • Store a set of planes with each vertex • Error based on distance from the vertex to the planes • Merge the plane sets when vertices are merged • Tries to keep vertices near original surface • Ronfard and Rossignac 96 • Store planes, use max distance • Error Quadrics – Garland and Heckbert 96 • Quadratic form instead of planes, use sum of square distances b c a CS 638, Fall 2001
Point-Surface Distance • Measure the distance from a set of points to the simplified surface • Point set representative of original surface • Use sum of squares distances • Hoppe 93 and 96 • Approximation to surface-surface distance • Expensive to compute CS 638, Fall 2001
Surface-Surface Distance • Bounds the maximum distance between the input and simplified surfaces • Tolerance volumes – Gueziec 96 • Simplification Envelopes – Cohen/Varshey 96 • Hausdorf Distance – Klein 96 • Mapping Distance – Bajaj/Schikore 96, Cohen et. al. 97 • Arguably best measures, but most expensive to compute CS 638, Fall 2001
Error Metric Notes • A good metric allows you to transform error in object space into error in screen space • Simplifies decision of which model to display • Note that the metrics can be very different • Consider an edge-swap: • E=0 at verts and edges • E0 everywhere else • Metrics that look only at vertices or edges will give this a zero error • Run-time metrics may take view into account CS 638, Fall 2001