I was involved in building the interactive story map using deck.gl that you can view at https://3dtiles.carto.com
It’s really cool to have access to all this amazing data! Shout out to Google for working with us to bring support to multiple open source rendering engines.
We worked on providing an integration with deck.gl to make it easy to combine 3D tile data with interactive visualizations. Happy to answer any questions!
Night trains are great! Do you have to transfer in Regensburg? There used to be a direct Prague-Amsterdam night train going through Berlin. I met some weird people on it, great times :)
Sorry, code is not public. My initial business model was to offer the shade layer as a drop in for any Leaflet, Mapbox, Google Map so companies like AllTrails, Strava, Gaia GPS could use it in their apps but selling's hard. Now I'm leaning a bit towards just releasing an app with offline mode.
Great link, thanks. Horizontal scrollbar tripped me out a little bit though...
Nice writeup, I always like it when the shaders are highlighted like this. I got started in a similar way 7 years ago and have been making 3D terrains with THREE.js & WebGL since.
The real fun begins when you need to implement some sort of Level-of-Detail system and streaming in data to give the illusion of high detail everywhere without sacrificing performance.
Great visualization and approach with compressing the tile data. Do you have a comparison of how much smaller the payload ends up being compared to simply sending PNG files?
I use PNGs to encode elevation data in my 3D mapping library (https://github.com/felixpalmer/procedural-gl-js/) and this does a pretty good job of compressing the data, for example in the ocean the PNG files are also very small as the image is mostly black. Different use case I now as your data is much more sparse, but I wonder how close the PNG compression would be compared to your approach.
I don't have the exact size comparison between this approach vs PNG compression, but i guess the difference would be similar to the difference between DEFLATE vs brotli.
I'm curious about what you just asked of me though, i will make the actual measurements, and will update this page with the results when i got time.
Great thanks - perhaps obvious, but worth running the PNGs through something like pngcrush.
I'm thinking about it the other way also, that is could your approach be used to reduce the size of DEMs encoded as PNGs. While I can see brotli being more efficient, by not using a image compression algorithm you perhaps lose out on exploiting the 2D nature of the data, as if I understood correctly when you're compressing the data you treat the tile as a 1D blob of binary data.
I wrote the underlying 3D library, but React isn't my specialty, so I don't know if this is deemed best practice. Seems to work though and is nice and extensible, allowing the API to be proxied if and when the component changes
Oh boy, this brings back some fond memories from around 2013-2015.
Around that time I wrote very similar 3D map library (using three.js and cdlod-type approach for terrain rendering) and created custom AngularJS directives for similar purposes like your React library.
Sadly, my code was closed source and the startup I was working in went bankcrupt and my code went with it.
I don't mean to pick on you here, but seems to work is about the best anybody can do these days when talking about Javascript libraries. It's a little depressing at times.
Really nice, any plans on showing this on integrating 3D maps? You might be interested in my project, Procedural GL JS: a mobile-first 3D mapping engine with emphasis on user experience. Live demo here: https://felixpalmer.github.io/procedural-gl-js/ (I've also posted separately in this thread).
