130 likes | 224 Views
Level of Detail. CS184-Sp05 Section. Level of Detail. Basic Idea Use simpler versions of an object as it makes less of a contribution Generation How to make different LODs Selection Chooses LOD based on some criteria Switching Change from one LOD to another. Switching. Popping problem
E N D
Level of Detail CS184-Sp05 Section
Level of Detail • Basic Idea • Use simpler versions of an object as it makes less of a contribution • Generation • How to make different LODs • Selection • Chooses LOD based on some criteria • Switching • Change from one LOD to another
Switching • Popping problem • Discrete Geometry LODs • No blending. Bad popping.
Switching • Blend LODs • Render LOD1 opaquely first, then LOD2 w/ increasing alpha val. • High overhead during transitions.
Switching • Alpha LODs • Only 1 LOD per object. • As metric for selection increases, transparency is increased. • No popping. • When object completely disappears, don’t need to render it at all. • Only at this point is speedup attained.
Switching • CLODs (Continuous Levels of Detail) • Huge set of LODs • Each level has 1 edge collapse (2 fewer polygons) • Edge collapse – vertex joined with another • Keep track of edge collapses to reverse (vertex split) • Can animate edge collapse for smooth transition • Problems: • Not all models look good. • Have to go through all prior edge collapses to get to a particular LOD • …
Switching • Geomorph LODs • Interpolate between 2 LODs • Remember vertex connectivity between levels • E.g., animating the edge collapse in CLODs would be a geomorph
v6 v1 v1 v7 v4 v4 v2 v3 v3 v3 v5 v5 Progressive Mesh • CLOD as described earlier • Order to collapse edges is determined by some absolute cost metric • Always collapse in same order • Store edge, adjacent faces, and vertices of adjacent faces • When an edge collapses, the 2 endpoints disappear and a NEW vertex is placed somewhere (e.g. along the old edge).
View-Dependent Progressive Mesh • View-dependent progressive mesh • Order in which we want to collapse edges is based on view • Will collapse in different orders for different views • Can’t just store in a list like w/ CLODs
Basic Alg. • First create the view-independent progressive mesh • At run-time, create a forest of LOD info • Start w/ the coarsest mesh • Try to split “best” vertex given view-dependent metric • If that split depends on splitting another vertex first, do that
v6 v1 v1 v7 v4 v4 v2 v3 v3 v3 v5 v5 Basic Alg. 1) Create PM: Mn <- Mn-1 <- … M0 2) Create forest M0 v1 v2 v3 Say our v.d. metric says to split v1 first. Can we do that? (Hint: No)
Billboards • So far, we’ve been working with meshes • Billboards • Render an image onto a polygon facing the viewer OR have several “cross-billboards” • Used in video games • Useful for simulating “special effects” • Lens flares • Switching between different LOD textures will create creases • Fix problem by using mipmaps
LOD Selection • Back to meshes • Very application oriented • Range-Based • Projected-Area Based