Question Physics rate and framerate

[fishcakes]

Ive been using VAM for a while now and one thing I don't really understand is speed VAM plays animations in relation to the physics rate and the monitors refresh rate. Looking at games as an example, it doesn't matter if the game is running at 30hz, 60hz, 144hz or whatever. The speed of movement on screen is the same. It may be more stuttery/smoother depending on the refresh rate, but the gameplay is always at the same pace.

With VAM, changing the physics rate changes the speed of animations. But also changing the refresh rate also changes animation speed. If I set up a VAM scene to use the desktop vsync, and have my display set to 60hz and physics rate to 60hz - but then change my display to 30hz, all animations run at half speed. Why is this the case? It makes it really difficult to predict what other users will get when looking at my scenes. How do I know what refresh rate/physics rate the user is using? If I set up a scene with the above values to look just right - and then somebody with a 144hz display loads my scene, everything will be too fast.

In a nutshell, why doesn't VAM work as games do? Where the animation speeds are consistent regardless of monitor refresh rates?

 

[geo_gan]

I notice this too in VR for years. Scenes play like in slow motion so I have to go into main settings and change Physics rate from Auto to 45Hz or even change the Physics Update Cap from 1 to 2. Then suddenly the animation plays twice as fast (normal speed). Strange and annoying. Thought it might be my old slow processor not being able to keep up with physics but it still happens right now using Ryzen 9 5950X so....

 

[Acid Bubbles]

@fishcakes I know in Timeline there was an issue that I'm in the process of testing exactly for that. I was using Time.fixedDeltaTime in FixedUpdate, which works... if you have a high enough framerate so the FixedUpdate doesn't extend the configured fixedDeltaTime, which is a fixed value. I'm thinking the same error may have happened in VaM itself. For now I'll at least try to prove that theory :|

 

[WrongTamago]

It's not strictly true that games always run at the same rate. Modern games try hard to account for all kinds of frame rates, but some do various tricks like locking the FPS below what the graphics card can put out. For instance, Skyrim (which admittedly, is nearly a decade old now) has a physics system that is very dependent on frame rate. For a long time, everyone advised locking your rate to 60 fps to fix problems with stuff exploding everywhere. Only in the past few years has it been discovered that you can adjust some INI timing parameters to get higher frames to work properly.

It really depends on the physics engine. VaM uses an older version of Unity, which had its own implementation of PhysX. That implementation doesn't support GPU acceleration, unfortunately. Apparently, the timing is based on frames. I don't have experience with it, so I don't know if the timings can be adjusted at all, but I'm going to take a guess that they've tried.

So their hands are pretty much tied until they go to a newer version of Unity, which is the plan for VaM 2.x.

Edit: Or if Acid Bubbles fixes it by working his magic.

 

[Acid Bubbles]

You're probably at least partially right @WrongTamago (pun not intended). But I do think there might be some places where physics are calculated using a fixed time delta rather than the actual time delta. This has probably some very subtle side effects though, for example if you allow fixed updates to run for any time delta, you can easily get things flying through models, whereas using fixed delta will give stable results with good framerates, and avoid explosions with lower framerates. In the case of Timeline, it was an implementation error but I might discover all sorts of new problems by using the actual delta time. We'll see. In any case, I cannot fix physics, only Timeline :|

 

[fishcakes]

I appreciate your input chaps. Its helped me understand whats going on a bit more clearly.

 

[geo_gan]

Also I don't know if this is directly related, but I suspect it is - VR headsets such as Oculus use a thing called Asynchronous Spacewarp which means if the headset cannot do 80/90FPS right now, then it immediately drops the framerate down to 45FPS and creates fake interpolated frames after that instead.

I think it was supposed to still give the impression of 80/90FPS to the game & user. But I'm not sure it works right at all. You will see your headset framerate stuck at 45FPS if you use the Performance HUD on Oculus Debug Tool, but if you turn off Asynchronous Spacewarp using this, you might see the framerate jump up to way higher framerate (like 60 to 75 FPS).

I don't know, I think this spacewarp is a stupid system - unless you are right now over 80/90 (80 for Rift S) then it drops right back to 45FPS - EVEN IF THE GPU IS CAPABLE OF DOING 46 TO (79 or 89) FPS RIGHT NOW! And of course what happens in VAM with animations/playback/physics is there is a big jump and difference in speed of playback as it does this jump to / from this 45 point.

Point is I think we would be better off with Asynchronous Spacewarp turned OFF for VAM altogether.

 

[Acid Bubbles]

@geo_gan it's not that simple (nothing every is). What ASW does is give you 90 fps while only asking the game to render 45. So in theory you get smoother framerates (hugely important in VR) for lower processing. This also allows for more physics updates per frame, since the pressure is lowered on the render pass. But it also means that you get some artefacts since the in-between frames are "guessed", and like you said if calculations are done using a lower fps it can have side effects on physics and stuff like that. But in general, it's a very good thing. There was a discussion somewhere about it though, because VaM is CPU bound and that most of VaM's performance issues are related to fixed update (physics), there was an argument against using ASW but I'm not sure if it still holds with innovations in those technologies since then. So, debatable and full of compromises, but certainly not stupid.