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

51–60 of 136 posts

Re: React Renderer for Three.js

#51

Post by mlsarecmg »

CraftThatBlock wrote: post #35
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 useM…

r3f is a custom renderer, there is no difference in useRef between a div or a mesh, refs give you the underlying object. lowercase elements are native elements (div, span, mesh, view, box), they are defined by the renderer. uppercase is for components.

Re: React Renderer for Three.js

#52

Post by miohtama »

felipellrocha wrote: post #26
joshwcomeau wrote: post #7

Earlier quoted context omitted.

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.

For some use cases, like charts and diagrams, even a piss poor performance is enough as long as it is accessible to developers.

Re: React Renderer for Three.js

#53

Post by tills13 »

afloatboat wrote: post #36
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.curr…

Oops, I guess it's not undefined, but it'll attempt to render a ref object.

const mesh = useRef()

The underlying JavaScript (i.e. not JSX) on the first render , is React.createElement(mesh /* { current: undefined } */, { ref: mesh } )

In fact, I don't even think it matters which render you're talking about. It's still rendering a ref (again, { current: }). That doesn't seem right to me.

Re: React Renderer for Three.js

#54

Post by Jasper_ »

mlsarecmg wrote: post #48
Jasper_ wrote: post #30

Earlier quoted context omitted.

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.

there were multiple versions of that test, the fist had nothing to do with the subject matter, the ones that people refer to (spinning cubes) had an artificial delay that was added to simulate cpu stress.

No artificial delay was added from what I can find. Here's the example from the tweet [0]. Feel free to tell me where the artificial delay is.

[0] https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42...

Re: React Renderer for Three.js

#55

Post by hirako2000 »

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.

Except that for three.js, it's react introducing complexity rather than improving the organisation of the code. A simple component with defaults look neat, but start building a complex scene and jsx gets in the way.

three.js isn't dom elements updated in js. The state of each object is updated in the scene depending on more than whether they changed.

Where three.js lacks abstraction is a component system, in plain js, to organise application with decent patterns. Most three apps are a big blob or code.

Re: React Renderer for Three.js

#56

Post by tills13 »

mlsarecmg wrote: post #51
CraftThatBlock wrote: post #35

Earlier quoted context omitted.

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 useM…

r3f is a custom renderer, there is no difference in useRef between a div or a mesh, refs give you the underlying object. lowercase elements are native elements (div, span, mesh, view, box), they are defined by the renderer. uppercase is for components.

Ah, if they're using a custom JSX Pragma it might make sense. Still a little too bespoke for me.

Re: React Renderer for Three.js

#57

Post by tills13 »

shallowthought wrote: post #34
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.

I think I blame JavaScript for this mess, not the other way around.

Re: React Renderer for Three.js

#58

Post by tills13 »

mlsarecmg wrote: post #46
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.

this is how refs work. it's the same with a div. the ref will be filled in useEffect, not before. null! is a common typescript thing, it is a semantic guarantee that the ref is static and hence will be available. this saves you the if (ref.current) { ... } check.

To clarify, I'm not talking about the ref _prop_, I'm talking about them using the ref as the element.

Re: React Renderer for Three.js

#59

Post by nobbis »

rock_hard wrote: post #50
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.

Totally agree! We switched https://flux.ai from vanilla ThreeJS to R3F and it’s been a huge productivity gain for the whole team! Less code, that is more capable and more reusable! In case anyone is interested, we are hiring: https://coda.io/@flux-ai/flux-jobs

Is this AR/VR? It looks like 2D circuit schematics.

Re: React Renderer for Three.js

#60

Post by mlsarecmg »

Jasper_ wrote: post #47
mlsarecmg wrote: post #40

Earlier quoted context omitted.

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

As I said, "schedule" just means "defer work to future frames". That's a valid strategy if you have severe load, but it's not globally applicable: one might imagine that two components need to be updated together (e.g. updating the arms and body of a character should not be split up between two frames, or else the user will see split bodies for in-between frames). At the very best, this sort of scheduling should be i…

what you link there has more to do with react vs zustand.

if it interests you, read up on react 18 concurrency, this is the bit you are missing in this discussion.

Post reply on HN