Armory: applyForce() does not take rotation into account

[MoritzBrueckner]

First of all: this is more like a missing feature than a bug.

When using applyForce() (Documentation) on rigid body objects, the second parameter loc of that function works like an offset in world coordinates, but the rotation of the object is not taken into account.

I know that loc probably stands for "location" and not for "local", but for me it makes way more sense to use the second parameter as an offset from the object that isn't using world coordinates but local coordinates. In most cases, the second parameter is used to describe a position at the game object the force is applied to, so it should take in a vector in local space (offset from the objects center) and respect the object's rotation.

If the input is (1, 0, 0, 0) (= apply the force 1 unit left of the object's origin), it should always be left of the origin regardless of the rotation of that object. Currently, if you rotate the object 90 degrees left on the z axis, the force will be applied at the front of the object.

So as a workaround, you need to rotate every point with the object's rotation to get a relative position vector that properly works with applyForce().

[QuantumCoderQC]

I think it is best kept as is. The reason is the Bullet Physics library defines the "location" vector in applyForce() as the "location in the world co-ordinates" from which the force seems to be applied. It may cause more confusion if the definitions in BulletPhysics and Armory3D differ.

As you mentioned, the "work-around" of applying force is a better option. Or maybe use an empty parented to the object you use and then apply force from that empty's location.

[MoritzBrueckner]

If Bullet defines it so, that's how it should be. Thank you for clarifying this :)
We definitely need better documentation of the available methods