Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / SetPhysicsScale, Simulation Run Time and SetSpritePhysicsVelocity

Author
Message
DrT
15
Years of Service
User Offline
Joined: 10th May 2008
Location: 26.78 degrees North, -70.49 degrees West
Posted: 19th Aug 2011 18:54
I attempted to perform a two dimensional motion with constant acceleration test and I am running into a problem.

1) I am interested in setting a scale of 0.03, which corresponds to 1.5 m = 50 pixels. For this scale, the simulation agrees with those expected from constant acceleration equations for small run times. If the scale is increased from 0.03 to 0.1 (and higher), the agreement is better for much larger run time times. Why is scale connected to run time? Why do small scales give agreement only for small run times? My scale seems reasonable and I am simulating simple two dimensional motion with constant acceleration. Seems like this shouldn't be a problem.

2) Even more odd, is that the scale can be set to large values like 10 and still get good agreement for larger run times. 10 meters = 1 pixel seems to be not practical. What is the range of allowable scales?

3) Commands like SetPhysicsGravity require you to scale the parameters - see code below. To get SetPhysicsVelocity to agree with predictions, you have to pass the parameters with the default and new scales - see code below.

DrT
15
Years of Service
User Offline
Joined: 10th May 2008
Location: 26.78 degrees North, -70.49 degrees West
Posted: 20th Aug 2011 14:02
Regarding item 1 above... I believe I have found the answer.

After running a series of test on the code above, I have determined that there is a speed limit of 600 pixels/sec. The maximum speed for each scale is determined by vmax = 600 pixels/sec * scale in meters/sec. This means that the measured and predicted quantities will be in close agreement until such time that the maximum speed has been reached. The speed is calculated from the square root of (velocity in the x direction squared + velocity in the y direction squared).

Here is an example:
If scale# = 0.3, then vmax = 180 m/s. If you attempt to launch something out horizontally (x0 = 0, v0x = 35 m/s and a0x = 0) and allow it to fall under the influence of gravity (y0 = 0, v0y = 0 and a0y = 10), then you will find that the measured quantities and predicted quantities will be in close agreement until vy reaches 177 m/s (from the speed calculation above: 180 = sqrt(35^2 + 177^2)). This then sets the run time to 17.7 seconds (from the vy calculation in the code: 177m/s = 0m/s + 10m/s^2*17.7 s). If the run time exceeds this amount, then there will no longer be agreeement between measured and predicted quantities.
Paul Johnston
TGC Developer
21
Years of Service
User Offline
Joined: 16th Nov 2002
Location: United Kingdom
Posted: 23rd Aug 2011 16:14
It turns out Box2D does have an internal speed limit of about 125m/s. Although the way this is enforced means it can reduce an object's speed down to 10m/s for one step, which then persists into the following steps.

I've changed it to enforce the 125m/s limit without reducing the speed below this, it may make it into the next update (for the windows interpreter). There was also a bug in the SetPhysicsScale command that would maintain the scale at 0.2 no matter what value was given to it.
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 28th Aug 2011 06:15
I have integrated the fix into the next build which should be in the next seven days if all testing goes well.

I drink tea, and in my spare time I write software.

Login to post a reply

Server time is: 2024-04-19 06:02:58
Your offset time is: 2024-04-19 06:02:58