Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Renderer for Three.js

github.com

Post reply on HN
Print view View original

31–40 of 136 posts

Re: React Renderer for Three.js

#31

Post by atom_arranger »

runawaybottle wrote: post #16
mlsarecmg wrote: post #6

Earlier quoted context omitted.

react has little to do with html. it just calls functions, what you see in react-dom isn't html either, these are nested document.createElement(...) calls. this can be configured for any platform, web, native or otherwise, so in this case is just new THREE.Mesh(). in react terms it's called a custom renderer. the other thing you say, that react is bad for animations — r3f operates outside of react, there is no overhe…

So again, I have to contest this. Not all UIs should be described in a tree structure. React and it’s whole diffing algo is to make sense of parts of the tree that changed. That idea didn’t come out of the blue, it came from html, it came from the DOM. If I give you a blank sheet of paper and say ‘write me a rendering api’, and you immediately reach for a tree structure, I’d be compelled to say you are influenced by…

I’m not sure it’s optimal from a performance perspective, but having everything represented by a tree is kind of nice.

I haven’t really encountered anything that can’t be represented well in a tree, especially with context providers in the mix.

Re: React Renderer for Three.js

#32

Post by tills13 »

Is there an error in the examples? You have

    const mesh = useRef()

    ...
You'll be rendering an undefined element (before the ref has a chance to attach).

Also, the TypeScript example makes me head hurt.

    const ref = useRef(null!)
Ah, yes. A non-null null literal.

Re: React Renderer for Three.js

#33

Post by short_sells_poo »

Jasper_ wrote: post #30
short_sells_poo wrote: post #29

Earlier quoted context omitted.

I can't take a 3d rendering framework seriously if it gets bogged down at updating 2000 untextured and non-interacting cubes @ 60 FPS. What on earth is all that time spent on? Doing ~2000 3x3 matrix ops should take a modern processor a few hundred usec surely? To put the silliness of the 2000 number in context, look here at a showcase of the Unity ECS system from years (!) ago: https://software.intel.com/content/www/…

You have to remember that this 700ms overhead is not the renderer. It's just setting fields on the underlying Three.JS Cube objects. The Three.JS renderer runs fine, and I don't even consider Three.JS to be a fast renderer. So yes, the overhead of React-Three-Fiber's tree reconciliation is seemingly massive. No, I do not have any answers for what it is doing. Nor do I have any guesses.

Thanks for clarifying. 700ms overhead is massive. It sounds like the approach is just deeply suboptimal for any sort of high performance and complicated 3d scenes. Perhaps that was not their objective...

Re: React Renderer for Three.js

#34

Post by shallowthought »

tills13 wrote: post #32

Is there an error in the examples? You have const mesh = useRef() ... You'll be rendering an undefined element (before the ref has a chance to attach). Also, the TypeScript example makes me head hurt. const ref = useRef(null!) Ah, yes. A non-null null literal.

I have to wonder: Have we gone too far? Is TypeScript becoming more tedious than helpful? Has React lost its way in its blind zeal for pure functions?

...no, no, definitely not. Must've gone crazy for a second there.

Re: React Renderer for Three.js

#35

Post by CraftThatBlock »

tills13 wrote: post #32

Is there an error in the examples? You have const mesh = useRef() ... You'll be rendering an undefined element (before the ref has a chance to attach). Also, the TypeScript example makes me head hurt. const ref = useRef(null!) Ah, yes. A non-null null literal.

I'm guessing they are overloading the ref's usage with the custom renderer. I believe that a renderer can accept non-function/class components in theory, which is why this works.

I don't really like this though, although interesting, it feels like a hack and might not integrate well with tooling (e.g. the Typescript example).

How I would have implemented it was exposition a Mesh component which wraps this, and a useMesh hook to wrap and type the ref.

Re: React Renderer for Three.js

#36

Post by afloatboat »

tills13 wrote: post #32

Is there an error in the examples? You have const mesh = useRef() ... You'll be rendering an undefined element (before the ref has a chance to attach). Also, the TypeScript example makes me head hurt. const ref = useRef(null!) Ah, yes. A non-null null literal.

I believe the `null!` is some trickery to let the rest of the code know that the `ref.current` will never be null, but with how React works you can’t really provide any other value. It prevents having to check for `null` everytime you address the value.

I don’t understand your first issue. The component is assigned to the ref, not the other way around, so why would it render `undefined`? It’s possible that `mesh.current` is undefined at first render, but that shouldn’t matter for the component, only for the reference.

Re: React Renderer for Three.js

#37

Post by short_sells_poo »

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 think they need to take a very serious and hard look at performance before it can go anywhere near VR (where rendering speed and stability are paramount). I'm sure it works for simple things and can handle GUIs fine, but the overhead seems huge currently.

Re: React Renderer for Three.js

#38

Post by brailsafe »

nobbis wrote: post #19
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.

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.

This looks really neat

Re: React Renderer for Three.js

#39

Post by vvanders »

brundolf wrote: post #25
vvanders wrote: post #15

Earlier quoted context omitted.

The "No. There is no additional overhead. Components participate in a unified renderloop outside of React. It outperforms Threejs in scale due to Reacts scheduling abilities." made me do a serious double-take. If you want to go fast in this space then you need to care about data layout and how the system is structured end-to-end. Calling a function per object is going to hit a wall regardless of how you schedule. Hun…

It's interesting because in normal React usage, the overhead of generating and throwing away a bunch of objects on each update is dwarfed by the cost of updates to the DOM But in Three.JS the actual updates to the tree should be cheap, right? There's no reflow, you're just setting values in memory to be used by the next render frame. If so, that changes the calculus. There's also the fact that in an app, it's rare fo…

Yeah, I can totally see the argument that it's a programming model that's well understood and you can get a productivity boost from that. However I don't think you can say that doesn't come with a cost, otherwise it would have been pretty widely adopted across the industry.

Re: React Renderer for Three.js

#40

Post by mlsarecmg »

Jasper_ wrote: post #13
gentleman11 wrote: post #3

So react builds a tree of react elements that react dom turns into html. So this must replace react dom? Reusable components are easy in a 3d engine like 3js. You can still program declaratively if you liked. It’s claim to outperform raw threejs is surely untrue. React is also bad for animations, and they recommend you sort of use reacts “back door” to do complex animations. 3d engines are all about animations. You c…

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…

as absurd as it may seem to you, this is a react feature. the upcoming react 18 release is pretty much based on concurrency.

this is the test you are referring to: https://docs.pmnd.rs/react-three-fiber/advanced/scaling-perf...

the github repo now contains a vanilla test that you can run

Post reply on HN