The library aframe-physics-system which I’m using to add physics to my scenes supports 2 physics engines, cannon.js and ammo.js, but recently I started using the library super-hands-component and it’s component super-hands attached to the A-Frame component hand-controls in order to provide a more natural way to interact with the elements of the scene, but super-hands-component is only compatible with the cannon.js engine. The problem arises with the latest version of A-Frame, which breaks the support of cannon.js and i’ts uncertain if they’ll fix it in the future or ammo.js will become the only supported physics engine.
Keeping that in mind, the problem I faced is that when the user tries to grab a virtual object, it doesn’t work if I use A-Frame 1.2.0 and the super-hand component. After some days of testing and debugging, I realized that the problem is that the super-hand component creates a constraint component on the entity grabbed and that component isn’t defined on ammo.js, instead, if that engine is used, the component that represents the constraints is called ammo-constraint, so the solution in this case is to create an ammo-constraint instead of a constraint.
I’ve forked the super-hands-component repository to introduce this changes ( link ), but by the time I was going to open a pull request, I found an issue where the github user diarmidmackenzie purposed a more complete solution.
Here I show 4 scenes I created to illustrate the problem. Note that in the first two we can only grab the entities on the one which uses cannon.js, but on the last two I replaced the super-hands-component script mine, on which I’ve introduced the modifications required to be able to grab the entities with both cannon.js and ammo.js engines.
- Scene with cannon before the changes ( Code )
- Scene with ammo before the changes ( Code )
- Scene with cannon after the changes ( Code )
- Scene with ammo after the changes ( Code )
Solution adopted
After making my own modifications over the super-hands-component code, I finally decided to use the fork made by diarmidmackenzie as he considered more things when making the code compatible with ammo.js than I did (I changed the bare minimum to make the component work on my use case)