Recreating Real-World Terrain with React, Three.js and WebGL Shaders
techblog.geekyants.com
Recreating Real-World Terrain with React, Three.js and WebGL Shaders
1–10 of 54 posts
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#2A guide to rendering photo-real terrain with React + Three.js
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#3That looks neat but why would you need a react-style reconciler to render a webgl scene? It's immediate mode...every frame is rendered according to the latest state available. What is even being reconciled?
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#4Looks 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.
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#5Looks 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.
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#6Looks 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.
Yes I understand that different hardware renders things at different speeds, thanks for your input? I'm saying that if something runs like shit on my $3,000 laptop I wouldn't be comfortable putting it into production for a user base that likely has, on average, far less.
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#7That looks neat but why would you need a react-style reconciler to render a webgl scene? It's immediate mode...every frame is rendered according to the latest state available. What is even being reconciled?
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.
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#8That looks neat but why would you need a react-style reconciler to render a webgl scene? It's immediate mode...every frame is rendered according to the latest state available. What is even being reconciled?
Yes, but they are using Three.js, which provides a scene graph structure, basically wrapping WebGL in a retained mode.
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#9Earlier quoted context omitted.
Ran perfectly fine on my Dell Precision with an i7-9850H.
Yes I understand that different hardware renders things at different speeds, thanks for your input? I'm saying that if something runs like shit on my $3,000 laptop I wouldn't be comfortable putting it into production for a user base that likely has, on average, far less.
Runs silky smooth on my 2015 MBP - it’s possibly a system specific issue
Re: Recreating Real-World Terrain with React, Three.js and WebGL Shaders
#10That looks neat but why would you need a react-style reconciler to render a webgl scene? It's immediate mode...every frame is rendered according to the latest state available. What is even being reconciled?
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 why/whether this coupling is actually necessary