Replies: 1 comment 1 reply
-
Determinism in bevy_xpbd requires us to use certain features for our dependencies; Excluding these dependencies, bevy_xpbd should actually be just as deterministic with But yeah, to have proper determinism for any entities we need to have the Parry and Glam features enabled, and this means that they are enabled everywhere. If we ignore this, we could probably treat entities set as deterministic/indeterministic differently, but I would suspect the difference to be almost negligible in practise, and it wouldn't currently be useful because we don't handle determinism any differently. |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to implement determinism for only some physics objects, by that I mean have some physics objects which uniquely are deterministic so that those can be used for multi-platform games and enable easier netcode (by allowing for rollback) while having most other physics objects by non-deterministic. The deterministic objects would have to only be allowed to impart force to non-deterministic objects and not receive any force (otherwise they wouldn't be deterministic). This way a few gameplay relevant objects could retain determinism while allowing for other aesthetic objects to respond appropriately to these deterministic objects without substantial inefficiencies in speed for those aesthetic objects. I think this method of operating would fit an ECS style of development better then the Rapier either being deterministic or non-deterministic. Is this a practical direction or am I fundamentally misunderstanding determinism? Separately would this even be as efficient as global determinism?
Beta Was this translation helpful? Give feedback.
All reactions