Physics Limiter Sometimes Not Working? (v0.44)

[discordianisms]

In order to increase FPS I set the environmental variable OPENMW_PHYSICS_FPS to 29 as suggested. This appears to have at least been acknowledged in the openmw cmd: Warning: physics framerate was overridden (a new value is 29).

It seems to take a little while for the cap to kick in, however, if it ever does. Currently, just standing around, my framerate is 1-2 whereas the Physics is ~ 250.

What's particularly odd is in the past, with the same version, I would sometimes get >100 FPS, so I capped the framerate at 60. I'm not sure why it's fluctuating so drastically, although the ridiculously high FPS is rare but it does happen which means its probably not an issue with the sparingly used 2k texture packs or my hardware.

Ideas on how to solve this would be nice, but I think this generally would be good info for the devs to have (if they dont already have it ).

System info in signature :3

[AnyOldName3]

The physics FPS setting controls the number of physics simulation steps OpenMW simulates per second. If it's set to 60, OpenMW simulates 16.66... ms of physics at once, for example. That doesn't mean that the simulation of that much physics has to take that much time to do - if nothing's going on, it'll take very little time at all, but if a lot is happening, it'll take much longer. If the physics ends up too far behind real-time, we have to simulate multiple steps at once, and that makes it take even longer, creating a positive feedback loop where the physics takes longer and longer each frame.

I think you've misunderstood what the setting does and expected it to limit the amount of time OpenMW spends on physics, but that's not really what it does. Decreasing it can give a performance improvement (as there're fewer steps which need simulating) but it can only help up to a limit (as the longer each step covers, the more stuff needs simulating).

The variation in performance is probably because there are some places where there are very few collision objects near NPCs and other areas where there are loads of complex collision objects near loads of NPCs, which, for obvious reasons, makes things take longer.

[discordianisms]

Physics is set to <29
General framerate is set to <60

But I see what you mean. I guess I'll have to just deal with it until the navmesh update bug is fixed?

[psi29a]

But I see what you mean. I guess I'll have to just deal with it until the navmesh update bug is fixed?

What bug do you mean? Do you have a link to the issues you are referring to? If there is no issue being tracked, we can't act on it.

[wareya]

I think that physics currently doesn't fall back to delta time if it can't run fast enough, but tries to catch up anyways, so you have times where it slows rendering to a crawl. I'm not sure, though. Either way if there's a positive feedback loop then something is implemented wrong.

[discordianisms]

But I see what you mean. I guess I'll have to just deal with it until the navmesh update bug is fixed?

What bug do you mean? Do you have a link to the issues you are referring to? If there is no issue being tracked, we can't act on it.

I believe it's this one: https://gitlab.com/OpenMW/openmw/issues/4785
maybe this too: https://gitlab.com/OpenMW/openmw/issues/4777

But both of which are intended to be fixed for 0.46 if I'm reading this correctly?

(Its also possible its just an occasional blip. Today running OpenMW 0.44 I'm at maximum framerate, and those issues seem like they might be from a later version due to the "regression" tag. I'm honestly just trying to figure out the cause, which has probably already been solved so honestly this thread is probably a nonissue. Sorry for wasting your time.)

[psi29a]

I think one issue can already be closed...

can you re-validate with a nightly build (based on master)?

Don't forget, navmesh was introduced in master (0.46), not 0.44...