Open drcmda opened 3 years ago
Hi all, I started working on this concept with this branch: https://github.com/krispya/cannon-es/tree/exp/scaling
I have a proof of concept working which you can see with the 'Scaling' demo I added to examples. Right now the proof of concept only scales spheres and boxes, but I was curious what people thought before I made it more robust.
The main motivation for me to add this is to get easier interoperability between three and cannon-es when applying basic args to the mesh and bounding area created by cannon. A common use case for this is use-cannon which encourages sharing props between them. This turns the process into a single method call or as simple as setting an option on construct.
The main concern is this gets close to violating the rigid body contract. Schteppe wanted to enforce this by making users destroy and create a new body when they wanted to change its dimensions. For me, I thought it was enough to make scale update on set in the render loop like position and quaternion do, but instead have its own updateScale method much like updateAABB or other costly functions.
Updated to work with Complex Polyhedron and Cylinder now. I didn't bother touching Heightfield and Trimesh until there is more of a conversation. Trimesh has a local scale property and method which might be better than how I am handling it on shapes right now.
see: https://github.com/schteppe/cannon.js/issues/122 and: https://github.com/schteppe/cannon.js/issues/270
currently this is super unintuitive and it cannot be handled generically. use-cannon would have a hard time re-creating bodies just like that. would it be hard to give cannon bodies a simple scale: [x,y,z] prop?