mapbox / martini Goto Github PK

I noticed that the errors are stored for each coordinate in the grid instead of per triangle.

The paper suggests to calculate per triangle (Section 6: "... An initial preprocessing phase allocates to each triangle a measure of how accurately it approximates the surface - the triangles error"). I believe the reason is that storing per point creates an issue where triangle A and B may share a midpoint, but triangle A has a child with a greater error than any of triangle B's children.

If you are storing the maximum error of the children of triangle A at triangle A's midpoint, triangle B will also use that error value, even though they are in separate branches of the tree and do not share that maximum error child. Maybe this depends on the order of the iteration.

It may also be ok to store the midpoint errors on each point if they are true midpoint errors (not maximized based on the children), and then descend the tree to override with children in the getMesh call.

Apologies if I'm missing something, but I noticed because I'm trying to implement in rust and that caused a discrepancy when calculating error starting from a triangle and only checking its children vs starting from that same triangle's parent.

Awesome library; I love your work! When installed from NPM, there's the main index.js file and also bundled martin.js and martin.min.js. It looks like the rollup config is still set to those names:

Did you mean to rename those to Martini too?

Cool library! I tiled a bunch of RTIN terrains together and there is a seams issue that I was unable to resolve. The edges of each mesh has an irregular number of vertices, so it is not sufficient to average each edge's height because the vertices don't line up. Adding difference thresholds (i.e. average each vertex as long as it is within some lat/lng range) will work but it results in texture stretching. Is there any plan to address seams? Included some screenshots below. I'm on a gtx 1080 getting 120fps with this many tiles.

Another method, directly applying height to a planebuffergeometry, works and is easy to stitch but I get 55fps with that method. Clearly RTINs offer an immense amount of optimization, but I don't know where to go from here with the seams issue. I could try hiding seams with skirts? Is there a better way?

Hi,
I want to overlay 3d elevation model with other datasources (we have our own wms/wfs server with vector and raster layers). Is that possiible to do that?

Thanks!

@mourner Could you please compare martini to delatin?

I need tins in Unity and may port one of the two to C#. I don't need a fast client-side generation just preparing a set of static mesh-tiles.

I'm working on a prototype module that uses this library + Mapbox elevation tiles to render QuantizedMeshTerrainData tiles in Cesium.

I've managed to get a version working that creates a mesh in Cesium, but all of the tiles are (rather hilariously) warped.

I think the issue relates to some combination of the winding order of triangles and the sorting of vertices. Cesium apparently expects triangles wound in counterclockwise order; there may be some restrictions on the sorting of vertices as well (see e.g. this example dataset). I've tried several combinations of rewinding triangles and sorting vertices to no avail.

This may be a better issue to raise in the Cesium context, but I thought I would start here: are there any guarantees on winding order given by this library? Does the pattern of artifacts in my image above look diagnostic of any particular failure mode? Perhaps a few words in the documentation about how the output mesh is structured would allay my confusion.

Hi, I see npm install @mapbox/martini on the README but I don't see the package on NPM. Perhaps it's set to private?

This is where I'm looking: https://www.npmjs.com/package/@mapbox/martini

Thanks.

Great library @mourner. I've been adapting this to simplify non-square meshes, by buffering the east and southern edges with filler values. This forms a bigger square, whatever the next larger 2^n +1 integer may be (a 225x500 mesh becomes 513x513).

To keep the algorithm from simplifying away vertices on the real edge, I fill the placeholder values with a constant, extremely low/high elevation, and then trim them away:

Two questions:

• is this worth adding into core functionality? I'm curious if we can further optimize by skipping simplification on values that are known to be placeholders.

• this strategy forms an interesting bandana pattern, where the eastern and southern edges keep a really fine detail (probably finer than necessary) where they were trimmed away. The savings might be minimal, but can we simplify those edges further?

Any plan or idea of creating contour line from this library?

Thanks for advance.

I've tried different attempts using https://github.com/andreasplesch/aframe-triangleset-component but I get this from the Mount Fuji 256 data:

Which doesn't look to me like the input image:

Mainly because of the pointy spikes.
I'm using
<a-triangleset projectdir="z" material="roughness: 0.2; metalness: 0.3; color: green" rotation="90" position="-60 -100 30" scale="1 1 1" :vertices="this.vertices" :triangles="this.triangles"></a-triangleset>

Where this.vertices and this.triangles come from a Vue component that uses the data from tile.getMesh(80) to make these attribute data.

Please advise what am I doing wrong?
Thanks for your guidance.

Elevation value of a point on hover, elevation profile of a line.

How would one go about it?-- if it can be achieved. Could restricting the model to 2d while interacting help, or can we achieve the same in 3d.

Thanks. Martini is 🔥 🔥

Edit 1: CDN support would be really appreciated for quick prototyping.

Edit 2: terrain has to be calculated by the user rather than the library, but certain front-end frameworks don't give you access to the DOM-- like Vue

Thanks, very intriguing. After the initial split, the refinement should be unique because there is only one way to split a right-angle triangle into two right-angle triangles by splitting the diagonal. So the resulting mesh can be reproduced given the same input DEM and max. error.

However, there are two options for the initial split. Currently, the diagonal from 0,0 to sizeX, sizeY is used for the initial split (https://github.com/mapbox/martini/blob/master/index.js#L159). Equally valid would be an alternative, initial split: from 0, sizeY to sizeX, 0.

In some cases, the alternative, initial split may lead to a more optimized mesh, eg. fewer triangles and there may be situations where exploring both options would be worth the (doubled) cost. Perhaps this is discussed in the original publication. In most cases, it should not matter much. It may be possible to prove that at most only a few triangles can be saved.

Consider adding an option to choose which initial split to use ? Then a user could explore both if wanted, and choose one.

davenquinn/cesium-martini#2 reports that Martini-produced meshes covering a significant angular radius appear faceted due to the low number of triangles. This is a major problem at low zoom levels in Cesium.

Right now, I am simply falling back to a height field for low-zoom tiles, but this will not show any topography if, for instance, vertical exaggeration is enabled. It would be preferable if this could be handled in the initial mesh-generation step — would it be possible for Martini to support a "max-triangle-size" optional parameter in getMesh that would force continued iteration until the legs of all generated triangles were shorter?

I could accomplish this with another loop, but it seems overly complex.

While trying to use Martini in a deck.gl terrain layer, I discovered the NPM package isn't transpiled to es5 (pure JS developers would run into syntax issues).

Could you publish an es5 version as the default along side es6 distributable?

You might find this article useful, it seems most folks are using babel (and this plugin) to do the transpiling.
Here's a snippet of their rollup config.

babel({
    // ignore node_modules/ in transpilation process
    exclude: 'node_modules/**',
    // ignore .babelrc (if defined) and use options defined here
    babelrc: false,
    // use recommended babel-preset-env without es modules enabled
    // and with possibility to set custom targets e.g. { node: '8' }
    presets: [['env', { modules: false, targets }]],
    // solve a problem with spread operator transpilation https://github.com/rollup/rollup/issues/281
    plugins: ['babel-plugin-transform-object-rest-spread'],
    // removes comments from output
    comments: false,
  }),