Animation slower than.....pretty much everything else

case762

New member
Messages
15
Reactions
2
Points
3
The animation is running slower than the audio and background music. It's gotten worse over time and is now quite slow including panning and zooming. It seems audio and background is working fine. But the actual animation is running super slow and not keeping up.
 
The FPS you get depend on your hardware, scene contents, your settings, etc.
Thanks. It was working fine for the last year or so and all of a sudden started doing this. I don't recall doing anything to change it. Where can I look to check the settings?
 
Do you mean User preferences?

By settings I mean the above plus tons of other things per atom, person soft-body physics, clothes, hair, and lots more. This is a sandbox with many places to configure and change things.
 
Increase your physics CAP setting to max. If that is not enough, or your FPS get's too low, you need to reduce physics rate.

Rule of thumb:
FPS multiplied by PhysicsCAP should be bigger than your PhysicsRate
 
How many var.s are in your addonpackages folder? if you've not been keeping it organised it's probably slowing vam down.
 
How many var.s are in your addonpackages folder? if you've not been keeping it organised it's probably slowing vam down.
There are quite a few. How do you recommend keeping it organized? Can you just delete old ones you don't use? I'm not real smart with all this stuff so any advice is lamens terms is greatly appreciated.
 
There are quite a few. How do you recommend keeping it organized? Can you just delete old ones you don't use? I'm not real smart with all this stuff so any advice is lamens terms is greatly appreciated.
It's a bit tedious. The problem is that some/many packages are used as dependendies for other packages. I would recommend to deactivate packages first via the PackageManager window, not actually deleting them just yet. Then you see other packages highlighted in red that have missing dependendies. Then you can decide whether you delete both or renable the dependency package. Note that you don't see local content that depends on a package this way. E.g. a local appearance preset you made will break if the clothing/hair/morphs/skin/etc. are missing, that's obvious I guess?

Focus to get rid of packages containing morphs, because these cost performance even just the package being active, even if the morphs are not used in the current scene. Other stuff just eats disk space, which is usually not that much of a problem.
 
WHAT is the physics cap?
Increase your physics CAP setting to max. If that is not enough, or your FPS get's too low, you need to reduce physics rate.

Rule of thumb:
FPS multiplied by PhysicsCAP should be bigger than your PhysicsRate
WHAT is the Physics cap? if FPS didn't matter to me, which one will produce the most accurate results?

1,2,3 i don't understand it.
i wish things were documented better, i have no problems reading stuff on my own.
 
WHAT is the Physics cap?
Ok, I will try to keep it short. VaM uses Unity engine, which like most engines uses a separation of physics updates from anything else. The main update, running Logic/Graphics, simply tries to run as fast as possible, it's measured in frames (or images) per second...also known as FPS. However, physics run seperately at particular rate measured in Hertz (Hz). That's because for physics you want a stable rate that is not affected by sudden drops in performance or similar, as that would cause issues. This Hz number is the "Physics Rate" setting.

Now how this works in Unity on the technical side is that the physics update is done at a particular point during the main update loop. We basically decide whether we did enough physics updates to keep up with our desired physics rate since the last frame. Let's say our game runs at 90fps and we want to run physics with 60Hz. In 2/3 frames we would need to do one single physics update and in every third frame we don't need to do anything for physics. However, if our frame rate drops to 18fps, we would need to do much more physics updates per frame, which might slow down the fps even more. Now at 18fps we would need to do sometimes 4 updates and sometimes 3 updates to keep up with 60Hz for our physics.

That's where "Physics Cap" comes into play. It's the limit of how many physics updates we are allowed to catch up on per frame. For VaM the maximum setting is 3, so in those frames where we need 4 updates, one would be skipped! Skipping physics updates causes physics to run slower, which means trouble. For example your animation might run out of sync with audio, since that is using real time and doesn't wait.


if FPS didn't matter to me, which one will produce the most accurate results?
Always set Physics Cap to the maximum, which is 3 at the moment. Make sure the frame rate you achieve with that is still a bit higher than Physics Rate divided by 3. So you may need to reduce your Physics Rate, I usually run at 60Hz. Your physics might still run out of sync slightly, for example if you have momentary frame drops during scene load, but a well build scene should be able to handle that. (e.g. have your animation trigger short audio clips instead having a single long audio that is supposed to stay in sync with animation)

i wish things were documented better, i have no problems reading stuff on my own.
A setting like this should not even be exposed to the user. It should be set automatically. But VaM is an indie game, you have to take shortcuts...
 
Ok, I will try to keep it short. VaM uses Unity engine, which like most engines uses a separation of physics updates from anything else. The main update, running Logic/Graphics, simply tries to run as fast as possible, it's measured in frames (or images) per second...also known as FPS. However, physics run seperately at particular rate measured in Hertz (Hz). That's because for physics you want a stable rate that is not affected by sudden drops in performance or similar, as that would cause issues. This Hz number is the "Physics Rate" setting.

Now how this works in Unity on the technical side is that the physics update is done at a particular point during the main update loop. We basically decide whether we did enough physics updates to keep up with our desired physics rate since the last frame. Let's say our game runs at 90fps and we want to run physics with 60Hz. In 2/3 frames we would need to do one single physics update and in every third frame we don't need to do anything for physics. However, if our frame rate drops to 18fps, we would need to do much more physics updates per frame, which might slow down the fps even more. Now at 18fps we would need to do sometimes 4 updates and sometimes 3 updates to keep up with 60Hz for our physics.

That's where "Physics Cap" comes into play. It's the limit of how many physics updates we are allowed to catch up on per frame. For VaM the maximum setting is 3, so in those frames where we need 4 updates, one would be skipped! Skipping physics updates causes physics to run slower, which means trouble. For example your animation might run out of sync with audio, since that is using real time and doesn't wait.



Always set Physics Cap to the maximum, which is 3 at the moment. Make sure the frame rate you achieve with that is still a bit higher than Physics Rate divided by 3. So you may need to reduce your Physics Rate, I usually run at 60Hz. Your physics might still run out of sync slightly, for example if you have momentary frame drops during scene load, but a well build scene should be able to handle that. (e.g. have your animation trigger short audio clips instead having a single long audio that is supposed to stay in sync with animation)


A setting like this should not even be exposed to the user. It should be set automatically. But VaM is an indie game, you have to take shortcuts...
Thank you for the detailed write-up!
3 other questions that are hopefully simple:
A. Is it possible to increase the physics cap to 20 like you do in the benchmark?
B. If i am using a capture plug-in running @game time instead of real time(eosin), and have a very complicated scene with multiple looks and lots of complicated SIM clothing and i don't want clipping. Would it be better to run a low physics update rate or a higher one? 45Hz vs 288Hz?
C. Does the real-time reflection probe make a big impact visually? Seems to make a decent difference in frame rate
 
A. Is it possible to increase the physics cap to 20 like you do in the benchmark?
VaM's UI does only allow it to be set to 3. However, via code it can be set to any value. Just make yourself a little plugin, its like 3 lines of code?


Would it be better to run a low physics update rate or a higher one? 45Hz vs 288Hz?
Sure, 288Hz is better, if you can set PhysicsCAP high enough. But it probably won't prevent clipping geometry.

C. Does the real-time reflection probe make a big impact visually?
I wasn't aware it was actually doing anything now. If anything, it should only affect global illumination and reflections on CUA objects. Likely you can just bake the reflection probe instead (use SkyMagic)
 
Back
Top Bottom