Recreating Real-World Terrain with React, Three.js and WebGL Shaders • Hacker News Board

Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders

#51

Post by tppiotrowski » Wed, Feb 24, 2021, 8:10 PM UTC

onion2k wrote: post #31

tppiotrowski wrote: post #24

Excellent write up. I've been using elevation models for the past few months to create real time shadows overlaid on slippy maps using WebGL. [1] One thing I learned is that if you really want to recreate "real-world" terrain you have to account for the curvature of the earth. Uluru is over 3km wide and I estimate your image is around 5km. Across this distance the earth will curve 2 meters so you could modify the ele…

That's ace when it loads, but modifying the time on the bar at the bottom of the screen makes the shadow disappear. I get a NaN in the URL which is presumably related (eg https://shademap.app/#47.62769,24.44286,4z,NaNt ). Chrome 88.0.4324.182, OSX, no plugins to speak of. There's a bunch of 404s from Mapbox (eg https://api.mapbox.com/v4/mapbox.terrain-rgb/3/3/6.pngraw?ac... ) but no other console errors.

My date/time code only worked with US date MM/DD/YYYY and not DD/MM/YYYY. Fixed now.

And to think 50% of my traffic this month has been from Europe. A lot of users I won't be getting back...

Thanks for the bug report.

Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders

#52

Post by pmayrgundter » Wed, Feb 24, 2021, 8:56 PM UTC

onion2k wrote: post #29

codetrotter wrote: post #27

Earlier quoted context omitted.

When I went to your site, the “screenshot coming soon” for each of them caught all of my attention so I didn’t notice the fork on codesandbox link. But why not just have the live WebGL thing on each page itself?

I'm writing something to generate screenshots at the moment. They'll be there fairly soon. I could embed the live WebGL, or a codesandbox embed. I might do that eventually.

+1 for embed live WebGL

Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders

#53

Post by mlsarecmg » Tue, Mar 02, 2021, 8:22 AM UTC

esperent wrote: post #46

onion2k wrote: post #26

react-three-fiber is a really nice library to make web 3D things with. Three.js is brilliant, but there's a metric ton of boilerplate to get complicated things up and running. react-three-fiber just shuffles that away so you can concentrate on building a graph out of components. I've been getting up to speed with it for a little while and I've been chucking things I've learned in to a Github Pages site - https://onio…

I haven't followed r3f development for the last six months or so, but previously I tested a couple of examples that were available as both r3f and pure three.js. I tested them on my old, slow mobile - and there seemed to be a big difference, with r3f much slower. When I brought this up with the devs, they have waved it away saying it's because the demos were running in dev mode (or something similar). However, I have…

r3f does not have a performance overhead, it is literally zero. rendering is done in threejs purely, react only takes care of managing the scene. but it can, in situations where the app faces a lot of load, outperform three easily, because it is scheduled, just like a virtual list outperforms a generic list.

Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders

#54

Post by mlsarecmg » Tue, Mar 02, 2021, 8:25 AM UTC

gw wrote: post #16

brundolf wrote: post #10

Earlier quoted context omitted.

Three.js has an imperative/stateful API for constructing and updating objects, not dissimilar to the DOM. So if your state lives in a separate place, then just like the DOM, you'd have to imperatively patch the view state to keep it in sync. Adding a layer that does this syncing automatically makes a lot of sense to me. Doing it through React seems a little bit odd... but I haven't looked closely enough to understand…

That makes sense, but it seems like a case of building an abstraction to solve a problem caused by another abstraction. If a scene graph creates a new chore for me that necessitates yet another dependency, i think it'd be simpler to not fuss with these layers at all. That's a choice i don't have with the DOM.

that is not what is happening here. you can see the real difference here: https://twitter.com/0xca0a/status/1282999626782650368

it allows you to create self-contained components. that alone will eradicate so much boilerplate and complexity. it has a real pointer event system. it takes care of managing the scene reactively, it disposes of objects it does not need any longer.

you use this for the same reason you would use react for the dom. r3f is not a wrapper that duplicates the threejs export catalogue, it is a renderer/reconciler.