luna VS procedural-gl-js

Check out https://github.com/greatscottgadgets/luna and https://github.com/tinyfpga/TinyFPGA-Bootloader

What the hell, here are a bunch of half-baked ideas that I haven't made time for because I'm lazy and stressed out and exhausted:

1. Designing a protocol and air interface for an amateur radio cellular network. This started out with some spread spectrum experiments and an interest in low-probability-of-intercept (below the noise floor) communication. The idea I have now is sort of a cross between APRS and DMR using modern modulation techniques. The network would consist of amateur rooftop "cells" with internet connections, and mobile transponders that communicate with those cells. There'd be some sort of callsign or key based addressing scheme and IP-like network topology discovery. Everything will be authenticated. I'd love to have an encrypted mode, but unless the laws change, it probably isn't going to happen.

2. Open-source firmware or gateware implementation of a USB PD controller that supports entering/exiting alternate modes properly. Inspired by Kate Temkin's Luna project [1]. I got the impression that PD was out of scope for LUNA, at least for the time being, but it would be really nice to have both a USB and PD stack that could be integrated onto a small, inexpensive chip without the proprietary mess.

[1] https://github.com/greatscottgadgets/luna

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.

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/

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