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(techblog.geekyants.com) |
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
OpenGL used to have a true immediate mode where you called a function for each triangle vertex, and you didn't need shaders or buffers. That mode is not present in WebGL.
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.
You don't, it might be a case of VRML cargo-culting or something.
https://en.wikipedia.org/wiki/VRML
While the DOM has some issues which makes React handy, Three.js and its "display list" have none of these problems, but I guess shoving React somewhere will translate in a better conversion for the authors of that article...
There are tons of good examples of how to use react-three-fiber on Codesandbox - https://codesandbox.io/search?query=react-three-fiber&page=1
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)
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 elevation model to drop off a meter gradually from the center to the edges.
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.
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.
[1] https://twitter.com/0xca0a [2] https://twitter.com/0xca0a/status/1357346054635544584
Also I had no idea what "frijoles" was, but I now have recipes bookmarked.
Edit - thank you for all the replies, we have now established that different hardware renders at different speeds, quite the discovery.
Edit: Here's something. You could probably hack something up that would check if the vendor name includes AMD or NVIDIA, or something. Might be fragile though https://developer.mozilla.org/en-US/docs/Web/API/WebGLRender...
https://github.com/gpuweb/gpuweb/issues/445
However, an issue is that many mobile GPUs don't support them.
react-three-fiber isn't a magic bullet that will make all web 3D things fast. You still have to be sensible. It does make it much easier to prototype things though, and a lot of the time performance is great. And if it isn't then most of the code is quite straightforward to move to pure WebGL.
But why not just have the live WebGL thing on each page itself?
I could embed the live WebGL, or a codesandbox embed. I might do that eventually.
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.)
Similarly, around 2013 threeQuery (threejs + jquery) was becoming somewhat popular too (it had a jquery "chain" api like syntax). It's good to see people experiment and attempt to improve developer efficiency. Who knows what new tricks will be discovered and what kind of benefit and new approaches will be created! However, I mostly agree with you.
I find threejs to be one of the most enjoyable libraries to work with (and its codebase is simple and beautiful too). I also highly recommend to everybody that wants to go into 3d graphics to dedicate some effort and learn the actual fundamentals (eg webgl, opengl, metal, matrix math, quaternions, etc). This way you gain domain specific knowledge that is applicable across platforms and across time. Abstractions are not future-proof, they are recycled and change according to the latest trends in development. Domain specific knowledge stays with you forever! If there is an intermediate ground on which people can meet (eg start with react-three or three.js and then dive deeper) that's a win too. Recently I have been advocating that web devs can start learning 3d graphic concepts by just playing with... CSS to familiarize with some of the concepts and then move from there. This way one can avoid all the overhead around the gl statemachines or various libs and focus on the basic concepts first
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
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.