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

61–70 of 136 posts

Re: React Renderer for Three.js

#61

Post by sswu »

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.

The TypeScript example does feel a little weird. I've used this library successfully with React + TypeScript with the following pattern:

  const mesh = useRef(null); // mesh has type RefObject
  ...
  useFrame((): void => {
    if (mesh.current != null) {
      mesh.current.rotation.x += 0.01;
    }
  });
  ...
  return
As others have mentioned, the ref will typically attach by the time a `useEffect` hook is called, but for safety it's nice to have the null check.

Re: React Renderer for Three.js

#62

Post by mlsarecmg »

tills13 wrote: post #56
mlsarecmg wrote: post #51

Earlier quoted context omitted.

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.

no special jsx pragma needed. this is actually just plain react, and so on come from react-dom, which defines these elements. other renderers define theirs. here's a mini custom renderer if this interests you: https://codesandbox.io/s/reurope-reconciler-hd16y

Re: React Renderer for Three.js

#63

Post by Jasper_ »

mlsarecmg wrote: post #60
Jasper_ wrote: post #47

Earlier quoted context omitted.

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.

No; that's not the test in question. The tweet I started the conversation with [0] shows a bunch of cubes, not text geometry. It's not the text geometry test. It's just creating and manipulating a bunch of cubes. Unfortunately, it was removed from the react-three-fiber examples, so it can't be easily run unless you check out an old version of the repo. It contains two switches, one for React vs. Zustand, and the other for Concurrency On vs. Off [1]. The tweet is talking about the concurrency mode.

I'm very familiar with React 18 concurrency, and gave my detailed analysis of it. The documentation you linked even confirms my analysis of it deferring work across frames:

> it can potentially defer load and heavy tasks

I've already given my feedback about that approach. I heavily suspect the overhead here is all React's reconciler / differ, as Svelte, which has no scheduler, performs similarly to the concurrent React mode[2].

[0] https://twitter.com/0xca0a/status/1199997552466288641 [1] See the description in the panel here. It's talking about React 18 concurrency. https://github.com/pmndrs/react-three-fiber/blob/e3a71baad42... [2] https://twitter.com/Rich_Harris/status/1200805237948325888

Re: React Renderer for Three.js

#64

Post by mlsarecmg »

Jasper_ wrote: post #54
mlsarecmg wrote: post #48

Earlier quoted context omitted.

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

we're running in circles unfortunately and i've explained where the test you're referring to comes from and what it meant. i've posted the real test and if you want, engage in it.

    async function test() {
      const chars = `!"§$%&/()=?*#-_.:,;+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz`
      const font = await new Promise((res) => new THREE.FontLoader().load("https://raw.githubusercontent.com/drcmda/scheduler-test/master/public/Inter%20UI_Bold.json", res))
      console.time("test")
      for (let i = 0; i
how react 18 concurrency works exactly, i think that's not the right place to churn through it. the react team has published tons of reading material as well as public talks.

Re: React Renderer for Three.js

#65

Post by mlajtos »

tills13 wrote: post #58
mlsarecmg wrote: post #46

Earlier quoted context omitted.

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.

It’s lowercase, so it will act as plain-old tag. If the name would be uppercase, that would be a bug you described.

Re: React Renderer for Three.js

#66

Post by mlsarecmg »

tills13 wrote: post #58
mlsarecmg wrote: post #46

Earlier quoted context omitted.

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.

no ref is used as an element in that code.

    const ref = useRef()
    useEffect(() => console.log(ref), [])
    return
will return { current: [dom node] }

    const ref = useRef()
    useEffect(() => console.log(ref), [])
    return
will return { current: [mesh node] }

Re: React Renderer for Three.js

#67

Post by nightski »

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.

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.

Re: React Renderer for Three.js

#68

Post by mlsarecmg »

Jasper_ wrote: post #63
mlsarecmg wrote: post #60

Earlier quoted context omitted.

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.

No; that's not the test in question. The tweet I started the conversation with [0] shows a bunch of cubes, not text geometry. It's not the text geometry test. It's just creating and manipulating a bunch of cubes. Unfortunately, it was removed from the react-three-fiber examples, so it can't be easily run unless you check out an old version of the repo. It contains two switches, one for React vs. Zustand, and the othe…

i've written them. the first pits react against zustand, it naively lets react churn through the whole graph 60 times per sec, you wouldn't do that ever, but zustand could. i initially tweeted it for people interested in that lib.

some got it in the wrong throat, so i changed the test to actually pit it against a vanilla counterpart, and they were silent. the real test, contest that please, let the zustand thing go.

Re: React Renderer for Three.js

#69

Post by runawaybottle »

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

Okay yes, thank you from saving me from my drivel. Why would three.js care about representing a document model, bubbling up events, and so on. If we do this, we do it fresh.

Re: React Renderer for Three.js

#70

Post by pjmlp »

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.

BabylonJS and PlayCanvas do it just right without jumping into React fashion.
Post reply on HN