minicoro VS procedural-gl-js

It would be interesting to bench something extremely lightweight (like https://github.com/edubart/minicoro) against these runtimes.

By my back-of-the-napkin math, 1,000,000 coroutines would cost about 64mb + 2mb/core for stacks.. which works out to about 4x less memory than the 'winner' of this comparison, and ~30x less than go.

A single header asymmetric stackful cross-platform coroutine library in pure C.

https://github.com/edubart/minicoro

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.

Last year I released an open-source framework (https://github.com/felixpalmer/procedural-gl-js) for creating 3D terrains for web applications, you can see Uluru here: https://www.procedural.eu/map/?longitude=131.036&latitude=-2... (unfortunately the aerial imagery from our default provider isn't as high resolution as other places in Europe)

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.

Bug reports are welcome at: https://github.com/felixpalmer/procedural-gl-js/

Also the geocoding quota issue has been resolved

Yeah, the React parts of this are very minimal. I'm not really sure what using it gets you, since it just manages a single div.

The _actual_ library that does all the work is here: https://github.com/felixpalmer/procedural-gl-js

- Tiny filesize means library is parsed fast. Package size is less than THREE.js thanks to code stripping

Check it out on Github: https://github.com/felixpalmer/procedural-gl-js/

> https://github.com/felixpalmer/procedural-gl-js/

> Key features

> Batteries included elevation data. Global 3D data coverage courtesy of nasadem.XYZ

> https://www.nasadem.xyz/

Generally just a choice for the demo - in part because restricting the view distance means less data to download (thus lower cost to serve!). If you switch the phone to portrait you will be able to see the horizon.

The library itself (https://github.com/felixpalmer/procedural-gl-js) lets you configure the angle freely.

Hi HN, Merry Christmas to all!

I made this as a demonstration of the open data available from the Austrian government under the www.basemap.at project. The rendering engine is built on top of THREE.js and can be found here: https://github.com/felixpalmer/procedural-gl-js/

For those in the southern hemisphere, there is also a similar visualization of the national parks of New Zealand: https://felixpalmer.github.io/new-zealand-3d/

That's not a bug, it's Germany! The aerial imagery comes from the Austrian basemap.at dataset, which only covers Austria. If you use imagery that covers multiple countries this isn't an issue, but for this project I wanted to try out the basemap.at data. See https://github.com/felixpalmer/procedural-gl-js/ for more

The imagery comes from the Orthofoto dataset on https://www.basemap.at/ - the actual texturing is done by the Procedural GL JS library https://github.com/felixpalmer/procedural-gl-js