Adding groups to physics engine

I’ve just started have issues when trying to add display groups to the physics engine. My code looks like this:

[lua]

    local hw=obj.contentWidth/2

    local hh=obj.contentHeight/2

    local shape={

      -hw,-hh,

      hw,-hh,

      hw,hh,

      -hw,hh

    }

  

    physics.addBody(obj,“dynamic”,{density=60.0, friction=0.8, bounce=0.1, shape=shape, filter=collisionFilter})

[/lua]

If obj is a image object the bounding box works fine - (I define it manually as obj will have x and y scales between 0.7 and 1). If the object is a displayGroup containing a rectangular image, the bounding box appears around the top left corner of the group. 

Is there anyway around this? I’ve tried setting the reference point. What I want to achieve is to have physics objects made up lots of smaller images, but which behave as a single rigid body with a bounding box that I define.

Thanks,

Display groups have reference point in top left corner at default. Did you try to set reference point before adding body? If so then I suspect it can be default physics lib behaviour.

I agree, it looks like it’s related to the group’s reference point, but I tried setting it just before to no avail. In fact doing so to the top of the example made no difference. 

For reference, here’s what I tried:

[lua]

 obj:setReferencePoint(display.CenterReferencePoint)

    

    local hw=obj.contentWidth/2

    local hh=obj.contentHeight/2

    

    local shape={

      -hw,-hh,

      hw,-hh,

      hw,hh,

      -hw,hh

    }

  

    physics.addBody(obj,“static”,{density=60.0, friction=0.8, bounce=0.1, shape=shape, filter=collisionFilter})

[/lua]

I also tried playing around with the origin and reference values for the object, but couldn’t really make a difference. I’m wondering how the physics engine derives what the centre is?

Maybe Corona api is constructed this way what when you create physics body then default reference point is taken - so for image it will be center, but for display group it’s corner…

However you can make simple workaround

local dgw=obj.contentWidth local dgh=obj.contentHeigh local shape={ 0, 0, dgw, 0, dgw, dgh, 0, dgh }

:slight_smile:

Hi @tap32,

When you construct a “shape” physics body, the coordinates are always based around the center point of the object… referencePoint has no effect on that. So, in most cases, you should always construct the body shape based on the relative coordinates of the object, not a group or some other “global” coordinates.

Brent

Hi Brent, 

Thanks for the explanation. So is there any way of fixing the situation? At some level I think I need an image group to deal with the 12 or so individual images which make up the shape.

Hi @tap32,

Can you be more specific about your ultimate plan with this, and describe how you envision it working? I’m sure there’s a resolution, but I’ll need to hear more details.

Thanks,

Brent

Hi Brent,

Thanks for helping out. So, what I’m trying to make is a physics based room editor. Within the room I want the user to be able to place mini-games which when activated the camera zooms in on and the user can then play seamlessly (when I say camera, I just mean some clever scaling and transformation effects of 2D images). The mini-games themselves consist of a lot of different components, but within the room I want them to behave as single physical images (imagine a Wheel of Fortune for instance - you would have to use several images to create it, but within the room it would just be a single complex rigid body).

Hope that makes sense! So the easy solution would be to have a single image for the mini-game in the room and then to switch to group of images when it’s played. I’ve been resisting that approach because it adds an extra layer of complexity to development - I wind up having two sets of images for one objects, and possibly two sets of animations, and changes have to be mirrored across both sets, plus I wind up with extra images. 

Out of interest are my responses supposed to be on top, or is the link I get in my e-mail doing something strange?

[Edit]: They don’t when I revisit the page, but they do when I post…

Hi @tap32,

I’m not sure how complex you’ll be making this, but as a general rule, remember that physics “worlds” must be treated as a whole unit at an over-arching level. You can put objects in all different groups as necessary, but if you move the “camera” around, you need to move the physics world as a unified whole, otherwise collisions will not function as expected.

Brent

Hi Brent,

I think I am making things quite complex, I already have three different layers each with the their own collision filters to make sure they don’t collide… but as the minigames themselves don’t use physics I think I should be fine. I actually disable the physics engine when they’re active. 

However I think in terms of adding a group, using piotrz55’s suggestion has worked for me. There’s been a lot of additional work I’ve had to do in the supporting code to accommodate groups as objects, but simply checking for a numChildren field and adjusting the centre x and y coordinates accordingly has so far solved all the problems.

Thanks for all the help

Display groups have reference point in top left corner at default. Did you try to set reference point before adding body? If so then I suspect it can be default physics lib behaviour.

I agree, it looks like it’s related to the group’s reference point, but I tried setting it just before to no avail. In fact doing so to the top of the example made no difference. 

For reference, here’s what I tried:

[lua]

 obj:setReferencePoint(display.CenterReferencePoint)

    

    local hw=obj.contentWidth/2

    local hh=obj.contentHeight/2

    

    local shape={

      -hw,-hh,

      hw,-hh,

      hw,hh,

      -hw,hh

    }

  

    physics.addBody(obj,“static”,{density=60.0, friction=0.8, bounce=0.1, shape=shape, filter=collisionFilter})

[/lua]

I also tried playing around with the origin and reference values for the object, but couldn’t really make a difference. I’m wondering how the physics engine derives what the centre is?

Maybe Corona api is constructed this way what when you create physics body then default reference point is taken - so for image it will be center, but for display group it’s corner…

However you can make simple workaround

local dgw=obj.contentWidth local dgh=obj.contentHeigh local shape={ 0, 0, dgw, 0, dgw, dgh, 0, dgh }

:slight_smile:

Hi @tap32,

When you construct a “shape” physics body, the coordinates are always based around the center point of the object… referencePoint has no effect on that. So, in most cases, you should always construct the body shape based on the relative coordinates of the object, not a group or some other “global” coordinates.

Brent

Hi Brent, 

Thanks for the explanation. So is there any way of fixing the situation? At some level I think I need an image group to deal with the 12 or so individual images which make up the shape.

Hi @tap32,

Can you be more specific about your ultimate plan with this, and describe how you envision it working? I’m sure there’s a resolution, but I’ll need to hear more details.

Thanks,

Brent

Hi Brent,

Thanks for helping out. So, what I’m trying to make is a physics based room editor. Within the room I want the user to be able to place mini-games which when activated the camera zooms in on and the user can then play seamlessly (when I say camera, I just mean some clever scaling and transformation effects of 2D images). The mini-games themselves consist of a lot of different components, but within the room I want them to behave as single physical images (imagine a Wheel of Fortune for instance - you would have to use several images to create it, but within the room it would just be a single complex rigid body).

Hope that makes sense! So the easy solution would be to have a single image for the mini-game in the room and then to switch to group of images when it’s played. I’ve been resisting that approach because it adds an extra layer of complexity to development - I wind up having two sets of images for one objects, and possibly two sets of animations, and changes have to be mirrored across both sets, plus I wind up with extra images. 

Out of interest are my responses supposed to be on top, or is the link I get in my e-mail doing something strange?

[Edit]: They don’t when I revisit the page, but they do when I post…

Hi @tap32,

I’m not sure how complex you’ll be making this, but as a general rule, remember that physics “worlds” must be treated as a whole unit at an over-arching level. You can put objects in all different groups as necessary, but if you move the “camera” around, you need to move the physics world as a unified whole, otherwise collisions will not function as expected.

Brent