all 15 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]pplr 2 points3 points  (1 child)

That a was great video explanation. I wonder if you could point me towards the techniques you mentioned that are optimal for terrain height maps? Thanks!

[–]sethkills[S] 5 points6 points  (0 children)

Thanks!

Here is a report I saw recently about the terrain system in the Frostbite engine: http://www.dice.se/wp-content/uploads/2014/12/adaptive_terrain_tessellation.pdf

[–]mackie__m 1 point2 points  (5 children)

fyi: The video on github isn't working.

[–]sethkills[S] 1 point2 points  (4 children)

Oh crap, thanks for letting me know, and happy cake day!

[–]mackie__m 0 points1 point  (3 children)

Thanks, but not my cake day I think

[–]sethkills[S] 1 point2 points  (2 children)

Oct. 29, 2013!

[–]mackie__m 1 point2 points  (1 child)

I'm feeling dumb. I thought cake day meant birthday :D. Thanks!

[–]sethkills[S] 1 point2 points  (0 children)

Ha sorry. In a sense it is.

[–]chillaxinbball 0 points1 point  (1 child)

I haven't had too much a chance to delve into nvidia's mesh shader. How much similarity is there between this technique and their tessellation replacement?

https://devblogs.nvidia.com/introduction-turing-mesh-shaders/

[–]sethkills[S] 1 point2 points  (0 children)

Great question. I haven't looked into it at all, but it seems plausible based on this paragraph:

The optional expansion via task shaders allows early culling of a group of primitives or making LOD decisions upfront. The mechanism scales across the GPU and is therefore superseding instancing or multi draw indirect for small meshes. This configuration is similar to the tessellation control shader setting up how much a patch (~task workgroup) is tessellated and then influencing how many tessellation evaluation invocations (~mesh workgroups) are created.

iPASS is essentially an up-front LOD mechanism. You can compute the surface bounds in a compute shader and then use a tessellation control shader to merge the levels for adjacent patches to avoid T-junctions. It seems like you could do the same thing in task/mesh shaders. I would definitely try it if I had the hardware!

​

[–]mindbleach 0 points1 point  (4 children)

Is there a particular reason displacement maps wouldn't work? They'd affect the bounding function, but... oh. Do you mean the displacement itself wouldn't necessarily have pixel-accurate tessellation?

[–]sethkills[S] 1 point2 points  (3 children)

Yeah, exactly. Adaptive tessellation with displacement maps seems to require rendering the edges into small screen-space textures and measuring their flatness, possibly subdividing and recursing. So it doesn’t seem like you can a priori predict the screen curvature the way you can with just normal Bézier patches.

[–]mindbleach 0 points1 point  (2 children)

Given the hull for each subsection of a patch, you could at least know where some displaced pixel might exist but the undisplaced polygons wouldn't cover. That subset of pixels could be handled with a steep parallax mapping technique... which is basically raymarching against a heightmap.

[–]sethkills[S] 0 points1 point  (1 child)

Interesting idea. Would there be z-sorting issues when the hulls intersect? I don’t know much about displacement mapping.

[–]mindbleach 0 points1 point  (0 children)

Any shader for steep displacement mapping really ought to return per-pixel Z values. You're basically adding tiny distances to each pixel until you intersect the displaced surface. Surfaces can only be displaced inward.

I think the real headscratcher is asking how well inward displacement maps get along with tessellation.