donmccurdy
commented
6 years ago Thanks for the demos, having motion-capture makes this so much easier. 😅
The looseness of the constraint is inherent in the CANNON.Constraint implementation as far as I can tell. There is a maxForce property on the constraint, and you would think that increasing it would limit swimming, but it doesn't seem to change anything when I increase it further.
The most recent release (3.0.0) allows you to change the type of a body after it has been defined. Haven't tested this but I think your best bet would be: (1) use body="type: dynamic; mass: 5" instead of the dynamic-body component, and call setAttribute('body', {type: 'static'}) when the object is grabbed. You can then set its body.position arbitrarily. May also want to set the body's rotation and velocity to get realistic collisions.
Reparenting in the DOM is iffy, the physics system has no scene graph and everything is done in world coordinates — my implementation of that conversion is not perfect I don't think, and in any case slows things down. Best to keep physics stuff at the root of the scene where possible.
At some point I'd like to investigate AmmoJS or OimoJS further, as alternatives to CannonJS, perhaps they won't have this issue.
Working to attach a dynamic-body to the controller so it can be picked up & thrown around...
After poking around a bunch of code / issues / examples (extras grab.js, super-hands, aframe-physics-extras)
I saw that the general suggestion is to use a lock constraint.. but have noticed that the locked body lags/swims around a bunch (which invokes motion sickness for me). This is present in a lot of the examples I'd found around the web as well.
Eventually whittled down to a dead simple example that makes me believe it is the constraint?
<a-entity static-body="shape: sphere; sphereRadius: 0.2;" hand-controls="left" id="left-hand"></a-entity><a-box dynamic-body constraint="target: #left-hand; type: lock;" width=".2" height=".2" depth=".2" color="blue"></a-box>Motion captured demonstration: https://free-budget.glitch.me/
Try in VR https://free-budget.glitch.me/?avatar-replayer-disabled
Thoughts? Am I missing something? I'm going to start looking around the constraint code. Physics system update rate issue? Glitch in the constraint? If no, wondering if there a special case that could be implemented (ala kinematic-body)? Seems like a rock solid grab is pretty important for A-Frame (thinking of how influential VRTK is for Unity, and how close superhands is to matching it).
Considering a workaround that uses a non-physics grab system I made, then copying over the forces of a hand-attached dynamic body when a grab release is fired.
(Implemented my own grab system for fun/education before I attempted to add any physics and I got it working pretty well. Just using a naive tick-based implementation, where I continuously update the grabbed object’s position and rotation to follow a hand. Started by trying to do reparenting in the DOM, then various THREE level manipulations via https://github.com/aframevr/aframe/issues/2425, but hit different walls in those directions)
Let me know what ya think / thanks for all the work on this lib!