PhysicsVelocity is framerate dependent?

When my framerate is low
My bullets are slow!

I don't have any update acting on the bullets. I simply set the PhysicsVelocity and wait for collision events.
If there are fixed steps then the system should compensate for slow frames by taking more steps, no?

What is the proper solution here?

Thanks

 

As far as I know, Unity Physics currently uses fixedTime while running in "Update", not "fixedUpdate". That means that the movement per "tick" will be the same, with no way for a longer frame to result in longer distance moved per frame.

This is easy to test, just change the fixedTime in the time setting to something smaller than the basic 0.02 and watch your whole project run in slowmo regardless of your real framerate. Then change it to 0.05 and watch everything race across the screen.

There've been solutions in the forum, but most don't really work well for me, because they don't address the underlying problem of using the value of fixedTime while not running in fixedTime. It's been suggested that the reason for this is that unity is currently waiting on some other changes, and it'll probably be fixed in due time.

Just one of the hidden gotchas of a preview package, basically

 

Wait, what?

It's using FIXED timesteps, but in DYNAMIC updates?

That would explain why it's running very juddery for me, even at 160fps.

 

Thanks for the confirmation. Hope this gets fixed soon. Until then, physics is wrong unless you happen to be at 50 FPS.

 

@cort_of_unity Is that the problem of fixed update for DOTS Physics still not getting solved completely yet?

 

@Thygrrr I haven't seen any 'juddery' physics regardless of fast or slow framerate. That would seem to imply non-determinism. Could you share an example?

@meanfox I think this was the original discussion: https://forum.unity.com/threads/why-is-simulation-the-default-system-group.639058/#post-4289911

There's also lots of examples that have been shared about how to manually control your timesteps. Here's a recent one: https://forum.unity.com/threads/phy...ove-at-the-correct-speed.877375/#post-5798164

 

This issue, as well as how they plan to implement it in forthcoming releases of Entities and Physics packages are explained in this thread, so I guess it's the most relevant source at this point of time.

 

Here's an example recording. It's literally just linear velocity being set on the ship. The judder is virtual, the actual linear velocity (seen on the right) does not change, it tops out at 190 a bit after this video was taken, at full judder. The ship wobbles because the camera is interpolated framerate independently in Update ticks; if I pin the camera to the ship, the entire rest of world will judder and the ship stays fixed in screen coordinates.

This is practically the same judder, albeit a bit worse, that I get when using a non-interpolated Rigidbody in the "classic" physics system when the rest of the game runs at a high frame-rate.

https://imgur.com/a/aQhxe2q

 

I have that same problem but I'm still not tackling it since I have more urgent things to do. We wait I guess, to see what the announced release will bring us. However, I don't expect for it to solve the problem since it's obviously stated that it wont. We might need to implement rigidbody interpolation ourselves or do some other workarounds like synchronizing frame count of physics simulation with rendering frame rate.