Conversation
…ing the development i did no intermediate commits, so in this first commit all the following functionality is included: * allow MTK terrainRGB-tiles encoding with parameters: [6553.6, 25.6, 0.03, 10000.0]. In our opinion 0.1 for height-steps is to rough. * create a TerrainSourceCache.js class which is similar to SourceCache.js and holds all the terrain-tiles used for the 3D-mesh. If a terrainRGB tile is used in both, terrain & hillshading, it is loaded twice. This makes the whole process much more easy. * create a 3d-mesh in raster_dem_tile_worker_source.js with the martini library. * rewrite the draw logic to render all layers, except symbols, into a framebuffer. This framebuffer a later used as a texture onto the 3d-mesh. * rewrite symbol rendering to use 3d-coordinates. This is done with an extra a_ele shader parameter, because the z-value of the a_pos variable is already used for other things. * add the third dimension into the collision index. * create a terrain.html test-page.
This is done with an extra framebuffer in which all tile coordinates are rendered in an encoded rgb value. Dont know why, but this framebuffer looks very inperformant. As advantage, grabbing coordinates from screen is very fast. It may help to render the framebuffer only every 100ms instead of every requestAnimationFrame? This logic is currently used in * map.project * map.unproject. Other usecases are: * elevate camera over terrain * use in mouse-events * use in queryRenderedFeatures
|
This is an excellent thing to see here. I want to mention that the aims and structure of this implementation are similar to that of the Cesium-Martini project, which has a working but prototypical implementation at Macrostrat. Some of the problems and potential solutions might be shared, especially as one of the major goals of the Cesium-based work is to get Mapbox vector maps working atop the platform. |
|
I agree with Daven that this is exciting to see. I haven't looked through this PR's changes yet, but one note is that it might be worthwhile to keep the mesh generation and mesh rendering loosely coupled if possible. Especially for high DPI screens with many tiles rendered, calling Martini on every tile can use significant CPU. Additionally, this approach uses extra network bandwidth because it requires downloading the heavier raster DEM files to create the mesh on the client. If mesh generation and mesh rendering are loosely coupled, support for something like Quantized Mesh could also be implemented, where the mesh is generated on the server side, which avoids extra CPU usage on the client and allows for smaller downloads. I have a demo of rendering these quantized mesh tiles in deck.gl here if anyone's interested. |
|
Once this PR #30 is merged, we could use the same logic to load tiled DEMs 🚀 |
|
Cool!!! I'd be happy to take if for a spin somehow and help testing this... But I need to migrate to maplibre first first, which requires #30... :-) |
|
A few explanations:
And my plan is to have a usable beta ready in the next few weeks. |
|
Hi, great job with the terrain! I've looked at your code and for the moment all layers except the Symbol are drawn over terrain as a texture, is this going to be how those layers are rendered or do you want to in the future render them over the terrain directly, not just using a texture? |
|
Hi, background, fill, linestring, raster & raster-dem render to texture, symbols, circle & fill-extrude are render ontop. I think this is the way to go. |
|
Yeah, you are right, its also those layers that are rendered over the terrain in mapbox I think, can't wait to see the final results! |
|
OK! I've migrated my project to maplibre :-) (Although not yet published to production) |
Yes, you can use any kind of
If the early-alpha stage, as it is now, is completed it will be great to create some unit-tests :D |
|
So the 3D Code is currently already useable, but because it is my first experience in programming computer graphics, i am not sure if the implementation is state of the art. Some of the things to validate/discuss:
After the code is approved, i will start on performance and testing. |
|
I'd love to help, but I don't have the knowledge in either... :-( I can help test it though, probably :-) is there anything special I need to do in order to see 3D with the code in your branch? |
|
Simply add a |
|
First and foremost, thanks a lot for all the effort invested in this, please don't take my criticism negatively, I just want to help push this, nothing more. I can't stress this enough... I've created the following stackblitz:
The following is my observations:
I left the link to maplibre-gl.js in the index.html file so one can easily switch between the versions. Thanks a lot again! |
|
Here's how our initial testing looks :-) 3d-test-dead-sea.mp4 |
|
Hello Harel, thanks for your tests! 1 & 2: I will have a look into your stylesheet whats going wrong. And great to see, that it basically works on mobile devices! |
|
As suggested in the meeting today:
Thanks again @prozessor13 !! |
|
Just an FYI for merging this into main, so I don't clutter up a new PR. I think this still breaks heatmap. I commented on it here ( prozessor13#46 ). I was able to get it working with terrain disabled in that thread, but the elevation wasn't right with terrain enabled. |
|
@prozessor13 please resolve conflict so the tests can run. |
|
@prozessor13 do you want to move the code in this PR to a branch under this repo? This way the guys here can help with tasks such as merging, conflict resolution etc. What do you say? |
|
@prozessor13 I created a terrain3d branch in this repo to coordinate the merge process: https://github.com/maplibre/maplibre-gl-js/tree/terrain3d |
|
Closing in favor of #1022 |
|
Great, Thx! I currently working on performance to render the world with mapPitch=85. This is necessary to render tiles in respect to earth-radius. Without this you see Dubai from the peak of a mountain in Austria, which does not make any sense. Regards! |
12 participants
A working prototype, which adds 3d-terrain to maplibre-gl with the following features:
Already done:
Still open:
Nice to have, but not on my agenda:
showTileBoundaries&showCollisionBoxes.Need Help:
This code is already a work in progress! There are a some of
FIXME-3Din code, also this is my first experience in webgl, so i am looking forward for feedback.Also this code is not a copy of mapbox-gl 2.0, i initially looked onto the first 3 commits of mapbox-gl 2.0 at 8.Dec.2020, and than i started my work with a very different approach of implementation. For example:
all 3d is done with 3d-coordinates. mapbox uses 2d coordinates and calculates the 3d dimension in the shader.