Move worker logic into react agnostic 'cannon-worker' package

[isaac-mason]

I recall seeing a discussion/issue about separating the worker logic in this package into a cannon-worker package that isn't tied to react. I can't find that discussion anymore, but I recall reading that the maintainers only really used cannon with react-three-fiber, so it wasn't deemed important.

I have a use case where it would be great to have a cannon worker package, but I'm not looking to use react.

I'm hoping to reopen the discussion and see if there is any interest for contributions creating this standalone cannon-worker package to power this package.

I have been working on a POC for taking logic out of this package and creating that react-agnostic cannon-worker package, and I'm looking to see if there is any interest in that being developed under the pmndrs roof.

I have a lot of interest in this and time for contributing, and putting this under the pmndrs roof could de-duplicate some of the efforts I'm making with the efforts here.

[drcmda]

why not, the only thing is, a worker cannot be published through npm because workers are accessed by url, and you can't fetch from node_modules because it doesn't exist in production. in this project it's being bundled into a url blob to work around that issue.

if the worker were a separate lib i guess that could still be done but i wonder how anyone else would use it? or maybe it's getting bundled like that as well with a small interface to communicate with it.

[isaac-mason]

Great! 🙂

I think bundling the worker in the separate cannon-worker package with an interface to communicate with it could be a good way to go?

Almost all of the functionality here could be moved into cannon-worker. This package could then use it in hooks & components, essentially becoming a simple wrapper. Just spitballing of course! These are very significant changes.

---

For context, here is the POC I am working on now: https://gitlab.com/rapidajs/rapida/-/tree/develop/packages/cannon-worker

Note that this is the WIP result of a very messy rework of this repo - it wasn't built from the ground up. Some things straight up don't work yet. But it's just a POC - I'd want to either make some more significant improvements to what is there now or just start over.

I tried not to touch the api too much when doing the rework. It's usage right now looks like this:

import { CannonPhysics, BodyType } from '@rapidajs/cannon-worker';

// ... other three imports ...

// ... create three renderer, scene, camera, etc ...

// create physics world
const physics = new CannonPhysics({
  gravity: [0, -10, 0],
  maxSubSteps: 5,
  delta: 1 / 60,
  // ... other world params ...
});

// create a three box mesh
const mesh = new Mesh(new BoxGeometry(1, 1, 1), new MeshBasicMaterial());

// create a box - more or less the same API as in here
const { api } = physics.create.box({
  mass: 1,
  args: [1, 1, 1],
}, mesh);

// step the physics world, providing the time elapsed
physics.step(1 / 60);

The Provider component we have now could then instantiate a new physics world via cannon-worker, and then hooks could use cannon-worker to create bodies, constraints, etc.

e.g. Provider could become something like this

export default function Provider({
  /* ... props ... */
}: ProviderProps): JSX.Element {
  const [physics] = useState<CannonPhysics>(() => new CannonPhysics({ /* ... props ... */ }));

  useFrame((state, delta) => {
    physics.step(delta);
  });

  // all the other stuff :)
  // ...
}

---

Let me know what you think of this as a potential approach.

[drcmda]

sure, so i can create a cannon-worker repo on here and add you. i'd suggest better start from scratch so that we don't loose functionality by accident and i'd also suggest doing both use-cannon and cannon-worker at the same time for easier profiling and testing. is that good?

[isaac-mason]

That would be great. I'm happy to start from scratch and incrementally build things up, sounds good.

I'll put both cannon-worker and the use-cannon package in the one repo with yarn workspaces, the same as I've seen in other pmndrs repos.

This might be a good opportunity make some additions such as exposing shape-specific APIs, as I saw discussed in #35. I will keep the current usage backwards compatible though. I'll aim to use the current use-cannon demos without any alteration, just a different import in the new temp repo for my rewrite of use-cannon. Doing so would make profiling and comparing the two easier as well.

One other thing - are you happy for me to just push my incremental work to that repo? Looking at the fantastic work joergjaeckel has been doing with pmndrs/use-p2, it looks like you folks are happy with that workflow in the infancy of a project. I'm happy with whatever though.

[drcmda]

alright, let's try. i've added you into the pmndrs/physics team

[isaac-mason]

Awesome, I'll reach out to the others in there shortly. Keen to get this done! 🙂

[isaac-mason]

I'm going to make a start on this tomorrow.

I've created the cannon-worker repo, and I'll add a readme shortly with some context and my planned roadmap for building this out - will share once it's there. Keen to hear any thoughts on what is included there & any other things people would like to see.

[isaac-mason]

Making progress on this over at https://github.com/pmndrs/cannon-worker

As I reintroduce features & hooks, I'll be adding examples direct from the use-cannon repo to help regression test. Right now I've just got the Cube Heap and the Sphere Debug examples - will be able to add many more once I re-add hooks for constraints.

I'd love to get some thoughts from the current contributors of this repo on what's being done over there, especially thoughts on the split of logic between cannon-worker and use-cannon.

Just picking some frequently appearing names on this repos commit history, @bjornstar, @Glavin001, @marcofugaro it would be good to get some thoughts from you folk at some point! (and any anyone else!)

[bjornstar]

It looks like a hard fork of the project, I'm not sure what we're supposed to say. I feel that we don't need to throw away the work that people have done on this codebase by copy/pasting it piecemeal into a new project. This could easily be done within the context of this project by adding an API layer between the worker and react portions.

Here's a quick attempt, totally needs more work, but you can see how it could go -- https://github.com/bjornstar/use-cannon/tree/cannon-worker-api

[isaac-mason]

That's a very fair comment @bjornstar.

I do understand that moving code into a new project like this totally comes across as undermining the efforts of this repos contributors, and that's definitely not my intent! Just a not-so-great looking side effect of my enthusiasm. My bad haha

My motivation for doing this is to create an easy way of running cannon in a web worker that isn't only usable in the r3f ecosystem. In my mind, it made sense for there to be a first-class standalone cannon-worker npm package for this. It also seemed like it would be worthwhile recreating that from the ground up to make sure that the non-react API made sense, make sure nothing breaks along the way, add types everywhere, etc.

I'd be happy to give it a go contributing along the lines of your example if you're happier with that approach and you think it's valuable. That API layer could be built-in use-cannon, then maybe at some point once the layer is fully built, an independently usable cannon-worker package could be split out?

Another option could just be for a cannon-worker package to go off and exist on its own without being tied to changing how use-cannon works, but to me it seems worthwhile de-duplicating the two.

[marcofugaro]

My motivation for doing this is to create an easy way of running cannon in a web worker that isn't only usable in the r3f ecosystem.

Hey Isaac, I approve the idea. In the vanilla.js world, I've seen people writing the cannon code in a worker and the three.js one in the main thread (just like worker ping-pong example or the SharedArrayBuffer example), but this doesn't work well if the user wants to split up the project in multiple files.

But if you want to make an API that handles this syncronization behind the scenes, I'd suggest you make the public API as similar to the cannon-es one as possible, since that's what users are familiar to.

Something like this:

import { World, Box } from 'cannon-worker';

// other three imports ...
// create three renderer, scene, camera, etc ...

// create physics world
// this spawns a worker and creates a world in it
const world = new World({
  gravity: [0, -10, 0],
  // other world params ...
});

// create a three box mesh
const mesh = new Mesh(new BoxGeometry(1, 1, 1), new MeshBasicMaterial());

// create a box
// the returned object is the "api" object from use-cannon
const box = new Box({
  mass: 1,
  shape: [1, 1, 1],
});
world.add(box); // .add() sends a message to the worker

box.sync(mesh) // keeps the position and quaternion of the mesh in sync

// step the physics world
world.step(1 / 60); // this sends a message to the worker as well

or if you want to make things 1:1, consider mocking also the shapes classes

const box = new Body({
  mass: 1,
  shape: new Box(1, 1, 1),
});

[marcofugaro]

Regarding the use-cannon/cannon-worker thing, I assume you are keeping the use-cannon examples just to test that everything works in the short-term.

In the long-term, it doesn't make sense to duplicate the same examples over there, which is what I think @bjornstar was pointing to. There shouldn't be any react in that repo.

[bjornstar]

I'd be happy to give it a go contributing along the lines of your example if you're happier with that approach and you think it's valuable. That API layer could be built-in use-cannon, then maybe at some point once the layer is fully built, an independently usable cannon-worker package could be split out?

I'd be happy to help with that approach, I was hoping that people would see the use-cannon repo as active and responsive to PRs and would try to contribute here.

[isaac-mason]

Thanks for the responses, all!

Those examples were just being added to cannon-worker short-term to test, yep. I wasn't looking to steal and re-home them 🙂

---

Re: building out cannon-worker API layer in use-cannon

@bjornstar sounds like the start of a plan then!

I'll halt my cowboy work over at cannon-worker now and shift my focus to helping do this in use-cannon 🙂

How can I best help with pushing this? Are you happy for me to work on a PR for use-cannon that sets up the start of that API layer, following your example? Or would you be more comfortable creating that base and having me work off that? Happy with either!

---

Re: the cannon-worker public api

@marcofugaro mirroring the public API for cannon-es is a good call! Makes sense. I also like the idea of mocking the shape classes to make it closer to the cannon-es API.

Maybe it could look something like this?

// we could only provide `shape` if the body is not a compound shape
const box = new Body({
  mass: 1,
  shape: new Box({
    args: [1, 1, 1],
    position: [1, 0, 0],
  }),
});

// ---

// we could also support calling `addShape(s: Shape)` to create compound bodies?
const box = new Body({
  mass: 1,
});
box.addShape(new Box({
  args: [1, 1, 1],
  position: [1, 0, 0],
}));
box.addShape(new Sphere({
  args: 1,
  position: [-1, 0, 0],
}));

// ---

// or provide `shapes` in the constructor for compound bodies 
const box = new Body({
  mass: 1,
  shapes: [
    new Box({
      args: [1, 1, 1],
      position: [1, 0, 0],
    }),
    new Sphere({
      args: 1,,
      position: [-1, 0, 0],
    }),
  ],
});

Another question is how instancing would look. Maybe something like this?

// If `Body.sync` is called with an InstancedMesh before adding to the world, instance the body.
// Offer two kinds of syntax - one being just providing the props as an object, an other being providing 
// the props as a GetPropsByIndex function, as in `use-cannon`
const boxWithoutFnSyntax = new Body({
  mass: 1,
  shape: new Box({ args: [1, 1, 1] }),
});
boxWithoutFnSyntax.sync(someThreeInstancedMesh);

// ---

const boxWithFnSyntax = new Body((index?) => ({
  mass: 1,
  shape: new Box({ args: [1, 1, 1] }),,
}));
boxWithFnSyntax.sync(someThreeInstancedMesh);

[marcofugaro]

Maybe it could look something like this?

I would avoid using the args keyword since it's a r3f thing, little did you know that cannon-es body already has support for a shape argument, so the simple body would look the same:

const box = new Body({
  mass: 1,
  position: [1, 0, 0],
  shape: new Box(1, 1, 1),
});

If you want to add a shape and a position relative to the body center of mass, the position goes actually as a second argument, so it would look something like this:

box.addShape(new Box(1, 1, 1), [1, 0, 0]);

but yes, as an enhancement it could be accepted in the constructor as well if we want, since the body already has those properties:

const box = new Body({
  mass: 1,
  shapes: [
    new Box(1, 1, 1),
    new Sphere(1),
  ],
  shapeOffsets: [
    [1, 0, 0],
    [-1, 0, 0],
  ],
});

---

Regarding instancing, I believe you still have to tell how many bodies to create (the Body constructor should handle sending a creation message to the worker, the sync just subscribes the mesh pos/quat to the body).

So it could be simplified like this:

// loop, you have to create a body per instance
for (let i = 0; i < count; i++) {
  const box = new Body({
    mass: 1,
    shape: new Box(1, 1, 1),
  });
  box.syncInstanced(instancedMesh, i);
  world.add(box);
}

where syncInstanced would invoke mesh.setMatrixAt instead of setting position/quaternion, example here