React Renderer for Three.js • Hacker News Board

Re: React Renderer for Three.js

#121

Post by mlsarecmg » Mon, Aug 16, 2021, 6:48 AM UTC

tuckerconnelly wrote: post #95

miklosme wrote: post #5

When AR/VR finally happens, UI developers will have to deal with complexity from a completely different paradigm. For me, React's biggest strength has always been its ability to organize complexity into a manageable order. Combine this with the large pool of developers and extensive ecosystem, I think React will be the go-to tool for AR/VR apps. For this reason, I'm super hyped for R3F.

I really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

React is not based on the dom, R3f merely expresses regular threejs which works as an object graph. Three is the usual choice for 3D on the web, if you use it once you'll see that it is also quite natural. There is no conflict between the two and react certainly doesn't change any rules or apis, it just builds a graph, which you would normally form imperatively.

Re: React Renderer for Three.js

#122

Post by dakom » Mon, Aug 16, 2021, 6:48 AM UTC

strbean wrote: post #101

tuckerconnelly wrote: post #95

Earlier quoted context omitted.

I really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

I don't see why an ECS would be incompatible with a DOM tree. As for the gorilla-banana problem, I would think all objects in a scene would be under the root, with the exception of pieces that make up a thing and rarely separate (wheels on a car, for example).

It's not that it's incompatible, it's that when the ECS is the primary tool for organization, a DOM tree (or scenegraph) is merely one way of iterating over the entities - not the way.

This provides tons of benefits, so for example you can also decide to iterate over the entites by shader program and gain significant speedups for graphics processing, or maintain components that roughly sort them by their position in world space for physics and culling or lighting, etc.

For a crude analogy, imagine if Document.querySelectorAll() were a zero-cost abstraction, i.e. it ran as fast as iterating over linear memory. In practice this isn't how it turns out with an ECS, but it's much closer and you can get this kind of performance for the "hot path" kind of queries.

To add to the sibling comment, there's another wonderful Rust ECS called shipyard[0] and I helped write a scenegraph for it (which I really need to update, one of these days)[1]

[0] https://github.com/leudz/shipyard

[1] https://github.com/dakom/shipyard-scenegraph

Re: React Renderer for Three.js

#123

Post by dakom » Mon, Aug 16, 2021, 6:58 AM UTC

nightski wrote: post #67

nobbis wrote: post #19

Earlier quoted context omitted.

As a counterpoint, I've enjoyed building VR on the web using C++ (with WebAssembly/WebGL/WebXR) and not having to touch the DOM or JS, see: https://twitter.com/nobbis/status/1425266634982248451 Benefits include complete control at frame and pixel level, being cross-platform (same code runs on web, iOS, macOS, Linux), and having access to third-party C/C++ libraries for 3D graphics.

I have not put a lot of time into learning WebAssembly. But isn't WebGL a JavaScript API? Meaning wouldn't you be going from WebAssembly -> JavaScript engine -> WebGL? I was under the impression WebAssembly had no access to the outside world and could only access the relevant JavaScript APIs. But if it is true you can basically do WebAssembly -> native GL then that would be amazing.

I wrote an opinionated WebGL wrapper in Rust/WASM here: https://github.com/dakom/awsm-web

The idea is that it does more cacheing of things like uniform locations and such so you do very fast in-memory lookups in WASM without hitting the JS Api as much.

In the future this will be obsolete since WebGPU has a more optimal API to begin with, and Rust/WASM won't need to go through the JS layer due to "interface types"

Re: React Renderer for Three.js

#124

Post by mlsarecmg » Mon, Aug 16, 2021, 6:59 AM UTC

beebeepka wrote: post #86

One of those things that make zero sense but use react, and that makes them cool enough to blog about.

It has similar benefits as react-dom has for the dom. Less code, faster performance, less memory consumption, real interop with a growing eco system.

Re: React Renderer for Three.js

#125

Post by mlsarecmg » Mon, Aug 16, 2021, 7:01 AM UTC

arcanon wrote: post #94

The age of WebGPU is almost upon us. Chrome 94 comes out this quarter. I doubt React will be the major player in this next epoch. It will be something new that can pull off an instant load shared world game.

Threejs already has a webgpu renderer.

Re: React Renderer for Three.js

#126

Post by dakom » Mon, Aug 16, 2021, 7:03 AM UTC

Jasper_ wrote: post #105

arcanon wrote: post #94

The age of WebGPU is almost upon us. Chrome 94 comes out this quarter. I doubt React will be the major player in this next epoch. It will be something new that can pull off an instant load shared world game.

In my experience ths issue with this has always been asset download speeds, not web frameworks. The lack of a storage solution means we can't ship game quality assets and have things be instant load.. I run a large WebGL application and the Chrome network cache is still my biggest issue ( e.g. this unsolved bug despite me having an 100% repro https://bugs.chromium.org/p/chromium/issues/detail?id=770694 )

Yes, I agree... case in point - Unity's Wasm/Webgl exporter works really well for the most part, especially if you test and develop specifically for that target - but we don't see it taking off the way Flash did because nobody wants to wait 10 mins for their page to load.

Re: React Renderer for Three.js

#127

Post by mlsarecmg » Mon, Aug 16, 2021, 7:09 AM UTC

dheera wrote: post #87

Jasper_ wrote: post #13

Earlier quoted context omitted.

The creator of React-Three-Fiber has come out with some extremely bizarre tweets, like claiming updating 2,000 cubes at 60fps is an "impossible amount of load" [0]. The solution it uses for performance is... punting your calculations to the next frame if you didn't make it this frame. They call this "the scheduler". Turns out this makes no sense in any serious context if you want your 3D frame to be coherent. I'm sur…

> updating 2,000 cubes at 60fps Have we gotten so bloated with framework on top of framework that even this is deemed an impossible load? If you write straight-up WebGL code 2000 cubes at 60fps should be a walk in the park for any modern PC.

threejs has no problem rendering hundreds of thousands of objects, so react doesn't have a problem either because its baseline is threejs, it does not introduce overhead or a performance penalty. These components render in a regular RAF loop, react is not involved at all unless you are mounting/unmounting objects, and this is where it can actually be faster.

Re: React Renderer for Three.js

#128

Post by mlsarecmg » Mon, Aug 16, 2021, 7:22 AM UTC

dheera wrote: post #88

mlsarecmg wrote: post #44

Earlier quoted context omitted.

you want your view to do something, to participate in the render loop, to animate, user interaction etc. look at the example on the main page: https://github.com/pmndrs/react-three-fiber#what-does-it-loo...

So just do it with VRML5 like HTML5. ... No reason the above can't be done. But many people will come up with lame excuses about why we shouldn't have nice things.

i can't say why webgl took over, as well as threejs, but i like how close to the metal they are. i would also much rather have a lower level representation underneath instead of starting outright with a markup language. i think that's why vrml eventually faded. i generally don't see why 3d should be represented in html.

as for react, it merely expresses threejs, and adds something which three doesn't have: self contained components that are now sharable. something like this: https://twitter.com/0xca0a/status/1394697847556149250 just didn't exist in the web previously.

Re: React Renderer for Three.js

#129

Post by tuckerconnelly » Mon, Aug 16, 2021, 7:30 AM UTC

mlsarecmg wrote: post #121

tuckerconnelly wrote: post #95

Earlier quoted context omitted.

I really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

React is not based on the dom, R3f merely expresses regular threejs which works as an object graph. Three is the usual choice for 3D on the web, if you use it once you'll see that it is also quite natural. There is no conflict between the two and react certainly doesn't change any rules or apis, it just builds a graph, which you would normally form imperatively.

React is inspired by the DOM and they split it before 1.0 IIRC, but that misses the forest for the trees. The main issue I had is that React, Three.js, and R3F are all hierarchical/tree-like (what you and Three.js are calling a graph). You can technically yes, build 3D scenes, but anything non-trivial will be very awkward.

Let's say you're building a game where you want a sphere to stick to whatever player you throw it at. How would you do that with a scene graph/OOP model? It'd be awkward, removing objects from one parent and adding them to another. Even more awkward if it's a complex object and you only want a part of that complex object to stick to the player. ECS + a constraint or physics system does a decent job (not perfect) of handling this in a relatively elegant and performant way.

I've used Three.js enough--built my portfolio[1] out of it, and then switched to Babylon when I realized how little I liked Three.js. For the record, I also dislike Babylon.

[1] https://tuckerconnelly.com

Re: React Renderer for Three.js

#130

Post by mlsarecmg » Mon, Aug 16, 2021, 7:58 AM UTC

tuckerconnelly wrote: post #129

mlsarecmg wrote: post #121

Earlier quoted context omitted.

React is not based on the dom, R3f merely expresses regular threejs which works as an object graph. Three is the usual choice for 3D on the web, if you use it once you'll see that it is also quite natural. There is no conflict between the two and react certainly doesn't change any rules or apis, it just builds a graph, which you would normally form imperatively.

React is inspired by the DOM and they split it before 1.0 IIRC, but that misses the forest for the trees. The main issue I had is that React, Three.js, and R3F are all hierarchical/tree-like (what you and Three.js are calling a graph). You can technically yes, build 3D scenes, but anything non-trivial will be very awkward. Let's say you're building a game where you want a sphere to stick to whatever player you throw…

i have yet to encounter something that shouldn't be expressed as a graph. three, babylon, ogl, blender, gltf, cad, games, they're all scene aligned. that doesn't seem to be a conflict since you still use shaders, physics, ecs and so on.

could you go more into detail what you mean when you say "anything non trivial"? is there a real example of something that would not be possible to create in, say, threejs?