Hey now 
I like the feature, but I think we would need to have a design meeting and think about how it would impact other systems (ways of updating the positions etc). I don’t think I can answer any more specific than that, part because I’m not an expert on the physics internals. 
Adding an issue for this so we can discuss it internally: #4170
That’s great, thanks for considering this!
+1 for this feature 
No sorry no change yet.
I am making an extension for Box2D, this functionality will be available in it.
Wow! Will the extension use game objects and collision shapes from the editor, or will it be “code only”?
Code only. You will have to setup some interaction between game objects and the extension. Plus at first not all functionality will be available, but people will be able to modify and extend the extension.
That still great. I had to use Hardon Collider, a Lua library, in one of my projects because the current limitations of Defold’s physics. I would have much preferred to use Box2D because of performance and flexibility.
After talking to @AGulev today I realised that we didn’t announce that linear and angular velocity of dynamic collision objects are no longer read only. We made this change in 1.2.171 but it never made it into any release notes:
And the documentation wasn’t updated until this beta release:
This is great, and timely because I’m about to start a new physics based game this week!
Update: Is this property available on Dynamic bodies only?
go.set("#collisionobject", "linear_velocity", vmath.vector3(100,0,0))
Using the above code on a Kinematic object seems to only move it once, as if set_position() was used. I would expect linear_velocity to be a continuous force for Kinematic objects, like it is in vanilla Box2D. This is useful for things like moving platforms and solid rotating objects.
Update 2: It seems like linear_velocity and angular_velocity can be set on a Kinematic collision object, but with decidedly unphysicsy (yes, it’s a word) results. This code:
timer.delay(2, false, function()
go.set("/platform1#collisionobject", "angular_velocity", vmath.vector3(0,0,-10))
go.set("/platform2#collisionobject", "linear_velocity", vmath.vector3(10000,0,0))
end)
Produces this:
Minimal project: KinematicLinearVelocity.zip (2.2 KB)
Am I misunderstanding how this should work, or is there something strange afoot?
Currently, it only works for dynamic objects yes.
Our kinematic objects still behave the usual way (i.e. needs another feature request)
The original feature request (and this thread) are mainly about Kinematic objects. I’m happy to create another one on Github if needed though.
I might have misread my own code, just now, and I did test it iirc, but it might need more testing now.
We do set the linear/angular velocity for the collision object in question. (regardless of kinematic/dynamic)
As for why it doesn’t work the way you need it, we’d have to investigate.
Cool. Based on the test above, it seems the velocities are set (and indeed returned if queried), and dynamic bodies appear to react in the right way (see ball1 and platform1). The thing that’s missing seems to be the continuous movement of the kinematic object.
The definition is described here:
A kinematic body moves under simulation according to its velocity. Kinematic bodies do not respond to forces. They can be moved manually by the user, but normally a kinematic body is moved by setting its velocity. A kinematic body behaves as if it has infinite mass, however, Box2D stores zero for the mass and the inverse mass. Kinematic bodies do not collide with other kinematic or static bodies.
Doing a quick test confirms my suspicion that we have two inputs that compete when updating the kinematic objects. First is the old way of getting the transforms from the “owner”, the collision object, which also gets its transform from the game object. This allows you to do a “go.set_position()” and then see your object move to the correct position.
Now, when the linear/angular velocities from Box2D also can affect the game object, we get a race condition, and the object will move, but also get immediately reset to the previous position.
Given the obvious problematics, I must have only tested the dynamic object case, which is my bad.
To solve this issue, we need to come up with a good design on how to control this behavior in a easy-to-understand manner.
I didn’t notice that this was a question of velocity for kinematic objects. It never occurred to me that this was needed for kinematic objects, despite it perhaps being possible in Box2d. The current difference between dynamic and kinematic object makes sense to me. Having velocity but not forces on kinematic objects feels weird.
I think it boils down to efficiency in the end. This is a good summary:
- Static bodies are unmoved.
- Kinetic bodies are moved based on their previous velocities.
- Dynamic bodies are moved based on their previous velocities, gravity, applied forces, applied impulses, masses, damping, and the restitution and friction values of their fixtures when they experience collisions.
Practically, in Defold, I don’t think it’s possible to remove gravity from a dynamic body. This means that dynamic bodies colliding with a moving platform is hard to achieve. Dynamic bodies colliding with a kinematic object which is “teleported” with set_position() each frame is unpredictable.
To me, the main benefit of having kinematic bodies with velocity would be a more stable physics simulation when using them in conjunction with dynamic bodies.
Better late than never: Since this is missing, and would be a great addition, I’ve added a new feature request:
yes that is the case, kinematic bodies are generally used for more controllable things like platforms and platformer characters. The main difference between them and dynamic bodies is the fact that kinematic bodies have infinite mass (stored as 0) therefore infinite inertia. Thats why force simulation in physics engine does not apply to them and dynamic objects cannot move them