Collision Polygon and physics results in awkward movement

Whenever I try using both a collision polygon and physics behavior, the object always ends up moving at a weird angle, even if the polygon is perfectly symmetrical. Why is this?

I have, for a long time, been interested in setting up custom physics instead of using the preset behavior, but I've been having a lot of issues figuring out the math for it.

EDIT: I've also noticed that any time I give a physics object a collision polygon that it not only moves at a weird angle, but faster than it is supposed to, if that helps anyone figure out what is going on.

Ajbael The same thing has happened to me aswel!

The 'faster than its supposed to' thing is because of the density - which is judged by the area of the collision polygon. By reducing the area of the polygon from the bounding box, you decrease the perceived 'mass' of the object.

Unfortunately, I can't explain why you're getting asymmetrical movement problems - it's not something I've come across myself

The 'faster than its supposed to' thing is because of the density - which is judged by the area of the collision polygon. By reducing the area of the polygon from the bounding box, you decrease the perceived 'mass' of the object.

Unfortunately, I can't explain why you're getting asymmetrical movement problems - it's not something I've come across myself

Good to know about mass calculations, I thought it was based on the size of the sprite. As far as movement is concerned, would you be able to upload an example of a controllable sprite that has both physics and is also using a collision polygon? Something as simple as a sprite that rotates toward the position of the mouse and accelerates while "W" is held would be a big help to me.

I've tried simplifying everything down to the bare bones to try to figure out where the asymmetrical movement is coming from, but I haven't found any leads.

Wouldn't it be easier for you to provide your .capx so we can see exactly what problems you have and hopefully offer clearer assistance?

Wouldn't it be easier for you to provide your .capx so we can see exactly what problems you have and hopefully offer clearer assistance?

There's not much to provide, I have the problem even when I strip it down to the bare bones.

The player sprite has the physics behavior and uses the collision polygon. The player sprite rotates toward the position of the cursor, and force is applied to the player sprite in the direction it is facing when "W" is held. The result is that the player sprite will fly crooked/drift when facing in most direction unless I used the bounding box or circle.

Well, strip it to the bare bones, and share the .capx.

Well, strip it to the bare bones, and share the .capx.

https://drive.google.com/open?id=0B9tqO ... mVheVpWUDA

I do not see a collisions setup in that capx. So i do not understand the initial question, still.

About this capx.

Besides a few weird things that you do, i see nothing wrong, or i miss something.

Weird things ? ....

1 In the physics world there is no such thing as an immediately movement, like you rotate that sprite. That will mess things up, got to do things smoothly. (with respect to time).

2 You compare to mouse coordinates that are not on the layer that you are moving, due the parallax. Run it in debug, en click 'mouse', watch the coordinates for the layers, you will understand.

So, if i do those things in a better way .....

https://www.dropbox.com/s/4sqbnd0bjioqe ... .capx?dl=0

..... Do we still have problems ? Do i miss something ?

I do not see a collisions setup in that capx. So i do not understand the initial question, still.

About this capx.

Besides a few weird things that you do, i see nothing wrong, or i miss something.

Weird things ? ....

1 In the physics world there is no such thing as an immediately movement, like you rotate that sprite. That will mess things up, got to do things smoothly. (with respect to time).

2 You compare to mouse coordinates that are not on the layer that you are moving, due the parallax. Run it in debug, en click 'mouse', watch the coordinates for the layers, you will understand.

So, if i do those things in a better way .....

https://www.dropbox.com/s/4sqbnd0bjioqe ... .capx?dl=0

..... Do we still have problems ? Do i miss something ?

There is no collision setup because I'm not having a collision issue. The issue is that whenever I use a Collision Polygon for a Physics object, that object will drift or move at a weird angle while moving.

It seems like the capx you provided with mouse coordinates relating to the layer the ship is on and replacing immediate turning with velocity based turning did smooth things out a bit, but the issue remains.

It is most noticeable when trying to follow a straight path while going up or down, the player object will drift along the side of the path you're trying to follow.

Now i understand the problem. I apologize for not getting it earlier.

The reason for this is that the force is pushes from the center of mass and the rotation takes the origin.

But lets first go the path that you started. starting from the collision polygon.

Lets explore the center of mass, see if it drifts.

https://www.dropbox.com/s/6s7ay6vwoxtqb ... .capx?dl=0

It does not. It is pretty stable. But it is a little of do inevitable floating point calculations.

Is that enough to cause a torque when applying a force ?

https://www.dropbox.com/s/s2kl9qpgilaoo ... .capx?dl=0

Darn it, yes it does. So in some way, your guts are right.

Same problem when we use an exact imagepoint ?

https://www.dropbox.com/s/92uz1kof9rsp7 ... .capx?dl=0

Nope, not at all. So it kinda a butterfly effect, a little mathematical error that cause big changes.

I have no idea if it possible to do this better. In real life it is not possible, just less noticeable do the proportions of mass, forces, gravity ..... and so on.

Question remains, is this the cause of the problem we face.

https://www.dropbox.com/s/tb85vpfaawclh ... .capx?dl=0

No, no, i still notice drifting. An that is because the rotation gripes on the origin and the force gripes on an imagepoint that is not the origin. Those forces do not balance out.

But, we can not rotate an object with the center of mass as origin. Well, in a way we can, just set a torque towards the mouse coordinates on that layer. But then i dont know how to avoid the wobbling, the torque will always overshoot a little.

So, we have no other chance (but i am not the smartest in here, maybe someone knows how to stop the wobble) then taking the two system apart. The 'system that rotates in tick steps' and the 'physics system'.

Here goes:

https://www.dropbox.com/s/8tmehuf4r61tc ... .capx?dl=0

Hope this explanation satisfies you.

Now i understand the problem. I apologize for not getting it earlier.

The reason for this is that the force is pushes from the center of mass and the rotation takes the origin.

But lets first go the path that you started. starting from the collision polygon.

Lets explore the center of mass, see if it drifts.

https://www.dropbox.com/s/6s7ay6vwoxtqb ... .capx?dl=0

It does not. It is pretty stable. But it is a little of do inevitable floating point calculations.

Is that enough to cause a torque when applying a force ?

https://www.dropbox.com/s/s2kl9qpgilaoo ... .capx?dl=0

Darn it, yes it does. So in some way, your guts are right.

Same problem when we use an exact imagepoint ?

https://www.dropbox.com/s/92uz1kof9rsp7 ... .capx?dl=0

Nope, not at all. So it kinda a butterfly effect, a little mathematical error that cause big changes.

I have no idea if it possible to do this better. In real life it is not possible, just less noticeable do the proportions of mass, forces, gravity ..... and so on.

Question remains, is this the cause of the problem we face.

https://www.dropbox.com/s/tb85vpfaawclh ... .capx?dl=0

No, no, i still notice drifting. An that is because the rotation gripes on the origin and the force gripes on an imagepoint that is not the origin. Those forces do not balance out.

But, we can not rotate an object with the center of mass as origin. Well, in a way we can, just set a torque towards the mouse coordinates on that layer. But then i dont know how to avoid the wobbling, the torque will always overshoot a little.

So, we have no other chance (but i am not the smartest in here, maybe someone knows how to stop the wobble) then taking the two system apart. The 'system that rotates in tick steps' and the 'physics system'.

Here goes:

https://www.dropbox.com/s/8tmehuf4r61tc ... .capx?dl=0

Hope this explanation satisfies you.

No worries about the misunderstanding, I really appreciate the input!

There is still some drifting and wobbling, although certainly much less now.

Knowing that this issue is a result of the two forces being applied to two different points gives me something I can work with when it comes to problem solving. However I'm not sure why that is an issue when a collision polygon is being used but not an issue when a circle or bounding box is being used.

Either way I'll get back to you if I ever figure out how to solve this issue completely. Can't help but feel like there must be a simpler way to do this.

You've given me a lot of information to work with, thank you so much

This is the most accurate version i can make with my simple talents.

https://www.dropbox.com/s/52ic3swmbkd27 ... .capx?dl=0

The angle is always calculated with the same, non outgrowing, distances.

When doing this on the parallaxing layer the little errors get bigger when it gets far away from the layout origin.

The centre of mass is not used. I just can not get it done when using the centre of mass.

This is the most accurate version i can make with my simple talents.

https://www.dropbox.com/s/52ic3swmbkd27 ... .capx?dl=0

The angle is always calculated with the same, non outgrowing, distances.

When doing this on the parallaxing layer the little errors get bigger when it gets far away from the layout origin.

The centre of mass is not used. I just can not get it done when using the centre of mass.

The second to last one actually had the least drift, but I think we might be approaching this all wrong. Even if the drifting is caused by the two forces acting on two different points, this issue doesn't exist when using a bounding box or circle and for that reason I'm pretty sure its a bug.

So I filled out a bug report, and hopefully it can be fixed before I lose my mind trying to figure out how to get physics objects using collision polygons to move the way they're supposed.

Thanks again for all your help, I'm going to continue working on this until I find a work around or the bug gets fixed. I've learned some important things about layer coordinates and how the physics engine works through this!