 # Strange behavior when applying force (SOLVED)

#1

Why is applying force behave normally in that case: But strange in the vertical shot? I mean this should end like the first shot (on the height of the factory) but goes further down The only different between above is:

``````msg.post("#collisionobject", hash("apply_force"),
{force = vmath.vector3(0,12000,0), position = go.get_world_position()})
``````

and in the first one there is a 4000 as x value of the force vector.

Below is the repro:

Empty Project.zip (21.0 KB)

0 Likes

#2

How are you calculating the force vector? Are you using a radian / angle and converting it to a unit vector and then multiplying a force magnitude value?

edit.zip (3.1 KB)

``````it = it or 0

function init(self)
it = it + 1
print("I'm here", msg.url())
--local dir = math.pi / math.random(1,10)
dir = it / 10
local heading = vmath.vector3(math.cos(dir), math.sin(dir), 0)
local power = 75000
local force = heading * power

msg.post("#collisionobject", hash("apply_force"),
{force = force, position = go.get_world_position()})

timer.delay(3, false, function() go.delete() end)
end
``````
1 Like

#3

Ok, but does it even matter? I used just vmath.vector3(0,12000,0) - why is it bad if the result of calculating angles and multiplying is also a vector3? I don’t know why it would be non deterministic? Does the moment of applying forces depends on the frame or something? I have no idea 1 Like

#4

I’m trying to understand how you are figuring out the force vector to use.

If I understand you then you have two vectors

``````vmath.vector3(0,12000,0)
``````

and

``````vmath.vector3(4000,12000,0)
``````

or

``````vmath.vector3(4000,0,0)
``````

?

In any case, these have different lengths, which means the final force applied will be different.

``````	print(vmath.length(vmath.vector3(0,12000,0))) --> 12000
print(vmath.length(vmath.vector3(4000,12000,0))) --> 12649.110351563
print(vmath.length(vmath.vector3(4000,0,0))) --> 4000
``````

That’s why I say you should first get a unit vector of length 1 and then multiply it by however much force you want to apply in that direction.

But maybe there’s something I’m not understanding?

Don’t forget that besides force there is gravity too.

Can you explain what you are trying to do?

3 Likes

#5

Hi there!

I have tried the repro and, in my opinion, there Is something strange.

The equation of motion of a free body under Gravity Is Linear. This implies that the movements along different axis are Independent.

If I apply the force (0, 12000, 0) or the force (4000, 12000, 0) I must get the same behaviour along the Y axis. And this Is not what I see in the repro.

Maybe init Is not the right Place to apply forces? And, more important, for how long the msg apply_force applies the given force? This must be guaranteed to be constant along the simulation.

Indeed, what change velocity Is the product F*DT, where F Is the force and DT Is the interval of time the force Is applied.

I apologize for the length of this post about elementary physics…

0 Likes

#6

They have different magnitudes. Compare e.g. with a “softer” or “harder” push.

for how long the msg apply_force applies the given force?

It is applied once, for that frame.

1 Like

#7

The two forces have the same Y components, so the mass should move in the same way along the Y axis (this is the superposition principle). And, if I understand, @pawel.jarosz21 is reporting that it is not.

The X components are different, hence the movements along X are different. So the total push is different as @Mathias_Westerdahl has said.

0 Likes

#8

Is your example project really the same as the one in your gif’s?
In both cases, the particle dies after 2 seconds, since you have the timer set to 2 seconds.
When running it, it does not look like your second gif for me.

0 Likes

#9

print("y = " … go.get_position().y)

before go.delete() in ball.script in order to print the last value of Y before the deletion. This SHOULD be independent of the X component of the force applied to the body.

When the force (4000, 12000, 0) is applied I see “y = 129.16…”
When the force (10000, 12000, 0) is applied I see “y = 86.15…”

I hope this may help to explain the “strange behavior” reported by @pawel.jarosz21

Ciao!

2 Likes

#10

Ok, so I think I get misunderstood. It’s not about a magnitude - it’s constant in both cases (doesn’t matter, that it has a different magnitude). The strange behavior is that in the vertical shot presented in the second gif in my first post, normally the ball is deleted before falling below the starting point, but sometimes, the ball is falling below it:  0 Likes

#11

That sounds more like an issue related to the way you are deleting the object somehow. Could you modify your test to have a timer of dt increment inside the script’s update instead of using timer.delay() and see if you still see the odd behavior?

Worth noting in your uploaded example the group and mask are the same value. So since you create and destroy at the same interval, it’s possible that sometimes the creation happens before deletion where there are 2 objects in a single frame which pushes a ball downward on spawn to create an illusion? Try alternating the orb color too.

5 Likes

#12

You are right!

I didn’t notice I wasn’t changing collisionobject groups nor masks It explains the issue, ball was simply colliding with other and was bumped up, and it was noticed only in a vertical shot, because in the leaned shot there were no collisions Moreover the timing in the first gif I uploaded was so bad, that the created ball was bumped down by a ball falling just before it was deleted.  Different collision groups vs overlapped collision groups.

What a dumb mistake Thank you! 5 Likes

#13

Great @pawel.jarosz21 @Pkeod.

However it seems to me that the problem I mentioned in my last post about the Y final position that should be independent of the X component of the force is still there. And there is no collision involved.

I have to say that I do NOT use physics, so my interest in that problem is limited but if someone want to investigate further…

Ciao!

1 Like

#14

Defold uses Box2D for its 2D physics. May be worth reaching out to the Box2D users/devs and asking about it.

0 Likes

#15

I am quite sure Box2D simulate the physics in the right way Maybe there is something I am overlooking on the Defold side but I have no doubt about the physical content of the remark above.

0 Likes

#16

Can you make a new topic about the issue you are seeing? I am still confused about it. And I’m no physics expert either.

0 Likes

#17

Ok! I will try to adapt the small repro of @pawel.jarosz21 and start a new topic. However I am not an expert about physics in Defold…

2 Likes