This looks really nice. I did a three.js CAD tool [1] for a client during this last year and really wanted to use something like this, but ended up building something custom.
The main thing I knew I wanted was a declarative specification of the objects in our scene. I knew it would be a nightmare to fiddle around with manually adding and removing bits of the scenegraph in response to input.
Ended up just doing diffs on the part of the Redux state that mapped to the scene, and automatically discarding and re-running the mesh construction code for the parts of the state that changed.
It actually worked well enough and didn't cause any problems I noticed (in terms of convenience of use and performance), but I wouldn't want to re-write it for each project that could use it.
One thing I do wonder about with this though is whether there's really a benefit to using the tag language to specify three.js objects. For folks already familiar with the three.js library it's going to be a nuisance to use the tag language instead, and it doesn't appear to me to be more concise or convenient in any way. But maybe I just feel that way because I've been writing js to construct three.js objects for years :)
Hey that's amazing, and your tool is really advanced! It's exactly the purpose of this, we're making a cad system as well and it's been hell with the current way of how we chose to do it. We're using redux and getting the scene graph to adapt with manual subscribers - it's led to something that is very hard to understand. That is why i'm writing the reconciler now.
The benefit of using tags (jsx) is that objects become fully managed. The most clear indication to me is still effects. https://codesandbox.io/embed/mo0xrqrj79 You can drop that in and it works. Make it conditional and once it gets unmounted the render loop goes back to normal. Almost magic, but then again, react for the dom had the same benefits.
> The benefit of using tags (jsx) is that objects become fully managed
I'm not sure I follow here. I assume that by 'become fully managed' you mean that React will reconstruct as necessary based on what is declared in the jsx?
So maybe that is just the nature of writing React renderers specifically, the only option for getting your objects managed is to map them to jsx?
> The most clear indication to me is still effects.
This does look much nicer than other examples I've seen of using effects. I have only limited experience with them personally. They weren't needed for our tool. Incidentally I am probably setting up some SSAO on another project today though so I'll be likely be digging more into them later.
with managed i mean that the view is now merely a reflection of state. Basically just like with the dom:
{condition && <div>hello</div>}
The div is there as long as the condition is true. But of course it can now also be a mesh, or a component that can clean itself up after the unmount.
We did this manually before, which usually meant watching out for objects to remove themselves, they'll have to communicate up their hierarchy to inform parents and so on. This wasn't straight forward in three, so there was a lot of prototype hacking and terrible things like that, i'm so glad this will be all gone.
The main thing I knew I wanted was a declarative specification of the objects in our scene. I knew it would be a nightmare to fiddle around with manually adding and removing bits of the scenegraph in response to input.
Ended up just doing diffs on the part of the Redux state that mapped to the scene, and automatically discarding and re-running the mesh construction code for the parts of the state that changed.
It actually worked well enough and didn't cause any problems I noticed (in terms of convenience of use and performance), but I wouldn't want to re-write it for each project that could use it.
One thing I do wonder about with this though is whether there's really a benefit to using the tag language to specify three.js objects. For folks already familiar with the three.js library it's going to be a nuisance to use the tag language instead, and it doesn't appear to me to be more concise or convenient in any way. But maybe I just feel that way because I've been writing js to construct three.js objects for years :)
[1] https://www.youtube.com/watch?v=e21tqZebl60