Inferring physics shape parameters from three.js objects?

[donmccurdy]

I'm currently maintaining a library (https://github.com/donmccurdy/three-to-cannon) that creates cannon.js shapes, given three.js objects and some user input on e.g. cylinder orientation. That library is aging (needs significant updates for Geometry -> BufferGeometry changes in recent three.js versions) and would probably benefit from a port to TypeScript. The library was originally written for A-Frame, which I'm much less involved with these days. So I'm trying to get a sense of what r3f users are doing here and whether there's overlap, rather than starting a major refactor based only on my earlier experiences with A-Frame.

Does use-cannon infer cannon.js shape parameters, or does the user configure this? If inferred, is that happening at runtime or somewhere offline like gltf2jsx? Basically wondering if there's something in this project I should try to reuse, or if you'd have any opinions on the direction of three-to-cannon.

Thanks!

[isaac-mason]

Hi @donmccurdy! Hoping I can re-spark some discussion around this! @react-three/cannon doesn't do any shape inference at the moment, but I think it would be a great addition :)

One difficulty I found using three-to-cannon as-is with @react-three/cannon is that cannon shapes and bodies are constructed from properties sent to a web worker, not from shapes directly. We can use properties from the shape that three-to-cannon generates as inputs to @react-three/cannon hooks - e.g. https://codesandbox.io/s/using-three-to-cannon-with-use-cannon-q0p282

But this is a little wasteful in generating a shape, only to take its properties and send them to a web worker to reconstruct the shape there again.

I'd be interested in hearing your opinions on whether three-to-cannon could also support returning props for a shape instead of a cannon-es shape. If you're open to that, I'd be happy to put together a PR?

[donmccurdy]

At one point I'd written some code to serialize/deserialize CANNON.Shape objects, you can still find that here:

https://github.com/n5ro/aframe-physics-system/blob/59100ac83033cf337d26925de1f92854c2988b75/src/utils/protocol.js#L141-L186

But I suppose generating the shape in the first place is a little wasteful if we're just going to serialize it. I'm certainly open to returning the props instead of just a Shape instance. Also note that the library may return an offset and/or quaternion defining the local transform of the shape.

[isaac-mason]

Ah nice! Though yes, it may be a little wasteful.

And noted re the local transform! :)

Do you have any thoughts on what that change to three-to-cannon should look like?

e.g. we could add output to ShapeOptions, which could determine whether ShapeResult -> shape is a cannon-es shape or props/constructor args for a shape?

enum OutputType {
  SHAPE = 'SHAPE', // default
  PROPS = 'PROPS',
}

const result = threeToCannon(object3D, { output: OutputType.PROPS }); 

Or alternatively, we could create a separate method for returning shape props?

[isaac-mason]

( I can probably move this discussion into an issue on three-to-cannon... 🙂 )

[donmccurdy]

My first thought would be a new export, something like...

import { threeToCannon, getShapeParameters, ShapeType } from 'three-to-cannon';

const { shape, offset, quaternion } = threeToCannon( object3D, { type: ShapeType.BOX } );
const parameters = getShapeParameters( object3D, { type: ShapeType.BOX } );

... perhaps with threeToCannon using that function internally.

[isaac-mason]

I'll find some time to create a PR going down that path then! Thanks