
Martini: Real-Time Terrain Mesh Generator - mourner
https://observablehq.com/@mourner/martin-real-time-rtin-terrain-mesh
======
pastrami_panda
Cool! I just want to point out that the urge to generate an irregular mesh can
be quite hardware unfriendly if you want to tesselate the terrain dynamically
around a moving camera. The well cited papers on Geometry Clipmaps highlight
this. The point is that it can be more efficient to focus on feeding the GPU
pipeline in an efficient manner instead of focusing on rendering as few
triangles as possible. Irregular meshes thrashes the cache if you
retriangulate them all the time (since no data can be reused). A uniform grid
has many advantages, unless you're only interested in rendering one static
view, then irregular meshes are great!

~~~
kuzehanka
Yep. A uniform mesh of flat quads with a vertex shader doing the displacement
will perform better.

~~~
mourner
Would love to learn more, since it seems counter-intuitive — are there any
studies / benchmarks on this for modern hardware? Why would a uniform mesh
with, say, 10x more triangles perform better if it's not updated often (e.g. a
few times a second)?

~~~
pastrami_panda
Mainly because GPU throughput is increasing much faster than CPU throughput.
Spending cycles removing triangles doesn't matter if the GPU can just churn
through them like nothing. In the context of a moving camera you want to reuse
as much data as possible between terrain updates. With regular nested grids a
ton of data can be reused, only the height needs updating as you move the
grids around (and height can be reused between adjacent grids half the time if
they have a power of two resolution relationship).

But baking irregular meshes into a tree-structure could be powerful too I
suppose, I'm not that familiar with algorithms involving them. All of this is
highly dependant on actual size of terrain and LOD requirements, terrain
rendering is a deep rabbit hole.

~~~
mourner
Yeah, it's a thin balance, and to me as someone without years of experience in
graphics programming, GPU feels like such a blackbox — hard to predict what
will be the actual bottleneck until you implement an approach fully, with
real-world loads, and even then it's hard to assess, especially with such
variety of GPU performance characteristics on different devices.

So what's simpler / easier to implement in a given system will play an
important role, and so are any additional things you want to do with the
height data like collision detection, querying, data analysis etc. Anyway,
that's a super-exciting topic to learn more about! Thanks a lot for all the
thoughtful comments.

------
mourner
Author here — thanks for checking this out, everyone! Happy to answer any
questions in comments.

~~~
jacobolus
Firefox looks a bit wacky:
[https://i.imgur.com/ivLwxyG.png](https://i.imgur.com/ivLwxyG.png)

Vs. Chrome: [https://i.imgur.com/Go0mt1K.png](https://i.imgur.com/Go0mt1K.png)

~~~
mourner
Wow, what OS / device is this on? Looks fine on Firefox 68 / OS X for me.

~~~
jacobolus
Firefox 68.0, OS X 10.14.6

~~~
mourner
Really weird! No idea what could be the culprit. Some GPU bug maybe?

------
tomcam
Worked on my iPad, which is unusual for demos like that. And wicked fast! The
article is beautifully written and the information presented with astonishing
clarity. Well, well done.

~~~
doctoboggan
Out of curiosity, are you running iPadOS 13 with the "Desktop Class" browser?

~~~
layoutIfNeeded
Works on my iPhone with iOS 12 too.

------
throwaway13337
Very cool. Seems to have some striking similarity to the quadtree map used for
efficient position querying of variably complicated areas.

[https://en.m.wikipedia.org/wiki/Quadtree](https://en.m.wikipedia.org/wiki/Quadtree)

~~~
mourner
Oh yes, quadtree-like structures come up all the time when you're dealing with
maps. E.g. check out this algorithm I came up with for finding pole of
inaccessibility of a polygon:
[https://github.com/mapbox/polylabel](https://github.com/mapbox/polylabel)

~~~
kuzehanka
Hey mourner, didn't know you're on HN. Just wanted to say thanks for all the
great work on mapbox-gl and the side libraries you've released!

~~~
mourner
Thank you!

------
isoprophlex
This is a wonderful presentation of results and code, well done! Very nice to
read.

------
Uehreka
This was a pleasure to play with on an iPad. Excellent work.

------
mattlondon
Lots of errors here on mobile:

RuntimeError: renderer could not be resolved

Browser: Mozilla/5.0 (Linux; Android 9; Nokia 7.1) AppleWebKit/537.36 (KHTML,
like Gecko) Chrome/75.0.3770.143 Mobile Safari/537.36

~~~
mourner
That's surprising. Does it help to do a hard reload? Are any other WebGL demos
working?

~~~
ingenieroariel
I got an error too but I am running Firefox/Sway/Nixos/AMD GPU and WebGL has
never worked:

    
    
      Content Security Policy: Couldn’t process unknown directive ‘prefetch-src’
      THREE.WebGLRenderer 107 three.min.js:187:462
      Error: WebGL warning: <SetDimensions>: Failed to create 
      WebGL context: WebGL creation failed: 
      * tryNativeGL
      * Exhausted GL driver options. three.min.js:190:415
      Error: WebGL warning: <SetDimensions>: Failed to create 
      WebGL context: WebGL creation failed: 
      * tryNativeGL
      * Exhausted GL driver options. three.min.js:190:440

------
edoo
I love stuff like this. This is like the 5th or 6th time I've seen 3D
techniques from the past become real time relevant. The first one I saw was
from the 50's and someone just happened to explore it and it happened to run
great on modern hardware. I bet there is a ton of stuff out there like this. I
do wish there was more of a benchmarking standard. It is great that it now
runs in 20ms on his laptop but that says nothing about the actual
computational requirements.

~~~
mourner
Everyone's hardware is different, so I've included notes about computational
complexity of the algorithm in the notebook too.

------
kmnt
Is there a method for dealing with seams between RTIN tiles of different
levels of detail? It looks like it would be complicated to implement.

~~~
wnkrshm
I think I've seen a rather pragmatic hack that has been used in Google Earth
for their stitching of terrain: They simply add a kind of skirt at the
boundary of each square chunk [0], so that there aren't any white/black
pixels. There may be some artifacts between LoDs but they soon disappear when
the next chunk gets more refined.

Edit: I think the Google terrain skirts were slanted, rather than falling
straight down, so two neighbouring skirts intersect in a V.

[0] [https://www.researchgate.net/figure/A-terrain-chunk-a-
withou...](https://www.researchgate.net/figure/A-terrain-chunk-a-without-
skirts-and-b-with-skirts_fig2_235952216)

~~~
kmnt
Funny hack, I would have expected some perfect seam algorithm from google.

------
colechristensen
If you are getting your data from an image, you already have a mesh (a quad
mesh from pixels which could be broken down into triangles a few different
ways).

Anybody know about best/easy/fast/interesting algorithms for doing the
opposite of the post and "compressing" the data eliminating triangles for a
prescribed error or some other metric?

------
aerodog
any raster imagery overlay come with this badboy? mourner is a maps legend -
hats off to him

~~~
mourner
Thank you! Someone just forked the notebook, adding satellite texturing —
that's a really cool aspect of Observable (and I'll probably merge it back):
[https://observablehq.com/@rzoller/martin-real-time-rtin-
terr...](https://observablehq.com/@rzoller/martin-real-time-rtin-terrain-mesh)

~~~
kuzehanka
That made it really clear that texture resolution trumps mesh resolution.
Dialling down the mesh detail slider results in very little perceptual
difference, but the blurry texture always stands out.

The non-textured demo actually looks _better_. Nothing that can't be fixed by
stitching higher resolution sat imagery though!

------
_bxg1
Fantastic. Love the demo and the animation.

------
thrax
This is slick.

