You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be interesting to have physics running in a background task over a few frames, and using interpolation to smooth results.
We could have a physics world simulating at 30 or 20 fps ; while rendering would go at 60 fps.
TODO
Study physx does its double buffering: when is the new buffer written exactly ?
Plan
flowchart TD
A[Set to allow user to change physics data] --> COPY(Copy physics into background)
COPY --> FORK(Start bevy task)
FORK --> Loop{Elapsed time}
FORK --> SIM["Rapier physics simulation (50ms ; 20fps)"]
Loop -->|"-50ms"| BU["Bevy update (16.6ms ; 60FPS)"]
BU --> Loop
Loop -->|"+50ms"| J(join)
SIM --> J(Join bevy task)
J --> WRITE(Write physics from background task into bevy)
WRITE --> A
Loading
Implementation
Add a "background mode" to the plugin.
step_simulation() is expected to provide the end result of our simulation, It makes sense for it to be the system reading the result of the background computation.
Add a start_simulation system to dump physics state and start the simulation.
re-order the apply_*_user_changes to be before that start_simulation system. Clarify in the docs that any value modified outside of expected set will be without effect.
Difficulties
Passing data out of ECS
A naive approach is to copy the whole RapierContext ; but IslandSolver doesn´t implement Clone, and this goes quite deep ( to SolverConstraintsSet ) ; we should keep in mind simd and enhanced-determinism features compatibility.
we might not need SolverConstraintsSet (and physicsPipeline in general) so try to clone everything but that.
This should be possible but adding Clone to those traits should probably be behind a feature?
Another approach is to unsafely copy 😱
Another approach would be to mem::swap the RapierContext with an empty/incorrect one for the ECS, while the simulation is ongoing.
This could be made more sound by using an Option<RapierContext> + .take() 🤔
It would be interesting to have physics running in a background task over a few frames, and using interpolation to smooth results.
We could have a physics world simulating at 30 or 20 fps ; while rendering would go at 60 fps.
TODO
Plan
Implementation
step_simulation()
is expected to provide the end result of our simulation, It makes sense for it to be the system reading the result of the background computation.start_simulation
system to dump physics state and start the simulation.apply_*_user_changes
to be before thatstart_simulation
system. Clarify in the docs that any value modified outside of expected set will be without effect.Difficulties
Passing data out of ECS
A naive approach is to copy the whole
RapierContext
; butIslandSolver
doesn´t implement Clone, and this goes quite deep ( toSolverConstraintsSet
) ; we should keep in mind simd and enhanced-determinism features compatibility.we might not need SolverConstraintsSet (and
physicsPipeline
in general) so try to clone everything but that.This should be possible but adding Clone to those traits should probably be behind a feature?
Another approach is to unsafely copy 😱
Another approach would be to
mem::swap
the RapierContext with an empty/incorrect one for the ECS, while the simulation is ongoing.Option<RapierContext>
+.take()
🤔Attempts
background simulation: See bevy task to run physics #596
interpolation experiments: Interpolation exploration Vrixyz/bevy_rapier#28
The text was updated successfully, but these errors were encountered: