Collisions not happening

Physics
#1

I was attempting to make a field of little pegs using a function to create them. As I created each peg they were added to a peg displaygroup so that I could later move the entire field of pegs if I wanted. However I can’t seem to get my ball and my peg field to interact or collide using the box2d engine. Here is my code for creating the ball.

function PlayObjects:newBall( ) local ballGroup = display.newGroup() ballGroup.type = "gameBall" local ball = display.newCircle( ballGroup, 0, 0, ballR ) ball:setFillColor(0,0,0) physics.addBody( ballGroup, { density=1.0 , friction=0.5, bounce=0.6, radius = ballR } ) return ballGroup end

Then I created my peg field with the code below.

function Obstacles:newPegField(w, h, rotation) local pegField = display.newGroup() local pegSize = \_H\*.005 local pegSpace = ballR\*2 for i = 1, math.floor(h/pegSpace) do for j = 1, math.floor(w/pegSpace) do local peg = display.newCircle( pegField, 0, 0, pegSize ) peg:setFillColor(0,0,0) physics.addBody( peg, "static", { density=1.0 , friction=0.5, bounce=0.3, radius = pegSize } ) if (i%2 == 1) then peg.x = j\*pegSpace else peg.x = j\*pegSpace + .5\*pegSpace end peg.y = i\*pegSpace end end return pegField end

The above constructs a field of pegs kinda like a carnival game or plinko. However I can’t seem to get the ball or the pegs to hit or interact with each other, the ball just passes through the pegs.

#2

All physics objects which you want to interact, must be in the same display group.

In addition, I’d suggest going over the Group Programming guide to fully understand how groups operate within Corona. Specifically, as quoted from the guide:

display groups are boundless and span to infinity in all directions — the physical screen edges simply frame a portion of the stage.

So, adding physics to an entire group isn’t always advisable. Perhaps adding a physics body to the ball object itself, might yield better results.

#3

@Alex@Panc,

This is not correct, so I’d like to firmly correct it. You can add physics objects to different groups and have them properly detect collisions… in fact, I can’t imagine it would be possible to program many games using physics without the ability to use groups for z-index sorting.

@lofy,

What you can’t do is add physics objects to different groups and then change the x/y position or scale of those groups independently of each other. All groups which contain physics objects that might collide should share the same x/y position and scale.

@Alex@Panc, where you  are  correct is that it’s  not  advisable to add physics to an entire group. In fact, the results would be so unpredictable, I don’t even want to suggest that any Corona user attempts it under any circumstances. To put this in context, the Corona/Box2D physics engine simulates a physical “world” and objects within it, much like the real world. Imagine if every object on earth shared one common “physics body”… pretty comical to imagine, yes?  :stuck_out_tongue:

Best regards,

Brent

#4

@Brent, thanks for the clarification. What i was trying to convey, was that, if you have an object “ball”, and it is inserted into “ballGroup”, and you have several pegs, each inside of their own display group “pegField”, and you don’t insert the “ballGroup” and the multiple “pegField” display objects into another group (fe sceneGroup), and start moving the ballGroup  as though it were a physics object, instead of the ball itself, then collisions would be unpredictable and interaction would not take place as one would expect.

I was also referring to a game that would have “camera” tracking dependent on a main “scene” group, which I (incorrectly) assume every game has, which is of course not true. I was totally offbase without that clarification. For anyone stumbling upon this in the future, below is a GIF of what camera tracking looks like, based on the generic Composer “sceneGroup”, without having all objects within that “sceneGroup” display group.

Sorry, and thanks again!

jIaq51n.gif

#5

@Alex@Panc,

No worries, I just wanted to clarify. I’ve seen that “all physics objects MUST reside in the same display group!” rumor a few times in the past, and I honestly have no clue where it originated. We never stated that in any documentation or guide or blog post as far as I know… somehow it got started in the community, long ago, and I want to make it disappear since it’s simply not true. :slight_smile:

Brent

#6

Of course!

I’m sure I’ve been perpetuating it with poorly supported statements like the above. Just telling tales around the campfire about the display group that got away… :wink:

#7

All physics objects which you want to interact, must be in the same display group.

In addition, I’d suggest going over the Group Programming guide to fully understand how groups operate within Corona. Specifically, as quoted from the guide:

display groups are boundless and span to infinity in all directions — the physical screen edges simply frame a portion of the stage.

So, adding physics to an entire group isn’t always advisable. Perhaps adding a physics body to the ball object itself, might yield better results.

#8

@Alex@Panc,

This is not correct, so I’d like to firmly correct it. You can add physics objects to different groups and have them properly detect collisions… in fact, I can’t imagine it would be possible to program many games using physics without the ability to use groups for z-index sorting.

@lofy,

What you can’t do is add physics objects to different groups and then change the x/y position or scale of those groups independently of each other. All groups which contain physics objects that might collide should share the same x/y position and scale.

@Alex@Panc, where you  are  correct is that it’s  not  advisable to add physics to an entire group. In fact, the results would be so unpredictable, I don’t even want to suggest that any Corona user attempts it under any circumstances. To put this in context, the Corona/Box2D physics engine simulates a physical “world” and objects within it, much like the real world. Imagine if every object on earth shared one common “physics body”… pretty comical to imagine, yes?  :stuck_out_tongue:

Best regards,

Brent

#9

@Brent, thanks for the clarification. What i was trying to convey, was that, if you have an object “ball”, and it is inserted into “ballGroup”, and you have several pegs, each inside of their own display group “pegField”, and you don’t insert the “ballGroup” and the multiple “pegField” display objects into another group (fe sceneGroup), and start moving the ballGroup  as though it were a physics object, instead of the ball itself, then collisions would be unpredictable and interaction would not take place as one would expect.

I was also referring to a game that would have “camera” tracking dependent on a main “scene” group, which I (incorrectly) assume every game has, which is of course not true. I was totally offbase without that clarification. For anyone stumbling upon this in the future, below is a GIF of what camera tracking looks like, based on the generic Composer “sceneGroup”, without having all objects within that “sceneGroup” display group.

Sorry, and thanks again!

jIaq51n.gif

#10

@Alex@Panc,

No worries, I just wanted to clarify. I’ve seen that “all physics objects MUST reside in the same display group!” rumor a few times in the past, and I honestly have no clue where it originated. We never stated that in any documentation or guide or blog post as far as I know… somehow it got started in the community, long ago, and I want to make it disappear since it’s simply not true. :slight_smile:

Brent

#11

Of course!

I’m sure I’ve been perpetuating it with poorly supported statements like the above. Just telling tales around the campfire about the display group that got away… :wink: