question about shapetumbler physics example

Physics
#1

So I took the shapetumbler example and trimmed it down to one circular object that’s supposed to be a pinball. I then want to use the device’s accelerometer to control the ball. I build 4 static walls to stop the ball from leaving the screen. This seems to work OK except that when the ball comes to rest in a corner it stops responding to the gravity events. (Tested on an iPad mini retina)  

local \_W = display.contentWidth local \_H = display.contentHeight local physics = require("physics") physics.setDrawMode("debug") physics.start() physics.setScale( 60 ) physics.setGravity( 0, 0 ) system.setAccelerometerInterval( 100 ) -- set accelerometer to maximum responsiveness display.setStatusBar( display.HiddenStatusBar ) function onTilt( event ) physics.setGravity( ( 9.82 \* event.xGravity ), ( -9.82 \* event.yGravity ) ) end Runtime:addEventListener( "accelerometer", onTilt ) borderBodyElement = { friction= 0.3, bounce = .5 } local borderTop = display.newRect( 0, 0, \_W,30 ) borderTop.anchorX = 0 physics.addBody( borderTop, "static", borderBodyElement ) local borderBottom = display.newRect( 0, \_H , \_W, 30) borderBottom.anchorX = 0 physics.addBody( borderBottom, "static", borderBodyElement ) local borderLeft = display.newRect( 0, 0, 30, \_H ) borderLeft.anchorY = 0 physics.addBody( borderLeft, "static", borderBodyElement ) local borderRight = display.newRect( \_W , 0, 30, \_H ) borderRight.anchorY = 0 physics.addBody( borderRight, "static", borderBodyElement ) local ball = display.newImage("super\_ball.png", 80, 160 ) physics.addBody( ball, { radius=24 } )
#2

FYI, the same thing happens with the original shapeTumbler example. If you let all the objects settle they stop responding to gravity events !!! 

Just for fun I tested this on my Nexus S phone. Same story. Submitted bug report.

#3

The objects go to sleep and a gravity event will not wake them. You need to set them not to go to sleep or wake them when you change the gravity values. I would recommend setting:

.isSleepingAllowed = false

… as the nudge approach does not work reliably. This is not a bug in Corona but a feature of Box2D.

http://docs.coronalabs.com/daily/api/type/Body/isSleepingAllowed.html

#4

Thanks. So this “feature” would affect all physics based sample code in the SDK. Would have been useful if those had been updated to document this. It’s not at all obvious to the dev.

#5

It has been commented on so many times in the forums I’ve lost count. It is documented in the Box2D documentation and easy enough to discover through trying code out.

It is a feature because allowing objects to go to sleep and be excluded from the simulation of physical effects has it’s own benefits. If you don’t want them to do that, don’t let them go to sleep. The catch 22 with that is that objects which don’t sleep consume more power on the device because of their continuous processing. A game which changes the simulated gravity based on the motion of the device is not likely to let objects go to sleep because the micro-motion of the device will keep every object awake. On the simulator it is much more likely because the simulator never moves, physically.

This link also states that collisions wake objects: http://docs.coronalabs.com/daily/guide/physics/physicsBodies/index.html#object.isawake

#6

horacebury is absolutely correct on all points.

however, I’d suggest that the sample itself contains a bug (of omission), if you wanted to submit THAT.

the sample claims to demonstrate “tilt-based gravity effects (on device only)” but is severely flawed as is.  that simple scene quickly settles, and once asleep there’s nothing to wake it.  so it would be quite difficult to demonstrate those tilt-based gravity effects as claimed.  and imo samples ought to work as claimed – that is, if it claims to do something but doesn’t, isn’t that a bug?  doesn’t the sample as is cause more questions in the forum than it answers?

(in theory you could also fix the sample by globally disabling sleep with physics.start(true), tho i’m not sure that actually works everywhere.  if you use debug/hybrid draw mode, you’ll still see them go gray when they sleep, tho this might be a simulator-only issue, i’ve not tested)

#7

imho Having extra code to force the objects to stay awake, in that particular sample, would over complicate the code being demonstrated and hide the problem of objects going to sleep in certain situations. It should be addressed somewhere, but that’s what documentation is for. The corona documentation has an option at the bottom of each page to submit comments, corrections and so on. I’ve not read the Box2D documentation too deeply, but I firmly believe that this is a well known issue in the Box2D community and docs.

#8

Don’t disagree. However, samples that come with an SDK are most often played with by those new to the SDK. Those users are less likely to have searched the forums and or 3rd party documentation. Sample code should work with the version of the SDK that it came with. I think it’s perfectly reasonable for Corona to QC the samples once there’s a new public release. Shouldn’t take long at all.

#9

The behaviour in the sample has always been the same. The sample is not there to demonstrate how to overcome any particular problem other than how to create physics object and apply gravity based of device orientation change. More than that complicates the sample. It is specifically noted in the documentation that the objects will go to sleep. A very quick search on Google returns this page which specifically states that objects will, once asleep, not respond to gravity changes:

sleeping bodies will not respond to changes in the direction of gravity

http://docs.coronalabs.com/guide/physics/physicsSetup/index.html#sleeping-bodies

https://www.google.co.uk/search?q=site%3Adocs.coronalabs.com+sleep&oq=site%3Adocs.coronalabs.com+sleep&aqs=chrome…69i57j69i58.5728j0j4&sourceid=chrome&es_sm=122&ie=UTF-8

#10

I get that, but I guess I’m coming at it from the opposite end, as I’ve used Box2D natively in C++, and am well aware of sleeping, so to me the example seems flawed - it’s not a very reliable “tumbler”, and doesn’t demonstrate well the accelerometer.  So I wouldn’t see it as over-complication if just adding enough code to fix what (imo) it MUST do to adequately demonstrate those things.

I’m admittedly a nitpicker, and expect docs and samples to be rigorous, but I really don’t personally care about the samples - maybe I’m just tired of seeing the same problem over and over in the forum.  :D

#11

FYI, the same thing happens with the original shapeTumbler example. If you let all the objects settle they stop responding to gravity events !!! 

Just for fun I tested this on my Nexus S phone. Same story. Submitted bug report.

#12

The objects go to sleep and a gravity event will not wake them. You need to set them not to go to sleep or wake them when you change the gravity values. I would recommend setting:

.isSleepingAllowed = false

… as the nudge approach does not work reliably. This is not a bug in Corona but a feature of Box2D.

http://docs.coronalabs.com/daily/api/type/Body/isSleepingAllowed.html

#13

Thanks. So this “feature” would affect all physics based sample code in the SDK. Would have been useful if those had been updated to document this. It’s not at all obvious to the dev.

#14

It has been commented on so many times in the forums I’ve lost count. It is documented in the Box2D documentation and easy enough to discover through trying code out.

It is a feature because allowing objects to go to sleep and be excluded from the simulation of physical effects has it’s own benefits. If you don’t want them to do that, don’t let them go to sleep. The catch 22 with that is that objects which don’t sleep consume more power on the device because of their continuous processing. A game which changes the simulated gravity based on the motion of the device is not likely to let objects go to sleep because the micro-motion of the device will keep every object awake. On the simulator it is much more likely because the simulator never moves, physically.

This link also states that collisions wake objects: http://docs.coronalabs.com/daily/guide/physics/physicsBodies/index.html#object.isawake

#15

horacebury is absolutely correct on all points.

however, I’d suggest that the sample itself contains a bug (of omission), if you wanted to submit THAT.

the sample claims to demonstrate “tilt-based gravity effects (on device only)” but is severely flawed as is.  that simple scene quickly settles, and once asleep there’s nothing to wake it.  so it would be quite difficult to demonstrate those tilt-based gravity effects as claimed.  and imo samples ought to work as claimed – that is, if it claims to do something but doesn’t, isn’t that a bug?  doesn’t the sample as is cause more questions in the forum than it answers?

(in theory you could also fix the sample by globally disabling sleep with physics.start(true), tho i’m not sure that actually works everywhere.  if you use debug/hybrid draw mode, you’ll still see them go gray when they sleep, tho this might be a simulator-only issue, i’ve not tested)

#16

imho Having extra code to force the objects to stay awake, in that particular sample, would over complicate the code being demonstrated and hide the problem of objects going to sleep in certain situations. It should be addressed somewhere, but that’s what documentation is for. The corona documentation has an option at the bottom of each page to submit comments, corrections and so on. I’ve not read the Box2D documentation too deeply, but I firmly believe that this is a well known issue in the Box2D community and docs.

#17

Don’t disagree. However, samples that come with an SDK are most often played with by those new to the SDK. Those users are less likely to have searched the forums and or 3rd party documentation. Sample code should work with the version of the SDK that it came with. I think it’s perfectly reasonable for Corona to QC the samples once there’s a new public release. Shouldn’t take long at all.

#18

The behaviour in the sample has always been the same. The sample is not there to demonstrate how to overcome any particular problem other than how to create physics object and apply gravity based of device orientation change. More than that complicates the sample. It is specifically noted in the documentation that the objects will go to sleep. A very quick search on Google returns this page which specifically states that objects will, once asleep, not respond to gravity changes:

sleeping bodies will not respond to changes in the direction of gravity

http://docs.coronalabs.com/guide/physics/physicsSetup/index.html#sleeping-bodies

https://www.google.co.uk/search?q=site%3Adocs.coronalabs.com+sleep&oq=site%3Adocs.coronalabs.com+sleep&aqs=chrome…69i57j69i58.5728j0j4&sourceid=chrome&es_sm=122&ie=UTF-8

#19

I get that, but I guess I’m coming at it from the opposite end, as I’ve used Box2D natively in C++, and am well aware of sleeping, so to me the example seems flawed - it’s not a very reliable “tumbler”, and doesn’t demonstrate well the accelerometer.  So I wouldn’t see it as over-complication if just adding enough code to fix what (imo) it MUST do to adequately demonstrate those things.

I’m admittedly a nitpicker, and expect docs and samples to be rigorous, but I really don’t personally care about the samples - maybe I’m just tired of seeing the same problem over and over in the forum.  :D