My Sadrith Mora inpsection

[Atahualpa]

Hm, changing my character's speed didn't do much -- except an increase to max. 15 when setting it to 10000. Within a normal range of speed values, I don't see any issues.

Another test with different grid sizes and viewing distances:
[Viewing Distance / Exterior Cell Load Distance / Exterior Grid Size]

7168 / 1 / 3

23552 / 3 / 7

39936 / 5 / 11

56320 / 7 / 15

It seems to increase with lower FPS.

[aesylwinn]

OpenMW uses interpolated physics with fixed time steps. This makes physics deterministic (more predictable behavior) and minimizes errors dealing with floating point precision (imagine really small time steps). When you are at or below the fixed time step, nothing bad happens. When you exceed the time step, OpenMW attempts to make up for lost time by running multiple simulation steps up to a defined limit. The alternative would be to skip the lost time. This is why "It seems to increase with lower FPS."

Perhaps the physics simulation should put a lower cap on how many simulation steps it can take in a given frame.

Just a note, collision detection between complex shapes is always going to be expensive. The only way to deal with it is to simplify the collision shape. That can be done with mods or by the engine at runtime.

[Atahualpa]

Thanks for the clarification, aesylwinn.

A quick search returned three related issues at our bug tracker:

https://bugs.openmw.org/issues/3237

In OpenMW 0.39 a change was made to run movement physics at a fixed framerate. This change was made so that movement would behave more deterministic. The downside to this is that the framerate will "spiral to death" if your hardware can't keep up with the requested physics framerate of 60hz (i.e. when simulating the movement for a timestep of 1/60 second takes longer than 1/60 of a second).

The question is, why are your physics frames taking so long that the framerate starts spiraling? For me, a physics frame in Balmora takes around 1 millisecond, whereas the allowed maximum for 60hz updates would be 16ms. Maybe you have a mod installed that is, for some reason, having an extreme effect on physics frametime?

https://bugs.openmw.org/issues/3265

https://bugs.openmw.org/issues/3355

Somewhat related to #3237. I know that the high physics frame times when walking into certain corners / vases etc. happen when the movement controller fails to find a valid path forward and thus bumps against its maximum iterations (currently set to 8 iterations, i.e. 16 convex casts). It might be a good idea to abort the stepping loop when a) we haven't moved at all in the last 2 iterations and/or b) we've reflected back to the previous velocity (i.e. an infinite loop would ensue).

(Just quoting scrawl -- always a good idea. )

[AnyOldName3]

As a temporary solution for lower-end hardware, we could make the physics tick configurable. If someone's already capped the game at 30 FPS then there's little benefit running the physics simulation at twice that rate (as long as the simulation is good enough for this not to introduce a lot of error). As well as this, users with a high refresh rate monitor and a high-end rig may want to have the physics run at a rate that isn't going to have them viewing each tick's state twice.

[aesylwinn]

I agree that it would be fine run the physics simulation at a lower update frequency (you won't see the same tick twice because of interpolation). However, we should try to keep everyone running at the same tick rate since that helps with determinism, which in turn makes debugging physics problems much easier.

[SquireNed]

Also, does the tick rate really make a huge difference? The amount of screwing-up that's going on is so immense that it'll still cause incredible issues at a reduced rate, and I'd imagine that you're not going to get a 50% decrease in compute time: you'll make the physics run a little quicker on the processing side, but the same number of things still need to happen and be equated (I'm going to go with my gut and say that you'd see something like a 45% increase, which is still okay, but not going to make a difference when you have massive collision detection lag going on).

[Pherim]

Just a note, collision detection between complex shapes is always going to be expensive. The only way to deal with it is to simplify the collision shape. That can be done with mods or by the engine at runtime.

Certainly, but most vanilla Morrowind meshes are less complex than the collision meshes in today's games, I'd imagine, and as I already pointed out, the same scenario has no noticeable performance impact in the original engine. Especially with the improved urns from MGSO. I haven't tested this with newer engine versions, yet (I believe it was something around 0.36), but when I did, it became unplayable when my character walked against the urns. If OpenMW is going to be a real alternative to the original engine, it should be able to handle things like collision at least as good. After all, one of its goals is to perform better with a highly modded installation, so it should also be able to work with somewhat more complex collision meshes.

edit: Alright, now I tested Sadrith Mora myself with 0.39, and I have to report that I am unable to reproduce the OP's problems, at least with the slave cages. However, the bellows near the forge for some reason has no collision mesh and thus is used for collision as it is, and it is, in Morrowind terms, a quite complex mesh. And when I run against that with my character, physics goes up and FPS down, in much the same way the OP reported.

[SquireNed]

One thing I think would be interesting is to get some hardware specs from everyone who's been having physics issues, and see if there's a problem with certain hardware and not happily loving the physics engine (OpenMW's is CPU-based, right? That should be pretty equally performing across manufacturers and devices).

[DestinedToDie]

My specs.

[Pherim]

I have an AMD FX-6300 (OC to 4Ghz), an overclocked AMD Radeon 7850 with 2GB VRAM and 8GB Ram.