terrain rendering research for games - red3d.com · gameplay goals for a terrain engine • large...
TRANSCRIPT
![Page 2: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/2.jpg)
Lecture Agenda
• Introduction to the problem
• Survey of established algorithms
• Problems with established algorithms
• How we solved these problems
• Future work
![Page 3: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/3.jpg)
![Page 4: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/4.jpg)
Gameplay goals for aterrain engine
• Large enough to travel around for hours
• Detailed when seen at a human scale
• Dynamic modification of terrain data
• Runs at high, stable frame rates
• Need fast rotation of viewpoint
![Page 5: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/5.jpg)
Technical goals to support gameplay
• Level-of-detail management (static orcontinuous?)
• A lot of polygons (231 in un-reduced terrain,70,000+ in a given tessellation)
• Rendered polygons economically representthe terrain
• Near-field detail
![Page 6: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/6.jpg)
![Page 7: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/7.jpg)
![Page 8: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/8.jpg)
Chief terrain CLOD papers:
• Lindstrom-Koller (SIGGRAPH ‘96)
• ROAM (M. Duchaineau et al, IEEEVisualization ‘97)
• Rottger et al
![Page 9: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/9.jpg)
Geometry management
• Our previous games used variants of Lindstrom-Koller
• We wanted to switch to ROAM for increasedversatility and efficiency.
• We’ll now survey both of these systems.
![Page 10: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/10.jpg)
Lindstrom-Koller and ROAMboth use a binary triangle tree.
![Page 11: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/11.jpg)
Lindstrom-Koller algorithm
• Operates bottom-up on aheight field.
• Considers vertex-removalerror projected to theviewport.
• If the projection is small, wecan remove the vertex.
![Page 12: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/12.jpg)
Lindstrom-Koller:frame coherence
• Vertices are grouped intoblocks, sorted by error value.
• Reduces the number ofvertices evaluated eachframe.
![Page 13: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/13.jpg)
ROAM algorithm
• Operates top-down onbounding volumes.
• Considers the projection ofeach bounding volume to thescreen.
• If the projection is large, wesubdivide the volume.
![Page 14: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/14.jpg)
ROAM: frame coherence
• Two priority queues: split queue, mergequeue
• Highest-priority wedges are split andmerged to maintain equilibrium trianglecount.
• Priorities modified according to viewpointmotion.
![Page 15: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/15.jpg)
Why we were so excitedabout ROAM
• Because it’s top-down, it does notdictate the form ofyour terrain data.
• We could use terrainconsisting of Bezierpatches withdisplacement maps.
![Page 16: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/16.jpg)
The binary triangle treeis an excellent tessellatorfor curved surface terrain.
• Most people who work on Bezier surfaceterrain use rectangular subdivision.
• BTTs provide easier crack fixing and tighterresolution adaptation.
• The height map guys and the Bezier patchguys just don’t talk to each other?
![Page 17: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/17.jpg)
We implemented ROAM
• It ran slowly -- didn’t scale.
• Spent a long time trying to optimize it.
• Other game developers have had similar problems.
• Games that use ROAM-style algorithms usuallythrow away the frame-coherence portions. Thisresults in “split-only ROAM”.
![Page 18: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/18.jpg)
The Evil Feedback Loop
• The longer you take to simulate a frame, thefurther the viewpoint moves in that frame.
• Thus the algorithm has to do more worknext frame: longer simulation time.
• There’s a catastrophe point where you canno longer keep up with real time: frame rateplummets toward 0.
![Page 19: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/19.jpg)
Minor improvements to increaseROAM tessellation accuracy
• Separate wedge ascent and descent
• Child-volume bounding versus contained-vertex bounding
• We were able to decrease polygon outputby 40% for our data set.
![Page 20: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/20.jpg)
viewpoint
The problem with top-downterrain rendering systems
• The bounding volumes hide informationabout the position of the maximal error.
• In making pessimistic assumptions aboutthe projection, they sacrifice tess. efficiency.
viewpoint
![Page 21: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/21.jpg)
In an LOD’d scene, polygons tend to beroughly the same size in screen pixels.
![Page 22: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/22.jpg)
A large percentage of polygonsare small and close (50%? 60%?)
![Page 23: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/23.jpg)
ROAM hindered bythe basic nature of LOD
• We cannot get good priority bounds onpolygons that are nearby.
• Polygons that are nearby comprise 50% ofour tessellation.
• This hurts.
![Page 24: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/24.jpg)
ROAM’s running time
• The ROAM paper states it’s O(n), n = number of LOD operations per frame.
• ROAM priority queues perform sorting.
• ROAM is actually O(mlogm),m = number of triangles in tessellation.
![Page 25: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/25.jpg)
ROAM’s lack of directionalityis a problem.
• We don’t know where wedges are relative to theviewpoint; only how “distant” they are.
• Priorities of all wedges decrement at the samerate… even wedges you are moving away from.
Distance d Distance d
![Page 26: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/26.jpg)
General problem withestablished CLOD algorithms:
Weak correlation
• The algorithms use 1-dimensionalcorrelation between vertices to gain speed(within-block sorting in LK, sorted priorityqueues in ROAM)
• They spend CPU resolving ambiguities inthis 1D ordering.
• We could do better correlating in 3D.
![Page 27: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/27.jpg)
Fn(v) = pn
pn < pthresh?
• F maps the 3-dimensional argument v intothe one-dimensional result p
• There are 3 dimensions’ worth ofinformation in F but we see only the 1Dshadow of that in p.
• Every point in p represents an infinitenumber of points in F aliased together.
![Page 28: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/28.jpg)
Changing the way we thinkabout the projected error.
• Rather than evaluatingFn(v), we look at Fn
itself.
• The set of points forwhich Fn(v) = pthresh
forms a boundary surfacein 3D space.
• This is an isosurface ofthe implicit function Fn.
F(v) < pthresh
F(v) = pthresh
![Page 29: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/29.jpg)
Isosurface LOD testing
• When the viewpointcrosses into anisosurface, enable thevertex.
• When the viewpointcrosses back out,disable the vertex.
![Page 30: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/30.jpg)
How we gain efficiency
• If B is contained in A,the viewpoint cannotenter B without firstcrossing A.
A
B
![Page 31: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/31.jpg)
How we gain efficiency
• We store the isosurfacesin a tree. We onlydescend into nodes whenthe viewpoint crosses anisosurface.
• Statistically, terrains willexhibit a lot of naturalhierarchy.
• Split tree, merge tree
![Page 32: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/32.jpg)
Clustering
• At the root level of theisosurface tree we willhave thousands ofintersecting surfaces.
• We introduce extrabounding volumes tocluster these nodestogether.
![Page 33: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/33.jpg)
Clustering
• At the root level of theisosurface tree we willhave thousands ofintersecting surfaces.
• We introduce extrabounding volumes tocluster these nodestogether.
![Page 34: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/34.jpg)
Performance
• The number of node traversals is O() thenumber of LOD operations required that frame,with a slight overhead for cluster nodes. “Youonly pay for what you get (mostly)”.
• To make things extra speedy, we use sphericalisosurfaces. However, the basic algorithmworks with surfaces of any shape.
![Page 35: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/35.jpg)
Lindstrom-Koller isosurface
![Page 36: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/36.jpg)
Performance
• 231 triangles, 50k in tessellation, 12k in frustum
• Quickly moving viewpoint.
• ROAM gave us 1fps, unstable performance.
• Lindstrom better at 8fps, moderately stable.
• Isosurfaces fastest at 30+fps, very stable.
![Page 37: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/37.jpg)
Tessellation improvement
• 640x480 rendering, 3-pixel error
• ROAM-style wedges: 86284 triangles
• Direct isosurfaces: 56234 triangles
![Page 38: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/38.jpg)
Tessellation improvement
• How low an error bound can we hit with abudget of 100,000 triangles?
• ROAM-style wedges: 2.75 pixels
• Direct isosurfaces: 2.17 pixels
![Page 39: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/39.jpg)
Vertex buffers
• Pack vertices into an array that getsshipped off to the card.
• Expensive to create or modify; cheap torender.
• Difficult to use vertex buffers withdynamic LOD.
![Page 40: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/40.jpg)
Using the isosurfaces to predictmean-time-to-modification
• We can make vertex buffers out ofisosurfaces that don’t come very close to theviewpoint.
• We cluster these vertex buffers spatially sowe can do reasonable frustum culling.
• Software buffers to take care of The Other50%.
![Page 41: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/41.jpg)
Changing the basicrendering method
• Now to render the scene, we begin at theroot of the isosurface tree and work our waydownward.
• We no longer use the binary triangle tree forrendering; so we phase it out entirely.
![Page 42: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/42.jpg)
Future work
![Page 43: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/43.jpg)
Future work:The binary triangle tree?
• The binary triangle tree causes extra trianglesplits to fix cracks.
• How much overhead does this produce?
• Some algorithms like Rottger’s and Ulrich’striangulate quadtree blocks instead. They havediffering crack fixing policies.
• What is the relationship between crack fixingpolicy, tessellation density, and scene quality?
![Page 44: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/44.jpg)
Future work:A better error metric?
• Lindstrom-Koller uses vertical displacement tomeasure error. Garland/Heckbert use normaldisplacement.
• Is linear displacement even a good error metric?What are other (non-ad-hoc) options?
• We need a metric that judges the algorithm’sfinal output. (cf. PSNR)
![Page 45: Terrain Rendering Research for Games - red3d.com · Gameplay goals for a terrain engine • Large enough to travel around for hours • Detailed when seen at a human scale • Dynamic](https://reader031.vdocument.in/reader031/viewer/2022022807/5ce5f19488c993fb6e8c29b2/html5/thumbnails/45.jpg)
Future work:Batched LOD operations?
• Our LOD decision-making is fast enoughnow to be negligible for our target detaillevels.
• However our algorithm still suffers acatastrophe at high viewpoint speeds dueto the aggregate cost of all the split/mergeoperations per frame.
• Some way to perform many splits/mergesat once would be good.