Discussion : Performance improvements, but some strange bugs

[d3x0r]

Hello.

I've been tinkering with an additive rotations... https://github.com/d3x0r/stfrphysics#live-demos
Using Log-Quaternions, or just angular velocities. Since a physics engine internally thinks in angular velocity anyway, there is less math to just update the angle-angle-angle representation of a quatrernion.

https://d3x0r.github.io/cannon.js/examples/worker.html This demo with cubes, once the cubes are on the plane, they seem to have a ghost rotation force, that seems to want to turn them upright (somewhat).

And https://d3x0r.github.io/cannon.js/examples/hinge.html (raycast vehicle demo) has a strange behavior - (need to improve rendering constraints in debug info)... if you could take a moment and give me an insight where angularVelocity is actually updated?

I was also attempting to apply velocity/position as a (final+initial)/2; which gives closer results across varying framerates; that in itself doesn't cause the issue.

https://github.com/d3x0r/cannon.js/blob/improve_accuracy/src/math/lnQuaternion.js#L390 (multiple angular rotation to a point, is a couple less multiplications than the equivalent quaternion https://github.com/d3x0r/cannon.js/blob/improve_accuracy/src/math/Quaternion.js#L251 Although the quaternion mult() to rotate a rotation is slightly more work... on the other side though, integrate becomes a direct scaled addition; and conversion from internal angle-angle-angle to axis-angle is just getting the length of the vector, and normalizing it, and then building cos(length/2), sin(length/2)*(x,y,z) for the quaternion.

The lnQuaternion/Quaternion is switchable with a new 'config.js' setting, so I can swap between one or the other just by changing which is require()ed. It passed all tests, but still failed the container test; added a container test, and now the stacks of balls in containers works well. Previously they spilled all over the plane, and appeared to rotate correctly... and thie spheres on a mesh appear to rotate correctly so I'm not sure where the constraint resolutions are failing; or really where the real work to update the angular velocity is done. It's not built as a change at the end... when the body is updated it's angularVelocity already has a value, and there's no torque to apply.

[d3x0r]

I did fix several of these tests by fixing the integrate. The only thing that malfunctions is the point pick on a cube. The rotational velocity increases without bound.

[arpu]

@d3x0r looks great but i think you should add your findings to https://github.com/pmndrs/cannon-es