Every time I am reminded that people use reactive stores with three.js or pixi.js I wonder what kind of problems are being solved this way, since frames are being redrawn anyway.

There has to be a good reason but I never bothered to ask.

Mostly to make the API declarative, similar to what you could do with OOP. If you have a 3D UI, a 3D UI framework might make sense, for example react has “suspense” for loading states, and you can imagine having 3D loading states, with placeholder models being rendered

There are similar three.js "connectors" for other frameworks too - I know of Svelte Cubed and React Three Fiber. I think I saw one for Angular too but I can't find it now. Any others?

https://svelte-cubed.vercel.app/

https://docs.pmnd.rs/react-three-fiber

We used React Three Fiber at my job 2-3 years ago (when it was "early") and it was already amazing then, we could do really cool stuff easily. We wrote our own wrappers to easily do <Cube /> and similar things and published it as OSS[1], but TBH documentation was scarce since it was an internal project and there were virtually no resources dedicated to publish it, just a couple of devs pushing for it. We even published one of the first bridges[2]. We didn't want to totally opt out of the React render loop so we had to do a lot of hacks and optimizations, but it was a great experience overall.

Nowadays React Three Fiber is very mature and you have the "drei" collection[3], which have all the things I mentioned and a lot more. Though now looking at the source and timing (we published a blog [4] with our solution and their commit few weeks later with almost the same code[5]) it seems they might've copied our solution as part of their package, would've loved a heads up or ack but well happy to make open source better.

[1] https://www.npmjs.com/package/@standard/view

[2] https://github.com/facebook/react/issues/13332#issuecomment-...

[3] https://github.com/pmndrs/drei

[4] https://standard.ai/blog/introducing-standard-view-and-react...

[5] https://github.com/pmndrs/drei/pull/137/files

Polygonjs [1] (disclaimer, I develop it) is for vanilla js, but also has components for vuejs [2], react [3] and react-three-fiber [4]. The goals are to provide a higher level api than threejs, and also to not be restricted to a single framework.

[1] https://github.com/polygonjs/polygonjs

[2] https://polygonjs.com/docs/integrations/vue

[3] https://polygonjs.com/docs/integrations/react

[4] https://polygonjs.com/docs/integrations/react_three_fiber

Yeah these declarative wrappers on top of threejs really help it become more approachable, especially since the skills you've learned with React, Vue, or Svelte translate so directly.

Mozilla created a vanilla js library that's similar called A-frame [1]. I've used it with success in a commercial project.

A-frame is heavily focused on VR, but can be used for any 3d project.

It also uses three.js under the hood.

https://github.com/aframevr/aframe

I've tried it, and I really really wanted to like it. . . But I can't recommend it for anything beyond simple demos.

If you need 3d work, it's far better to use a proper 3d engine like unity or unreal for a much nicer and productive overall workflow, and just export it as webgl.

The example at the top of the documentation is just so much fun :)

What is these days the way to make a simple 3D model exported in gltf interactive? I mean hide or show parts of the model? Add interactivity by having some JavaScript “steering” changes of the 3D model? Like an interactive model viewer. As modelviewer looks like not allowing to have a lot of interactivity

https://modelviewer.dev/

gltfjsx is the easiest I have used: https://github.com/pmndrs/gltfjsx

r3f export from spline also seems pretty easy but I haven't tried it yet: https://twitter.com/0xca0a/status/1519751065222238211

Thank you, exactly what I’m looking for right now

There's a bug in the second example. First tap of the square does nothing. Subsequent taps do.

After that, tapping outside the square also changes the color, but only for the first tap.

Meh.

Works as intended for me, Fedora36/Gnome/Firefox100.

Right so I'm imagining this behavior then?

Are you running Fedora36/Gnome/Firefox100? The more info you can give, the easier it is to debug for the devs.

nice