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

21–30 of 136 posts

Re: React Renderer for Three.js

#21

Post by brundolf »

runawaybottle wrote: post #14
eyelidlessness wrote: post #11

Earlier quoted context omitted.

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…

Lots of things are already tree-structured though, including Three.js

Re: React Renderer for Three.js

#22

Post by franciscop »

We're using these at my job, and it's been a pretty amazing experience. We built a wrapper[1] so that every front-end dev can build components even easier (without needing to know Three.js), since in the end of the day they are just React components that can be easily composed together:
[1] https://www.npmjs.com/package/@standard/view

Re: React Renderer for Three.js

#23

Post by felipellrocha »

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 additional overhead” struck me as a really high claim, and this confirms it. 2000 cubes at 60fps is really nothing if you know what you’re doing.

Re: React Renderer for Three.js

#24

Post by eyelidlessness »

runawaybottle wrote: post #14
eyelidlessness wrote: post #11

Earlier quoted context omitted.

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…

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

This isn’t a property of JSX, it’s a property of a virtual DOM. The former is typically used with the latter, but don’t have to be. SolidJS is an example of JSX without VDOM. It compiles to plain DOM operations, you only have a component tree during development. And like React, its compiler was designed to be render-agnostic and can be/is used in other environments.

It’s funny you should mention Portal here. I am working on a technique/hopefully eventual library to transparently (without requiring developer intervention) use Portals as a partial hydration solution—completely sidestepping the tree structure and only rendering interactive components. I believe it will be framework agnostic for anything that provides (or can provide) a hyperscript/createElement function and Portal-like functionality. And like those frameworks, it’s just a declarative data structure and can render to anything.

> 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’ve spent a lot of time (maybe too much time) looking at the underlying renderer abstractions of React, Preact, Solid, JSX Lite, several others.

The only one tightly coupled to DOM is Preact (and even that isn’t totally coupled). In fact that coupling is one of the major advantages Preact has in terms of package size.

React’s design has a separate renderer interface/abstraction that is primarily oriented around state reconciliation; the DOM implementation is just one of many.

Solid’s JSX (implemented in a Babel transform somewhat misleadingly called dom-expressions) is similarly decoupled from its DOM implementation with an abstract renderer interface. The difference is rather than state reconciliation it’s reactive.

JSX Lite’s render target is even more abstract, it renders an intermediate data structure that can be transformed to other component libraries, and even some design apps.

You can implement a JSX transform to basically any render target, without React. You can even skip the entire notion of state, events, interaction.

I even use it on my personal site to generate PNGs at build time! Unless you’re looking at my source code you’d never know it.

Re: React Renderer for Three.js

#25

Post by brundolf »

vvanders wrote: post #15
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…

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 for actual state updates (and therefore React renders) to happen on every frame; usually it's only on interactions. Maybe the occasional animation (if it can't be handled by native CSS animations). Whereas in graphical contexts like this, it's much more likely you'll have lots of objects in continuous motion (and therefore continuous re-renders).

I can see the productivity gains being worth it for a lot of simpler use-cases, but I'm skeptical about the performance claims when you start to get into complex scenes with lots of entities.

Re: React Renderer for Three.js

#26

Post by felipellrocha »

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

I've built "vanilla" Three.js projects, and worked with react-three-fiber. It is incredibly useful. Having a new set of "primitives" that map to three.js objects and being able to render them in a React application makes so many things easier. It's also just way less code to write compared to standard three.js. RE: animation performance, I haven't had any issues with it. I presume either they're doing a bunch of opti…

It’s just what you’re rendering is getting nowhere near pushing the limits of what can be done with the gpu.

Re: React Renderer for Three.js

#27

Post by shadowgovt »

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…

Not all UIs should be described in a tree structure, but a tree is an isomorphism to a scene graph, and a scene graph is a very solid, traditional way to structure a 3D scene for rendering.

Re: React Renderer for Three.js

#28

Post by Jasper_ »

catlifeonmars wrote: post #20
runawaybottle wrote: post #16

Earlier quoted context omitted.

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.

In most production renderers, you have a soup of objects. Sometimes it's a tree, but much more often it's a graph of nodes pointing to each other.

One of the first steps of this is to gather all the nodes in the graph, flattening it into a list, and then start filtering and sorting it: for every opaque object, you likely toss it in Z-pre and opaque buckets (for objects visible through the main frustum), and a shadow caster bucket (per shadowed light frustum!). So the renderer itself really prefers lists of lists, it does not have trees internally.

React-Three-Fiber seems to take the DOM-equivalent tree, sort it, and then construct a Three.JS scene graph from it, and then Three.JS's render method starts from that scene graph soup and does the above. So one might argue that the tree is a DOM-like interface you're adding on top of Three.JS's scene graph.

Re: React Renderer for Three.js

#29

Post by short_sells_poo »

vvanders wrote: post #15
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…

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…

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/us/en/develop/article...

Their starting setup achieves 16000 textured and complex (relatively) models @ 30fps. Which is already much more than the "optimized" thing is achieving here. And it doesn't "cheat" by pretending to be fast via simply not doing to updates that are expected. And once they apply the various optimizations with memory layout etc... they get to 150000 (!) textured models moving about on screen @ 30 fps. So let's say 75000 @ 60fps, which is more than 35x as many objects, and the objects are much more complex.

Am I missing something? Why is "2000 cubes @ 60fps" extraordinary?

Re: React Renderer for Three.js

#30

Post by Jasper_ »

short_sells_poo wrote: post #29
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…

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.
Post reply on HN