Frame-independent movement, I'm stuck
category: general [glöplog]
Quote:
That's why I proposed introducing a flag that turns off the interpolation on "hard cuts" such as bounces. In the above example, the physics code could set the flag when the ball hits the ground and omit the ball's first-tick collision response. Of course this would "delay" the ball's movement by the fraction of a tick but it would at least look like a proper bounce.
I won't dig out my non-existent photoshop skills now, but imagine the 5th and 10th point of the red line firmly tucked to the ground.
Wouldn't be possible to roughly predict what objects/faces (i am not really suggesting polygon checking here) an object with |v| > 0 may collide with. And if you find your object on a different side from the predicted "may collide with"-object then you rewind the physics engine and sample with higher precision. Obviously if this is possible it is also possible to use the data from "roughly where we will collide"-routine to be able to set object dependent time resolution in the physics engine.
So, i guess my question really is if you in more serious physics implementations use adaptive/dynamic time resolution and if you do have you been able to decouple objects more than in safe-distances (say rooms) to a level where you can actually run sub-simulations in higher precision than the ordinary "world".
I believe the consensus is that adaptive timesteps (especially if the purpose is to subdivide iterations to get ultra-accurate collision response) is way overkill for games.
Maybe a nice read for Saga:
Chris Heckers' page has some info about collision. He assumes the objects colliding are still penetrating each other in the current time step, which makes things simple (just subdivide and check for collision), but mustn't be the case if the simulation is running too slow. Then you get objects tunneling through each other.
Chris Heckers' page has some info about collision. He assumes the objects colliding are still penetrating each other in the current time step, which makes things simple (just subdivide and check for collision), but mustn't be the case if the simulation is running too slow. Then you get objects tunneling through each other.
Saga Musix: If your problem is related to collision detection with the ground/platforms (but you didn't say that in your first posting), then my advice is:
Don't simply add several pixels to the player position, but use a for loop and check inside the loop whether the player is already hitting the ground. Break the loop if he does.
Don't simply add several pixels to the player position, but use a for loop and check inside the loop whether the player is already hitting the ground. Break the loop if he does.
Adok: You don't know how my sourcecode is actually checking colission, so don't give advice that actually does not work. And I'm not working with pixels, btw.
Someone compile an Adok-on-code'n'math log already!
stefan, care to take the honors? :)
Adok, that was seriously the WORST advice on collision detection that I've ever had the misfortune to read. Go away and come back as soon as you've got a basic grasp on maths and numerics, ok?
Of course it would be more efficient to simply check if a collision has happened with a comparison operator and if it has, move the character back to the last position before collision (which can be easily computed).
*giggles*