box2d world step / timestep (solved)

Questions
1

Hi all,

I’m a long-time programmer, but I’m new to Codea. I’m curious about whether the full functionality of box2d is implemented in Codea. In particular, I’m wondering if there is direct access to the world.step() function, but I’ll take any useful solution to the following problem:

I’d like to be able to run a physics simulation at a speed many time faster than 60 steps/second, either rendering every N steps, or not rendering at all. I’m not interested in altering frame rate, but rather the amount of simulated time that passes per frame. If possible, I’d like to compress time at a ratio of 1/1000 or better. Extreme accuracy in the simulation is not as important as raw speed.

I appreciate any insight anyone might be able to offer.

2

@skysaw - welcome! There are many here like you who come from other programming environments, myself included.

If you’re simply wanting to speed up time, so that the physics engine will behave as though it was running many times faster than real time, the first thing I’d try is multiplying the velocities by the compression ratio, eg by 1000. I’m not a physicist, but naively, it seems it might work. AFAIK, Box2D doesn’t have any fixed time elements that remain the same regardless of velocity, so altering velocity should speed up ‘time’.

3

Thanks Ignatz, though that’s not the answer I was hoping to hear. I have a feeling that trying to simulate it that way might be very messy, if it’s workable at all. Just a guess though, so I’m willing to try, unless someone has a better idea.

If there is no access to other box2d physics functions and variables, I wonder if anyone in the know can say whether that might be in the works for a future version of Codea?

To see what I’m talking about, take a look here: http://www.iforce2d.net/b2dtut/worlds – The step() function is being called explicitly with a length of time specified for the step

4

@Skysaw codea features a function called physics.iterations which handled how many position and velocity iterations occur each frame. It does not have the step function though.

5

Thanks, @luatee. I’m aware of that, but it doesn’t really address the problem.

I thought again about @Ignatz’s suggestion, but there are too many things to consider. For example, gravity would be increased in that sort of simulation, which means consideration would also be needed for friction, motor torque, damping, restitution, etc., all of which would affect each other in ways that far exceed my grasp of the topic of physics.

I did have one idea that will help my problem somewhat. My goal was to run many different scenarios in a short span of time. But it occurred to me that instead of running them one after another, I could run them simultaneously in a world where the mechanisms I’m testing don’t collide with each other. I might be able to at least get away with doing 50-100 of them at a time, if I code concisely enough.

6

@skysaw yes I know, the step problem is something I wanted for one of my old projects to make it a bit more accurate but I don’t know if it was addressed by TLL.

7

Hey all,

This thread was from awhile back, but I thought I’d update it to say I have solved this and wanted to share my solution, since I think this is extremely useful.

I mentioned in my last post that working out the physics would be too messy (read: I was intimidated by giving it a try). Well today I decided to give it a try anyway to see what I might be able to figure out. Good news: it turns out it’s pretty easy to make simulations run at arbitrary speeds.

For my test, I set up two rectangle bodies and applied strong force and torque values to let them fly, then bounce off of walls. I tracked one corner of each rectangle by plotting its position on screen for each drawing frame, leaving a colored trace in place. Then I changed the gravity on the second box to see what I could get going – the idea being that if I could get each box to plot the same complicated path at different speeds, then the problem had been solved.

I’ve gotten a fairly close match with up to about 5x speed. At 6x and greater, the disparity starts to become more noticeable, but if you don’t need a great deal of accuracy, you may be fine going higher.

The math:
(“rate” is how fast you want the simulation to run; 1=normal speed)

Gravity: multiply by rate^2
Applied forces and torques: multiply by rate
All bodies: multiply linearDamping and angularDamping by rate

That’s all there is to it! Note that friction, density, and restitution should not be changed.

Note:
If you use very strong forces or very high damping rates, the simulation becomes less accurate.

I haven’t tested joints yet, but I’ll let you know how it goes. I’ll be looking at reactionForce, reactionTorque, maxMotorForce, maxMotorTorque, motorSpeed, and dampingRatio. I expect they all need to be multiplied by rate. Not sure what to expect yet with the frequency field of DISTANCE and WELD joints.

I’ll also look to see if calculated impact forces might have to be accounted for.

8

Looking in the Codea runtime it looks like what it does is pass in the DeltaTime (time for the frame), then the physics engine will do a 1/60 step how ever many times it needs to catch up to the deltatime (ie if framerate is currently slower that 60fps it’ll sometimes do 2 or more steps). So it’s locked to the speed of time on the ipad.

@Simeon I guess what TLL could consider is allowing you to set a physics parameter which gives a multiplier to deltatime when it’s accumulating in the PhysicsManager. That way rather than controlling step, you’d having a setting of 1.0 ie realtime, but you could change it to 5.0 being 5x realtime etc. It’d still do physics steps at 1/60s so the accuracy would be the same, it’d just slow processing. And the current iterations feature could let you drop accuracy for speed.

Of course that’s based on the old runtimes, but I presume the new exports/Codea itself are similar under the hood.