bevy_rapier
bevy_rapier copied to clipboard
Invalid behavior of `TimestepMode::Interpolated`
I have a problem with TimestepMode::Interpolated
, I analyze a code of this mode since few days and finally I think: it can not work correct with user defined systems.
Why?
Interpolated mode tries to keep selected frame rate (delta time) of physics pipeline steps like another engines tries to do this in thing which named FixedUpdate
. Bevy also have their own FixedUpdate
and it is a place where I tried to place things from my user defined systems, but this causes skipping Rapier's physics steps for my data which works by jitter.
Expected behavior
User defined systems should execute once for every Rapier's physics step. Rapier should do they work on end of every subupdate from Bevy's FixedUpdate
instead of created own implementation of that. Or executing user defined systems in their own subupdate loop. In my opinion, first option is better.
A gameloop should looks like this:
Actual behavior
User defined systems executes independently than Rapier's physics step. Code of step_simulation
system invoke whole pipeline work in itself, without any calls of user defined systems etc. And this causes changing a data between user defined systems without propagating this in physics.
A gameloop looks now:
Reproduction
Registring:
// I register this in FixedUpdate, because I want to keep selected physics delta time, like another engines do that.
app.add_systems(FixedUpdate, move_characters);
System code:
fn move_characters(mut query: Query<&mut KinematicCharacterController>) {
for (mut controller) in &mut query {
// Property of controller should always be `None`, because it was cleared after any pipeline step.
// But now it can be executed few times before next pipeline step will be executed.
controller.translation = Some(Vec3::new(0.0, 0.0, 1.0));
}
}
Environment:
- bevy v0.12.1
- bevy_rapier v0.23.0
Research steps
I tried to eliminate the same problem like @liquidev, because I work with him.
@liquidev's idea of invalid interpolation
He started from this idea, and even he make a pull request #463 which try to fix that, but this is not patching our problem and in my opinion (he do not must agree with that) his changes are wrong, but I plan to explain why in that pull request.
Idea of unstable delta time
Bevy's ECS scheduler currently have a little problem with delta time stability. This is described in https://github.com/bevyengine/bevy/issues/4669. Even @liquidev create chart of this, and how it is related with Rapier's lerp problem (dz
is variation in character's position in z
axis):
Initially I think about this like a big problem with lerp, but after consideration I think ustabilities like that should not very influence Because things which is unrelated with physics looks fine on different FPS, and generally so many published games on any engines have unstable frame time, but looks fine.
Generally from what I understanded and noticed, this relation exists, because this unstability causes an aditionals Rapier's subupdate and Bevy's FixedUpdate
subupdate, which start a whole problem which I explain in this issue.