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

11–20 of 136 posts

Re: React Renderer for Three.js

#11

Post by eyelidlessness »

runawaybottle wrote: post #4
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 interesting thing about switching renderers is that you are now free of the DOM. I just think web developers only know one api really well (the DOM and it’s offspring frameworks) that when you give us a blank canvas (no pun intended), we resort to the same data structure and api of what we’ve always known. We’re truly free to make a however we like. Perhaps not even in those tags. We just don’t know it yet.

JSX has very little to do with the DOM. It’s always been a language extension to provide render-agnostic expressions. Non-DOM renderers have existed for years (React Native, smart TV, CLI, PDF, PowerPoint, the list keeps going…).

The reality is it’s a good abstraction because it’s so decoupled from the DOM, but it’s associated with the DOM and web mainly for historical reasons.

It’s also worth noting that there are similar extensions to other languages that are similarly render-agnostic.

Re: React Renderer for Three.js

#12

Post by e12e »

mlsarecmg wrote: post #8
throw_m239339 wrote: post #2

VRML anyone?

you can't express a 3d scene with markup alone, that is why VRML didn't succeed. the JSX you see just masks function calls, it is not XML or HTML, but the true power is in components and hooks (useFrame, etc). a r3f component is self-contained, it will even subscribe to the render-loop. click into these two examples to see the difference: https://twitter.com/0xca0a/status/1426924274527477764

> you can't express a 3d scene with markup alone

What?

Re: React Renderer for Three.js

#13

Post by Jasper_ »

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 sure this is helpful for some people, but I can't rely on it when making serious applications. There's lots of things you can punt to the next frame, but ideally that should be decided per system, and not a global framework.

Keep in mind that rendering here is still happening every frame, so the only thing that's happening is 2,000 transform updates for cubes. Inexplicably, without the scheduler that punts updates to the next frame, it takes 700ms to do this [1]. For 2,000 matrix muls. That's 3ms per cube. What on earth is this doing?

[0] https://twitter.com/0xca0a/status/1199997552466288641 [1] https://twitter.com/0xca0a/status/1199997561358213120

Re: React Renderer for Three.js

#14

Post by runawaybottle »

eyelidlessness wrote: post #11
runawaybottle wrote: post #4

Earlier quoted context omitted.

The interesting thing about switching renderers is that you are now free of the DOM. I just think web developers only know one api really well (the DOM and it’s offspring frameworks) that when you give us a blank canvas (no pun intended), we resort to the same data structure and api of what we’ve always known. We’re truly free to make a however we like. Perhaps not even in those tags. We just don’t know it yet.

JSX has very little to do with the DOM. It’s always been a language extension to provide render-agnostic expressions. Non-DOM renderers have existed for years (React Native, smart TV, CLI, PDF, PowerPoint, the list keeps going…). The reality is it’s a good abstraction because it’s so decoupled from the DOM, but it’s associated with the DOM and web mainly for historical reasons. It’s also worth noting that there are s…

So I have a to contest that a bit. It parallels the DOM in structure entirely. You can see how this is the truth when you want to have components outside of a parent-child hierarchy belong to the same ‘component’, you have to use this very abstract concept of a Portal, as in, nothing is natural once you start thinking out of the tree structure.

Certainly you can map this api to a variety of other APis, which I’m sure is what they did with React Native, but it was built with the DOM tree structure in mind.

I think it’s one of the most brilliant things frontend has ever created along with Jquery, but they are both slaves to the DOM.

Re: React Renderer for Three.js

#15

Post by vvanders »

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…

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.

Hundreds/Thousands of updates is not small but it's also not massively impressive either. I've done ~2,800 node scene graphs on underpowered ARM chips back in '09 at 60FPS including rendering. You have to use NEON, and be aware of your caches. No scheduling magic is going to change that unless you're just deferring work which sounds like what may be happening there.

FWIW I've also done this in Java via FlatBuffers(which uses ByteBuffer internally) to keep data coherency when driving animations frames so it doesn't require dropping down to C/C++/Rust(although C#'s value types do make it easier).

Re: React Renderer for Three.js

#16

Post by runawaybottle »

mlsarecmg wrote: post #6
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…

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 html.

I feel like the watershed moment for us will be that moment in the Matrix where the kid tells Neo ‘there is no tree, there is no spoon’.

Edit (full quote from The Matrix):

Do not try and bend the spoon, that's impossible. Instead, only try to realize the truth... There is no spoon... Then you'll see that it is not the spoon that bends, it is only yourself.

We have been bending over for the DOM for quite some time now, I think it’s time we explore.

————————

Edit 2 (being rate limited), reply to some posts below:

Interestingly enough, ever major performance trick on the frontend requires breaking out of the tree structure. If you want a data table with a notable amount of rows, you have to break out and start defining heights and positions and calculate what to show manually. In other words, the free stuff we were supposed to get from the tree were not free.

My irreverence for the DOM comes from the fact that we have to negate it, ignore it, to achieve certain things.

So in the end I wonder, why bother with it at all?

Re: React Renderer for Three.js

#18

Post by [deleted] »

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.

[deleted]

Re: React Renderer for Three.js

#19

Post by nobbis »

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.

Re: React Renderer for Three.js

#20

Post by catlifeonmars »

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…

While I strongly suspect you’re right about React being influenced by the problem space, I’d contest the notion that trees aren’t useful for computational constructs in general. Trees are fundamental to the concept of a function call graph over time, for example.
Post reply on HN