I’m working on an authoritative networking scenario inspired by Valve’s multiplayer networking papers, specifically the part about collecting snapshots of collider positions/rotations and rewinding them at the moment of calculating a fired shot to it’s position in time equal to Network.time - transitTime - clientViewInterpolation.
I have it working fine and dandy, but moving colliders around just based on transforms with colliders and no rigidbodies is a very expensive process, due to collision data needing to be recalculated. To that end, I changed all my “hitbox” collider objects to be kinematic rigidbodies, and am doing the rewind with MovePosition/MoveRotation… it performs much better, but it happens exactly when the RewindHitBoxes() function is called, which needs to happen in the exact frame that the shot is being simulated, right before the raycast.
It’s been working great, I just feel like I’m doing something dirty, not operating within FixedUpdate, but I can’t afford to wait for the next physics step. Is there any unforeseen consequences of what I’m doing that I might run into?
There should be no problem to move it in Update. FixedUpdate is needed for accelerated movement because acceleration can’t be linearly scaled. Moving at a constant speed is no problem in Update. Keep in mind that FixedUpdate is called right before Update. It is never called in between. Unity’s scripting runtime runs only one thread and all code is executed between visual frames. Here’s how FixedUpdate works
For a 2D objects, You should move it inside the FixedUpdate even if it’s kinematic:
From Unity - Scripting API: Rigidbody2D.MovePosition
It is important to understand that the actual position change will only occur during the next physics update therefore calling this method repeatedly without waiting for the next physics update will result in the last call being used. For this reason, it is recommended that it is called during the FixedUpdate callback.
if you use MovePosition/MoveRotation just for move rigidbody to the point where object was at frame you fire, then it’s much better (IMHO) to create a separate collider/trigger at this point at try to hit it instead of hitting rigidbody’s collider with rigidbody moving. then, if hit was succesfull, apply some actions to rigidbody
you can use single collider for these detections - just move it every time you calc a hit