-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support 3D terrain meshes #1489
Comments
I'm curious about the technical feasibility of this. Having true 3D ability would be huge for us and we are willing to contribute developer resources towards making it happen. Is that a pipe dream, or could this feature be implemented in a reasonable timeframe? |
We are definitely going to take on the challenge of implementing 3D terrain for GL JS eventually. It wasn't a priority so far though compared to other pushes such as data-driven styling. It's certainly a complicated task that can take several months of effort to get right, both on the client and the server side. @ansis do you have any ballpark thoughts on the effort/challenges involved here? |
FWIW, we're looking at solutions for this right now and this would likely bring us over to Mapbox. Particularly with the Google Earth API deprecated, I suspect we're not alone in this. Chris |
A good source of inspiration could be www.eegeo.com Since Mapbox GL uses OpenGL it seams faisable, does not? But I see two different cases in 3D render:
IMO the most in the scope is the second option since render pipeline could be reused. Terrain elevation
Display 3D meshes
|
The first two steps will be terrain rendering and 3D extrusion (e.g. simple 3D buildings). A rough sketch for the second is in the |
Just out of curiosity, with extruded buildings out, will this be addressed with or before z-axis offsets come to labels/etc? The two seem intimately tied, at least when defining the behavior of the z-axis in general. For example, it seems impractical to force z-offsets to be absolute (from sea level), so it may also be necessary to define offsets relative to a particular layer. |
@mike-marcacci from a technical standpoint, z-offset properties are much easier to implement (and therefore will likely come first) because the property only affects that specified layer; projecting/wrapping the whole map based on a layer is a much more complicated beast. |
Not sure if anyone notice this, as of now, you can add "some sort" of 3D terrain with the native fill-extrusion.
Not a smooth terrain mesh, just extrude polygon with contour data, making all terrain look like they went through "slope irrigation". Negative elevation data are forced to 0, will be cover by map layer even if you manage to cut through z-axis. |
Further implementation of fill-extrusion-color to improve the visual of it
|
Sketching out my thoughts on the design of this from a GL/Style Spec perspective. Motivation
Primarily in styles like Design
GL SourceIf the Digital Elevation Model is transmitted as a raster heightmap (as opposed to a vector TIN) then the Mapbox Terrain RGB can already be used with the GL source If people have their own DEM they could upload this as a single large 1 band GeoTIFF (potentially with non Byte type) where pixel values are heights. The same way you upload a large RGB GeoTIFF and it's converted into a raster tileset, uploading a 1 band GeoTIFF would convert it to a GL LayerA new Mapbox GL In this way you could have multiple Extrusion types like the current
If the first implementation is as above it will only support a digital terrain model (ground surface). With lidar or photogrametry it's common to have a digital surface models (ground + trees + buildings etc), which has limitations if saved as a hightmap like the terrain-rgbs. eg. you can't texture the side of buildings, and you can't show 3D trees where the leafs form a ball above the surface since. It would be nice to future proof the design to support this, if possible. Concepts
I feel it's important to get the terminology right, there are a lot of terms to throw around: terrain, 3d, elevation, dem, dsm, mesh, terrain-rgb, and related terms which have their meanings in GL like hillshade, extrusion and z-offset. In the design proposal above I've used If the design is initially for the draped hightmap implementation rather than a 3D mesh, it's good to consider if the terminology will be a good choice even when the full 3D mesh implementation happens. I've sketched this out at master...andrewharvey:andrewharvey-elevation-layer
|
I'm a big fan of this functionality, would love to see it added. Cesiumjs does it pretty well but is pretty slow and sometimes unstable, and labels are terrible. A true future-proof approach would indeed be able to use non-monotone meshes (in height direction e.g. overhangs), and to project textures onto those meshes. That gets hairy really quickly though. A more standard approach would be to use monotone height meshes, which is much quicker to implement and much easier. Extra detail can then be added using standalone meshes (buildings, trees, overhanging cliffs), which can be pruned and shown with varying levels of detail depending on zoom level. Generating this mesh from a height map has the drawback of having a fixed resolution (e.g. 30m). Using a Triangular Irregular Mesh (TIN) solves this issue: it is still monotone in height direction but can vary its detail depending on the terrain. A drawback is that implementing some sort of Level Of Detail (LOD) that uses the previously-downloaded data is harder. There are algorithms with reasonable running times for generating such TINs. Cesium uses the quantized mesh format to store them. A possibility for transferring even less data would be to leave out the vertex linking information (so just specify the vertex coordinates), as a TIN is a 2D delaunay triangulation (looking at it from the top), so the triangles can be calculated relatively fast. This would also allow an easy way of implementing LOD, as you can just add some vertices and recalculate the delaunay triangulation where necessary (similar algorithm as TIN generation can be used). Hope this helps, would be interested to discuss this some more. |
Hi, any news about this? |
@Shongololo that feature is at #3993 |
Terrain extrusions.. Getting closer, are we not? |
It's looking like they are on it. Can you Mapbox reveal us something more? |
This is very interesting – I'm wondering if it'd be possible to load terrain meshes from external sources such as ESRI or a self hosted service. |
May I ask what the current status of terrain is? Since reading the post by Abhishek "Taking our maps to the next dimension" I note that he hasn't worked for Mapbox since February. The MARTINI approach is fantastic and opens a lot of doors....where are we with this? I am loving Mapbox and it's capabilities, unfortunately, the lack of support for vertical terrain and coordinates is restricting my ability to use Mapbox for many projects as they become more focused around environmental and urban planning issues. If Mapbox could provide a method for consuming any of the open-source data terrain formats, 3D Tiles or using terrain mesh/rasters it would be a huge benefit. |
Slightly adjacent: the deck.gl project provides data visualizations on top of a Mapbox GL JS basemap. As of version 8.1 you can use the The downside with this approach is that since terrain is extruded, the Mapbox GL basemap is hidden, so you can't actually combine the two without re-implementing the map rendering. I'm working on code to do that, but I agree it would be preferable to have support in Mapbox GL JS. |
Support for 3d terrain added as part of the v2 release: #10160. |
This looks amazing! A few questions:
|
Yes, through the Carbon SDK.
It works directly with all available vector styles, you can see it with a vector style in this example: https://docs.mapbox.com/mapbox-gl-js/example/free-camera-path/.
If it's under in the mapbox-rgb or terrarium format, then yes. |
This is HUGE team - congrats on the release 🙌 |
Newbie question, whats the Carbon SDK? 😀 I literally cant find anything with that name. |
Didn't find a lot of results by googling it either. Anyway I was more asking if support will be native in the Mapbox Android & iOS SDKs? I guess it will 🙂 Playing a bit with the terrain, it seems that changing the style with map.setStyle breaks it (terrain no longer loads). Anyway, congratulation guys, 3D vector tiles really look great! Adding support for 3D tiles would be amazing as well. |
@timautin yes, native support is coming!
Yes, that's expected unless you directly add it as part of your style (Either through mapbox studio which 3d support is coming, or added as a root style property), otherwise you need explicitly add it to the style like so: https://github.com/mapbox/mapbox-gl-js/blob/main/test/integration/render-tests/fill-extrusion-terrain/flat-roof/style.json#L12_L31 |
Awesome! Looks like the time to give up Google Maps SDK is finally pretty close 🙂 . Until now I've stuck with them for their (imho) unmatched satellite imagery despite the complete lack of new features / bug fixes for years, but your new 3D vector tiles are really appealing!
I just set up a quick and dirty code without a JSON style and tried to add a toggle satellite / streets style button. But it doesn't matter, it was just for a quick test. |
Looks awesome! Is there any way to set the elevation of linestrings, so that they hover above the ground by a set distance? |
@xsanda not currently, but we're working on this! |
Are you working on showing a globe rather than a plan as well (or planning to do it)? That would be the cherry on the cake 😃 |
This is great, except for the license change right before delivering it... :-( |
True. By the way does the new licence implies that even if we host all the data on a private server, we'll still have to pay the same as if we were using Mapbox's servers? If so, setting up a Mapbox map on a private server (say without an internet access) would no longer be allowed, right? |
Anyone knows how to generate the mapbox-rgb based Terrain tile? What kind of input data are required? |
I successfully used something similar to this but here's another solution with rio: https://github.com/syncpoint/terrain-rgb ;) |
Nice tutorial, it uses https://github.com/mapbox/rio-rgbify which produces an MBTiles you can upload to your Mapbox account. I'm still praying that one day you can just upload your single band GeoTIFF to Mapbox and it'll handle converting it into Terrain RGBs automatically. 🙏 |
This would be very useful. We're displaying things like overhead electrical lines and in some places they span across valleys so it would be great to see them in "mid-air" rather than clamped to ground. Similarly would be nice to have lines slightly above the ground for normal over-head lines, so the options of:
Loving the feature though, looks fantastic and very easy to integrate! |
Thank you guys for a great job so far. Do you have any plans on adding rendering support of 3D terrain meshes like google maps earth and cesiumjs are doing?
Example:
http://betaserver.icgc.cat/cesium/Girona3D.html
The text was updated successfully, but these errors were encountered: