Inaccuracy of the physics engine?

@dave1707: ahh nice!

@Luatee I suspect whats been happening is that nilling objects and restarting your game will not destroy physics bodies immediately, you need to do myBody:destroy() before you nil your physics bodies otherwise you could create a new body in the same position before the garbage collection takes effect and the ‘ghost’ bodies might interact with objects in the new game causing different starting conditions resulting in what appears to be non-deterministic behavior.

Well I was destroy all the line bodies but not the bike body which I dont know if that would have an effect on it but I’ve set that to be destroyed each time the simulation ends aswell and I’ll get back to you in a bit with the outcome.

@John Ive tested that and Im still ending up with different results still, Im not sure what to do now though

I don’t know how you’ve done the programming @Luatee, here’s how I did it and I get the same results every time I reset the ball. But there are two catchs one is that though the angle rotated, ball.x, ball.y are the Same the time taken is accurate to the first decimal place in seconds. Since I’ve calculated time taken using DeltaTime I think that’s pretty accurate. Second i didnt move the screen so at most you could draw five to six lines if too many lines is making a problem then this code maybe won’t solve it. Here’s the code if you want to have a look. https://gist.github.com/Saurabh96jun/5655889

No I’m not sure that will help as the only way I get these errors are with a full length track

While making the track how do you keep the cycles position always in the middle of the screen. Cause if the cycle is a physics body and has a velocity then shouldn’t it at some point move out of the screen. Maybe the way you keep in cycle in the middle might be making the difference. I am not sure about it though just a guess.

Nah its not that, you can do it by translating the screen to the balls position and adding Width/2 and Height/2 that should follow the ball

I have narrowed it down to this - http://youtu.be/mW1m7Nhj0G4
The bike takes two separate paths and it changes between them each time the bike is added and the simulation run

That’s what I was finding in the physics simulation I did. There were 2 paths that the ball took. But after I changed the program to destroy and recreate all the physics objects each warm restart, it took only one path. I’m thinking that if I would have let it run for longer times, the single path would have started to deviate again after several more collisions. It’s called Chaos theory. Unless everything is calculated to infinity, things are going to change. Maybe even at infinity too.

Well according to john it doesn’t include random occurrences or chaos theory as you say, it should only follow one path

Codeas’ math has only 6-7 digits of precision which sucks when it comes to physics objects or anything else that does continuous calculations. Rounding errors start to occur fast and keep growing. If you do simple calculations on one object, you probably will come out with the same results. But the more objects you add, the more the calculations will differ. The tracks are made up of multiple physics edges, so the bicycle would have to hit every one exactly the same each time. I doubt that will happen with the limited math precision. And that’s what Chaos theory is, the accumulation of small errors that add up to cause a difference from one run to another.

I quite like the iOS game Bubble Ball which is a free physics game. But I have noticed that adding an irrelevant object to the scene can make the physics of the ball change ever so slightly.

@inoddy: You are correct, even the presence of an additional body can alter the outcome, because of certain details of how Box2D is implemented.

But again: Box2D’s behavior is deterministic. If the input is the same, it doesn’t matter how long you let the simulation run, it will always be identical (after all, reproducibility is necessary in software. Nobody would use a physics engine that couldn’t be debugged!)

But @toadkick surely if I have a ball running down a ramp on the right side of the screen and add a box to the left side and the box never touches the ball then the ball should always follow the exact same path? Unless the box has a gravity field.

Why is it then that if I play the game line rider online the result is always the same even if I make I long track and even have some extreme cases where the cart just lands on the line? Do they use more accurate physics engines or is there some method to do so??

@inoddy: It might be ever so slightly different. You would only notice the tiny difference if you did one run without the irrelevant box, and then another run with it. There are a few reasons for this, but largely it has to do with the fact that adding that extra body changes the internal state of Box2D (for example, the bodies might be processed in a different order, depending on the order that you add the bodies to the world).

@Saurabh: I believe line rider uses a custom physics engine, tailored specifically to the game. Line rider’s engine is not a full-featured engine, and is quite a bit simpler than Box2D.

Line riders engine seems to be doing better than our favoured box2d atm, I’m just stuck I doubt this games gonna move anywhere

.@Luatee I’ve been playing around with my program that was giving me 2 different paths for the bouncing balls when I would do soft restarts. I added physics.iterations(1,1) in setup() and that gave me 1 path with the soft restarts. Not sure if that will make a difference for you or not.

@dave1707 I didn’t understand why you set the iteration to 1,1. I read the inbuilt help and saw that higher the number more stable the physics is and the default is 10,8 then shouldn’t you actually set it higher than 10,8?@Inoddy even if the mass of the body affects the motion of the ball. In this case the edges don’t have mass and also the results are different for the same case I.e. without making any changes