Live data from Hacker News

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

techblog.geekyants.com

31–40 of 54 posts

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

#31

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.

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

#32
post #25

Earlier quoted context omitted.

You don't really have the choice with graphics either. The GPU keeps mesh and texture data in memory between frames, and I would imagine something similar happens for lighting, etc at some layer in the pipeline. Reconstructing the entire scene every time would not be feasible.

You can still hold on to references to textures and meshes you uploaded to the GPU without using a full-blown scene graph. Some state is necessary no doubt, but this seems more like unnecessary state that could be replaced by something more direct. But i don't know, i'm not familiar with three.js; the click handlers seem useful.

Regardless: the reason for having a base API be imperative is usually because it's maximally flexible and performant. By your own admission, any reactive API for 3D rendering will at least have to hold on to references to GPU objects in-between iterations, which means it could never be a truly stateless API; it would always be an abstraction over something stateful.

So given that constraint, I think it's better for the base API not to hide that statefulness behind an abstraction, and to leave the abstracting to a higher-level API

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

#33
post #7

Earlier quoted context omitted.

Agreed. Haven't checked out the code but it might because of the text labels in the first example? Last time I checked rendering text into a webgl context was basically reinventing harfbuzz or using a proper game engine like unity. Edit: So a reactive way to lay over HTML which properly hooks into the 3d context doesn't sound beyond crazy, at least for web tech standards.

Unity?

Yup thanks, typo.

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

#34
post #5
post #4

Looks very cool and there's a ton of good info here. But the final product is unusably laggy on my Dell XPS 13 i7 - not something I'd be happy to put into production. Edit - thank you for all the replies, we have now established that different hardware renders at different speeds, quite the discovery.

Ran perfectly fine on my Dell Precision with an i7-9850H.

Same here. Probably the turbo encabulator on that XPS.

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

#35
post #31

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.

The 404s from Mapbox are for elevation map tiles over the ocean where elevation is assumed to be 0.

As you pan, zoom and change the time, the url updates so you can share a permalink with others and they see exactly what you do. It looks like somehow you got an invalid timestamp (NaNt should be a timestamp: 1614115393106t). Will dig more into this. Thanks.

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

#36
post #16

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.

> i think it'd be simpler to not fuss with these layers at all

You should check out some example code for react-three-fiber (e.g. https://codesandbox.io/embed/r3f-bones-3i7iu). If you have any experience with writing raw webgl, it will become abundantly clear that something is gained by going through three.js before returning to React's more declarative style.

Most of the savings in the example are coming from three.js itself (not r3f), which is maybe the key point: three.js offers much more than a scenegraph, which is why it's worthwhile (check out the official examples to get an idea: https://threejs.org/examples/). Webgl as an API doesn't even really talk about 3d objects for the most part; the language it provides is primarily about moving data around in buffers. The difference in possible time savings in three.js vs webgl is on the level of writing in C vs an assembly language.

And once you're building an application with a non-trivial amount of state mutation (on which the view depends)—you're faced with the same dilemma as traditional web dev and the DOM, hence the desirability of react-three-fiber.

That said, I think it would be super interesting to see a three.js alternative that was 'natively' reactive/declarative, because I'll readily admit the tower of abstractions involved in writing a react-three-fiber app has its downsides. (Then again, I consider three.js to be a rare gem, know of nothing comparable in terms of simplicity/quality for building 3d apps, and would be [pleasantly] surprised to see anything like the above anywhere in the near future.)

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

#37
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…

Thanks for the helpful repo and linking to it! Been looking fwd to playing w react-three-fiber...

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

#38
If you like this type of stuff, Paul Henschel shares similar content on Twitter [1] and it's absolutely amazing. For example, incredible stuff like this [2].

[1] https://twitter.com/0xca0a [2] https://twitter.com/0xca0a/status/1357346054635544584

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

#40

A guide to rendering photo-real terrain with React + Three.js

At first the thought of combining React with Three.js left me scratching my head - but upon closer inspection the added abstraction actually makes sense and it's quite elegant. Thanks for sharing.

Also I had no idea what "frijoles" was, but I now have recipes bookmarked.

Post reply on HN