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

111–120 of 136 posts

Re: React Renderer for Three.js

#111

Post by tills13 »

petrbela wrote: post #96
tills13 wrote: post #53

Earlier quoted context omitted.

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.

Actually, the compiled JS is `React.createElement('mesh', { ref: mesh } )`. JSX compiler converts all lower-case names to strings. Only upper-case name (and composites like `rn.View`) are converted to variables. The reason r3f uses lower-case names for built-in components is to distinguish them from your own components; from the documentation: "It merely expresses Three.js in JSX: becomes new THREE.Mesh(), and that h…

Ah, right. It's very obvious in hindsight. Thank you for clarifying.

Re: React Renderer for Three.js

#112

Post by tills13 »

afloatboat wrote: post #89
tills13 wrote: post #53

Earlier quoted context omitted.

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.

Ah, right. But the mesh useRef is not wat is being rendered, the `mesh` component is more like rendering a div. If you open the sandbox and remove the useRef mesh and references it will still work. Pretty confusing though, would have been better to call it `meshRef`. I also expected these components to be capitalised, but it probably makes sense in the way that in the dom renderer default components are lowercase as…

yeah imo simply changing the variable name of the ref would go a long way, here.

Re: React Renderer for Three.js

#113

Post by e12e »

mlsarecmg wrote: post #44
e12e wrote: post #12

Earlier quoted context omitted.

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

you want your view to do something, to participate in the render loop, to animate, user interaction etc. look at the example on the main page: https://github.com/pmndrs/react-three-fiber#what-does-it-loo...

I mean, this looks like a nice, more modern approach - but vrml did allow full interaction? For something that works in current browsers, see eg:

https://github.com/create3000/x_ite/wiki/Sensing-viewer-acti...

Re: React Renderer for Three.js

#114

Post by tuckerconnelly »

strbean wrote: post #101
tuckerconnelly wrote: post #95

Earlier quoted context omitted.

I really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

I don't see why an ECS would be incompatible with a DOM tree. As for the gorilla-banana problem, I would think all objects in a scene would be under the root, with the exception of pieces that make up a thing and rarely separate (wheels on a car, for example).

While not incompatible with ECS, the DOM and this renderer go all-in on the javascript event-loop. You would have to write your own run loop, which executes the systems on every frame (ideally creating a DAG and executing in parallel while possible), and leave the event loop behind, with all the niceties like `onClick`, to go full ECS. Otherwise you'll create some Frankenstein monster of part ECS, part event-loop, part declarative React.

Additionally, you can throw OOP in that mix as well, because Three.js has it's own whole OOP-style framework, that you're strapping declarative React on top of with this renderer. Reminds me of Jonathan Blow's talk on the end of civilization via endless layers of abstraction[1].

I really think, when it's ready, a Bevy[2]-style system either native or compiled to WASM with WebGPU will be ideal.

And while I'm airing opinions (forgive me), I think writing shaders now is like SQL 30 years ago. Developers left optimizing difficult--according to them--SQL to database administrators by abstracting it away into ORMs. If history is any indicator, I think we'll be having the same arguments on Hacker News 30 years from now about 3D frameworks vs writing shaders directly as we're having now about ORMs vs writing SQL directly.

[1] https://www.youtube.com/watch?v=pW-SOdj4Kkk

[2] https://bevyengine.org/

Re: React Renderer for Three.js

#115

Post by SirHound »

tuckerconnelly wrote: post #95
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 really don't think React will be the go-to tool for VR; it's based on the DOM and trees of function calls, which are both hierarchical, which necessarily means you have the gorilla-banana problem. If you have a coffee cup on a table in VR, is that coffee cup a child of the table? How do you move the coffee cup off the table and put it onto another table? Is it now a child of that other table? What about the coffee…

Aren’t nested coordinate systems a quite natural match for a DOM-like tree structure?

Re: React Renderer for Three.js

#116

Post by nobbis »

Unit520 wrote: post #109
nightski wrote: post #67

Earlier quoted context omitted.

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.

WebAssembly has no access to the outside world at the moment, that is correct. It is only able to call (and be called by) JS. A C++ application compiled via Emscripten ships (a fairly large amount) of JS glue code that exposes all relevant Browser APIs like WebGL, Fetch or other HTML5 stuff to the actual WASM program. As others commented, for WebGL an additional API translation is applied. If the source targets OpenG…

Not that large. The JS glue code for the VR web page referenced above is 48 KB, including WebGL, WebXR, Fetch, etc.

Re: React Renderer for Three.js

#118

Post by [deleted] »

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.

[deleted]

Re: React Renderer for Three.js

#119

Post by strogonoff »

lxe wrote: post #98
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 was scratching my head over this one too. Other answers in the thread don't seem right. I then realized this: const mesh = useRef(... assigns an instance of something (`React.mutableRefObject`) to a variable in scope, but after compiling into normal JavaScript and becomes (0, _jsxRuntime.jsxs)("mesh"... (see `console.log(__SANDBOX_DATA__.data.transpiledModules['/src/App.js:'].source.compiledCode) `) So that's why y…

I’d answer the original question…

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

…as follows:

1. On that last line, is just a regular element[0].

2. Ref assignment makes this element’s instance accessible within component code[1] under a constant, here coincidentally (and confusingly, I must say) named “mesh”. The constant could’ve been named anything else, like “el”, and the example would work exactly the same way:

    const el = useRef()
    ...
3. How come the constant in the original example does not shadow the equivalently named built-in JSX element? Well, there is a convention/hard-coded rule in React/JSX/TSX where it simply would not resolve lowercase identifiers to custom components. If we change “mesh” to “Mesh” in the original example, then the app would attempt to use the ref constant as a (malformed) custom component, and predictably throw.

[0] https://www.w3.org/TR/2016/CR-SVG2-20160915/shapes.html#Mesh...

[1] https://reactjs.org/docs/refs-and-the-dom.html#refs-and-func...

Re: React Renderer for Three.js

#120

Post by mlsarecmg »

webgfxdev wrote: post #92
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.

React is one of the worst choices of doing something like that. The underlying abstraction model of having a tree of components and re-rendering only the parts that have changed between renders doesn’t map to the hardware at all, meaning you’ll waste most of the HW performance just on maintaining the abstraction. You’ll also get zero benefits from the third-party libraries - there’s nothing in them that can help you…

You are arguing against threejs not react. R3f reconciles threejs in the exact way it's getting used, a graph. This ofc is also how blender gltf et al work. If you make a webgl app on the web you most likely use three and all react does is make that a little ordered with some additional benefits when it comes to performance, memory and interop.
Post reply on HN