Some Questions about crest

[huwb]

Just came across this while searching for something and was confused why it would be closed with no reply!! Eventually remembered that we moved to email. I'm going to post my reply for future reference / in case others find these questions when searching the issues..

---

Hi there,

Here are my answers to the best of my understanding:

1. Yes we could. It is a bit annoying though to implement the original article because the geometry LODs are manually stitched together, and things like T-junctions are handled manually (complex, tedious, inefficient). The original work also relies on per-frame upload from CPU to GPU (tedious, complex, potentially inefficient if not implemented carefully). Finally, because our vertex layouts match 1:1 at the transitions between LODs, we can use a simple interpolation of the shape data. Without this, it is painful to get a perfect transition between LODs. It's hard to describe concisely why this is the case, but the problems arise when a vert in a hi-res LOD sits above a diagonal edge in a lo-res LOD - here the vert height needs to be the average height of the two verts of the edge, not the average of the 4 surrounding verts. This is subtlely different and will result in z-fighting, and this problem took us a while to understand. McGuire performs the interpolation manually to ensure the verts that lie over an edge in the next LOD get the precise correct height:

"To eliminate discontinuities in elevation between grid resolutions, I use an explicit form of "trilinear" (MIP-map) interpolation. Vertices interpolate vertically towards the next lower-detail MIP level so that they exactly match the next resolution at the edge of a grid patch."

2. Our patches have strictly no overlap - this is convenient for the reasons i list on the slides. We choose to compose the geometry from patches as they can be frustum culled which is efficient, although McGuire reported minimal speedup from patches. One direction for future work would be to instance the patches to reduce draw calls. I've left it as is for simplicity/laziness :).

3. Yes good question, it took us a while to figure out there is overlap in mcguires work. He doesn't mention it! I'm certain it is there - it is required because the LOD geometry snaps to different resolutions and gaps would open up without it (to see roughly what this looks like, run our crest project in unity and disable "Smooth LOD" using the onscreen debug overlay, and look for the gaps). After puzzling for some time we realised mcguire uses overlaps to hide them. Look very closely at that the top image in this figure, at the boundaries between LODs: http://4.bp.blogspot.com/-wZrpKfO3YMU/U0lX7WrRxEI/AAAAAAAABfA/bnXyIIXXRZY/s1600/2014-03-29_004_terrain_r997_g3d_r4283.jpg . At the lod transition you can see zfighting in the higher res geom - sometimes verts are visible, sometimes not. This is because the hi- and lo-res geometry overlap and mcguire is rendering the visualisation with z-testing enabled, so they z-fight. This z-fighting is ok for terrain (i guess?) but disturbing for specular shading on water - this reason and the other reasons listed in our slides motivated us to eliminate overlaps between patches in our solution.

Hopefully the above makes sense or at least serves as good pointers for further thinking!