Collisions stop working mysteriously.

[mds]

I have a fairly simple program which demonstrates what seems to be either a bug, or a puzzling oversight on my part. I have a ball with a radius of 1 (single body, circle shape), and a ground large enough to catch it (static body w/ 0 mass, rectangle shape about 40 x 4). The ball falls, and lands on the rectangle and sits there for some amount of time; in the attached version, it's about 10 seconds on my computer, but variations have gotten it down to 5 or so. The ball then stops colliding with anything, and falls off the bottom of the screen.

If I place multiple static bodies in its way, it will stop at the first one, but once it starts falling, it will fall through all of them. If I have multiple balls, they will fall through at the same time, even if they didn't collide with the ground at the same time. In my original program I'd turned sleep off because I was moving the ball via gravity, so it had a tendency to fall asleep and not wake up, so sleep was turned off in the pared down version too. If I turned sleep back on, it would fall through sooner. I have tried varying forces of gravity, and all had the same effect.

In the original program, if the ball was moving around, it would fall through sooner, but it would also take longer before it would fall through than the simple program.

I went onto IRC and at least one person there managed to replicate the problem, so it's probably not just my machine acting weird.

[osgeld]

i know little to nothing about the love physics module so im not any help, but just so you know it only bounces a time or 2 then falls on my pc which ends up being only about a second

(and ps your *.love file is packed wrong, main.lua needs to be in the root of the file)

[mds]

(and ps your *.love file is packed wrong, main.lua needs to be in the root of the file)

Ah. Thanks! I couldn't figure out why it would play the folder fine, but not the .love file. I've attached a fixed .love file.

[rude]

Were you doing some sort of scaling? I think you messed something up during draw. I modified it to draw actual vertex positions, and it works fine.

[mds]

I was scaling by a factor of 10, since I'd read in the box2d manual that it works best with sizes between 0.1 and 10, and it specifically recommended against using pixels as the unit of measurement. Is this also the case for Löve, or is it safe to use pixel measurements in the physics engine?

I think I found out what was causing the problem, though - garbage collection. I was reusing variables, and/or using local variables, and the shapes would get collected away, leaving the bodies with no way to interact with any other shapes that might be left. In your fixed up sample, you used a separate variable for the ground shape, so the ball's shape never disappeared.

Am I just going to have to keep a table with every shape in it? (Such a table would probably have its uses, but I'm surprised that lua's GC would even know how to clean up the bodies properly.)

[rude]

Is this also the case for Löve, or is it safe to use pixel measurements in the physics engine?

This is also the case for LÖVE, although we plan to include a built-in scale into World in the next version.

I'm surprised that lua's GC would even know how to clean up the bodies properly.

It doesn't, it was made by us that way, which makes it even more amazing that I missed that.

[counterfactual_jones]

I had this problem too, although my balls were not actually reaching the box, they'd stop a ways before collision. This is troubling. I'm storing everything in a seperate table, and am not doing any scaling at all.

[osuf oboys]

I had this problem too, although my balls were not actually reaching the box, they'd stop a ways before collision. This is troubling. I'm storing everything in a seperate table, and am not doing any scaling at all.

Hi, there are three issues with the demo. From most to least significant:

• you must store references to your box2d objects or the garbage collector will remove them, e.g. by adding entity.shape=... (although, since each body may have more than one shape, you may want to use a 'shapes' table instead),
• the x and y coordinates when you create rectangular shapes denotes the center of the shape. the x and y coordinates in love.graphics.rectangle is for the upper left corner,
• shapes can rotate (although not from collisions if 0 mass) and you may therefore instead want to use love.graphics.polygon(love.draw_fill, entity.shape:getPoints()) to draw.

[counterfactual_jones]

These are some serious gotchas then. I take it the GC doesn't handle the stuff passed to the body because the library is in C?

Co-ordinate changes are ew, I hope when the Camera code goes in it all gets unified.

[osuf oboys]

These are som e serious gotchas then. I take it the GC doesn't handle the stuff passed to the body because the library is in C?

Co-ordinate changes are ew, I hope when the Camera code goes in it all gets unified.

Text drawing and love.graphics.rectangle are the only calls where the x and y coordinates refers to a point other than the center of a region or mass. If you wish to center a rectangle, you may subtract half of the width and height. I guess it might make sense to keep it this way for "pixel perfection". Text drawing uses the lower left point of the first line as x and y coordinate and may come to change to the upper left corner in the next LÖVE version.