Sign in to follow this  
flow

P2 physics child bug?

Recommended Posts

I've played around with P2 physics and created a sprite that has a child attached that can (is supposed to) move freely around the parent.

The child should still contribute to collisions with other objects so I gave it a P2 body as well, but it was behaving very odd. A closer look at the debug data revealed that the collision shape and the sprite image are not at the same position o_O in fact the collision shape is located at an absolute position in the world that relates to the relative coordinates between parent and child and does not move at all.

Here is an example that you can try with the sandbox editor:

game.physics.startSystem(Phaser.Physics.P2JS);
    
var parent = game.add.sprite(200, 200, 'phaser');
game.physics.p2.enable(parent, true);
parent.anchor.set(0.5);

var child = game.make.sprite(100, 100, 'phaser');
game.physics.p2.enable(child, true);
child.body.static = true;
child.anchor.set(0.5);
child.angle = 0;
parent.addChild(child); 

If you look at the attached image you can see the offset. When dragging the parent around with the mouse the collision shape will stay at a fixed position, but it CAN collide with the parent.

This issue might be related to an older discussion:

Any ideas how we can fix this (that don't involve creating the child as a "free" sprite and let it follow the parent via the update() function)?

p2_child_bug.jpg

Share this post


Link to post
Share on other sites

basically when you're using physics, you should make your scene hierarchy flat at the level, where all bodies occupy the same level of hierarchy - for example: you have root, which have UI and world children, and those have 0;0 position in world, so every child of world have proper mapping of its physics position matching rendering position.

Share this post


Link to post
Share on other sites

I thought the whole point of adding children to something is that I don't have to manually set all the follow-position, follow-rotation, kill-on-parent-death stuff myself ...

are you saying we just simply should not use children with P2 physics?

Share this post


Link to post
Share on other sites

well, source of this problem is that it uses physics engine, and those does not follow hierarchy pattern, to work correctly, they have to have flat hierarchy (root as world, and bodies as world children) - think of it as your hierarchy should just visualize physics and not constrain physics transformations into it.
to make bodies follow your hierarchy you have to make them kinetic bodies, but that makes whole physics simulation pointless - there is no solution other than flatting your world-level visual hierarchy to match physics transformations.

Share this post


Link to post
Share on other sites

I don't think that physics and parent-child hierarchy are generally something to be avoided, since 
1) it works fine with arcade physics and

2) the function itself even has the option to handle all the children with the same body ... "enable(object [, debug] [, children])" ... (I've tried that too but it does not change anything).

I have the feeling that there is simply some sprite.x, sprite.y call that should be a sprite.world.x, sprite.world.y call :(

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.