Jonathan Blow Bolt Action Software jon@bolt-action.com LOD Metrics Jonathan Blow Bolt Action Software jon@bolt-action.com

Motivation Spent a lot of time on terrain research Goal: spend energy wisely Goal: Maximize simplicity and benefit Communicate what I see in the academic papers from being real far into it. Disclose the things you won’t read in anyone’s LOD paper.

Lecture Structure Goal of LOD Choosing a metric to meet that goal See how implementation details get in the way Look deeper at what our algorithms are doing Examine the role of analysis in formulating these algorithms.

I. The Goal of LOD

LOD is about reducing resource usage Usually triangle, but also textures, etc We substitute cheaper models where people wouldn’t notice the difference This is not a very formal definition

No Objective Quality Goal Scientific method: test hypothesis against world to determine truth or falsehood LOD researchers are pulling this stuff out of their ass (e.g. metric). The more complex the algorithm, the more ass-pulling is involved -> more likely it is wrong.

Objective Goal Analogy - PSNR Used widely in image processing Definition: L2-norm of the N-vector between two images.

Drawbacks of PSNR Doesn’t match human visual system e.g. Each pixel independent People are working on replacements, nobody agrees on one

The Order in which Bugs Get Fixed Things that don’t compile Things that crash Obvious functional errors Subtle functional errors that require careful analysis to diagnose and that still leave the software “pretty much working”.

II. Choosing a metric and using it

Metrics in the small vs. in the large A common metric is projected pixel error We don’t have anything in the large (analogy of PSNR)

To be fast, algs degrade tess efficiency EQS or progressive mesh - mega conservative regular samples for BTT vs TIN structure of BTT forces extra splits (crack fixing) top-down view-dependant algorithms give up tess efficiency (often without realizing it!)

Measurement of projected pixel error computation is arbitrary GH: along normal LK: along z direction Why not measure terrain along normal? Or a general mesh along local verticality? What about texture popping? Etc.

Metric as simplifier breaks down lots of complex spatial relations into e.g. a scalar algorithms try to use vertex correlation to speed things up they usually use the *scalar* and forget that all this info is available Instead use isosurfaces, big speed improvement.

III. Implementation details get in the way

Icky non-cooperation of different data types (tri, tex, light) Changes in vert positions geometry Changes in normals texture irradiance “how the scene looks”

How might this be simplified? Example of LOD’d voxel space galactic armada of signal processing

Bump mapping (and other anisotropy eg BRDF) screws us Our hardware and API implementations give us less flexibility with this kind of lighting than with old-school lambertian stuff tangent frames can only be pinned to vertices This sucks ass when combined w/ LOD.

IV. Looking deeper at our algorithms’ processes.

Edge collapse is a linear interpolation between samples. When we look at this as a filter what does it tell us? Translate bilinear filter into sequence of fundamental signal processing operations. What this does to frequency content: fold, then mirror, then transfer by 1.5*cos(x).

V. Better planning of future algorithms

Metric defines system behavior So we can tell a lot about what a system will do by thinking about the metric and the data it operates on. This can help us understand where to best focus our effort.

Example: What it means to limit projected pixel error Metric: projected pixel error Algorithm: “keep projected error near some constant” Effect: Screen-space triangles are roughly the same size

In an LOD’d scene, polygons tend to be roughly the same size in screen pixels.

A large percentage of polygons are small and close (50%? 60%?)

Why polygons tend to be the same size in screen pixels. Projected size of any delta value is roughly constant (stabilized point of algorithm’s action). /z = k Big delta values tend to be attached to big edges, small deltas to small edges.  = md; d = edge length, m = some constant

Why polygons tend to be the same size in screen pixels.  /z = k   1/z1 = k = 2/z2  = md  md1/z1 = k = md2/z2 Screen area  1/2(d/z)2 = 1/2(k/m)2 This is a constant.

Conclusions Push “metric in the small” into the realm of the frame buffer sample? (Video cards already screw the pooch at this scale so maybe we would be just hiding all our error in there) Thank-you and good night.