Today

1. Today • Runtime LOD • Choosing a model to display • Progressive meshes and view dependent simplification • Spatial Data Structures Overview CS 638, Fall 2001

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. Structure Induced on Surface • Pair-wise merging forms hierarchy • binary tree of vertices • also a binary tree of surface regions CS 638, Fall 2001

15. Example:Initial Vertex Neighborhoods CS 638, Fall 2001

16. Example:99% of vertices removed Regions of constant color contain vertices that have all been contracted to a single vertex CS 638, Fall 2001

17. Example:99.9% of vertices removed CS 638, Fall 2001

18. 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

19. 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

20. 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

21. View Dependent Example Sorry for the fuzz, I couldn’t find a better picture CS 638, Fall 2001

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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 • E0 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