1 KIPA Game Engine Seminars Jonathan Blow Ajou University December 2, 2002 Day 6

2 Level-of-Detail Method Overview Traditional Purpose: Speed Boost Ideal: Render a fixed number of triangles always –Doesn’t matter how far your view stretches into the distance –Diagram of pixel tesselation Object detail / triangle count as a function of distance

3 Future Purpose: Geometric Antialiasing Discussion of scenes with many small objects far away In a rendering paradigm like MCRT we get a certain amount of antialiasing for free When projecting geometry onto the screen, we do not; we need to implement something that provides antialiasing for us

4 Level-of-Detail Methods Static mesh switching Progressive mesh Continuous-LOD mesh Issues involving big objects (static and progressive mesh not good enough?)

5 Static mesh switching Pre-generate a series of meshes decreasing in detail Switch between them based on z distance of the mesh from the camera –Perhaps be more analytical and switch based on max. projected pixel error? –Nobody actually does this because it is far too conservative

6 Progressive Mesh Generate one sequence of collapses that takes you from high-res to 1 triangle Dynamically select number of triangles at runtime Works well with modern 3D hardware since you only modify a little bit of the index buffer at a time.

7 Progressive Mesh Disadvantages Relies on frame coherence (bad!) Interferes with triangle stripping and vertex cache sorting (they become mutually impossible). High code complexity, and it makes everything else more complicated, and adds restrictions to everything else –Example of normal map generation restricted to object space

8 Continuous Level-of-Detail Algorithms Lindstrom-Koller, ROAM, Rottger quadtree algorithm Dynamically update tessellation based on estimate of screen-space error Crack fixing between adjacent blocks, etc

9 Continuous LOD Example of binary triangle trees There are other formats (quadtree, diamond, etc) but the ideas are similar

10 Continuous LOD Disadvantages Extremely complicated implementations Slow on modern hardware Extreme reliance on frame coherence (bad!) Not conducive to unified rendering (hard to make work on curved surfaces, arbitrary topologies)

11 Continuous LOD Has a lot of hype in the amateur and academic communities Is currently not competitive with other LOD approaches This is not likely to change any time soon

12 LOD Metrics

13 Introduction We need an effective way to benchmark / judge LOD schemes –The academic world is not really doing this right now! We need a standard set of data with comparable results –University of Waterloo Brag Zone for image compression

14 LOD Metric? We often create metrics for taking each small step in a geometric reduction We don’t have a metric for comparing a fully reduced mesh with the source model or another reduced mesh Because our mesh representations are so ad hoc

15 Image Compression guys have a metric (even though they know it’s not that good) PSNR measures difference between compressed image and original They know it has problems (not perceptually driven) and are working on a better metric But at least they have a way of comparing results, which means they are sort of doing science!

16 Metric ideas “Sum of closest-point distances” –Continuous, which is good –Very expensive to compute –Non-monotonic (!), which is bad Monotonic for small changes, usually, which might be good enough Ignores texture warping, which is bad –Unless we try it in 5-dimensional space Ignores vertex placement –Important for rasterization (iterated vertex properties!) –Example of big flat area Ignores cracks in destination model

17 Lindstrom/Turk screenspace LOD comparison Guide compression of a mesh by taking snapshots of it from many different viewpoints and PSNR’ing the images This can work but PSNR is not necessarily stable with respect to small image-space motions

18 Lindstrom/Turk screenspace LOD comparison (Talking about paper, showing figures from it)

19 The Fundamental Problem Our rendering methods are totally ad-hoc; we have 3 different things: –Vertices –Topology –Texture A metric that uniformly integrates these things is very difficult.

20 Complexity of metric The more complicated a metric is, the more difficult it is to program correctly, ensure we are using it correctly That our simplest possible metric should be something so complicated … that is a bad sign.

21 Compare with Voxels Voxel geometry representations can basically use something like PSNR directly; no need for complicated metrics Lightfields can also (though it’s a little harder)

22 “Digital Geometry Processing” Work by Peter Schroeder at Caltech, and many others Attempts to develop DSP-like ideas for geometry manipulation Heavy use of subdivision surfaces

23 (Overview of subdivision surfaces)

24 How DGP works Apply a scaled filter kernel to the neighborhood of a vertex Like wavelet image analysis in its multiscale aspects But unlike wavelets/DSP in that the inputs/outputs are not homogeneous –What exactly is the high-pass residual after a low-pass filter? This is because of that whole topology-different- from-vertices thing

25 Actual effective DGP would be …? I don’t know. (It’s a hard problem!) Spherical harmonics would work, for shapes representable as functions over the sphere

26 Solutions/Details

27 What I Use Garland/Heckbert Error Quadric Simplification Static Mesh Switching I want to do a unified renderer this way (characters, terrain, big airplanes, whatever) People seem to think crack fixing is hard but it is actually easy –Maybe that’s why people haven’t tried this yet?

28 Discussion of Garland/Heckbert Algorithm (whiteboard)

29 Garland/Heckbert References “Surface Simplification Using Quadric Error Metrics” “Simplifying Surfaces with Color and Texture using Quadric Error Metrics”

30 G/H is useful also if you are making progressive meshes It just tells you how to collapse the mesh; doesn’t dictate how you will use that information.

31 Review of GH Algorithm In code (looking at the code)