Movement solver changes/fixes

[wareya]

This fixes several major problems with the current movement solver, which make it a lot harder to get stuck and much less common that you can't jump in certain locations unless you stand still.

No changelog additions yet and not ready to merge. Some of these changes can cause performance problems and bring some other bugs to attention (like capsules breaking some vanilla level design), so it shouldn't get merged until enough people look at it.

If you look at this, though, please test it, too, and compare its behavior ingame directly to current master. The problems it fixes are monumental.

This is certainly still not a perfect movement solver, but it's a lot better than what OpenMW has right now.

Problems fixed:

• Not mapping against what's hit unless the stair code successfully runs
• Lack of safety margin making it unsafe to do the above
• Problem with how "don't skid up steep slopes" worked, preventing jumping while running into walls
• Some bad interactions between jumping and stairstepping
• Getting stuck in simple acute crevices, including some hanging sloped walls and things like the double stairs in the ald'ruhn mage's guild (complex acute crevices still get stuck)
• The stair code freaking out in obscure cases involving steep slopes

Test cases:

• The bottom of the stair meshes in interior vivec areas (test these with cylinders and rounded cylinders too, see actor.cpp)
• The beds in the ald'ruhn mage's guild (their sides are steep slopes)
• The bedside tables in the ald'ruhn mage's guild (their sides are VERY steep slopes)
• The hanging sloped walls in the ald'ruhn mage's guild
• The big plant pot thing near the entrance of the ald'ruhn mage's guild
• Most walls anywhere
• The double stairs in the ald'ruhn mage's guild (falling between the railings, not between them where you could always fit and get stuck) (note: in vanilla you can just walk between them for some reason)
• Some of the pillars in the ald'ruhn mage's guild walls, where they intersect with the wall at an obtuse angle (as far as player collision is concerned)
• A place in the ald'ruhn mage's guild (near a merchant) where two tall pots meet eachother at an obtuse angle (as far as player collision is concerned) (try jumping)

Things that might need adjustment:

• There's a hack that makes slopes act like walls in some cases, to keep the character from stuttering and unable to jump when like walking into the sides of beds and tables in ald'ruhn, or some rocks in the wilderness. It doesn't help in some cases.

Related forum thread (linked for bookkeeping purposes): https://forum.openmw.org/viewtopic.php?f=6&t=5200

[psi29a]

For those wanting to test along with you, can you provide save games to the places that should be tested?

[wareya]

Figured it would be easy to coc into those areas, but here.

saves.zip

[wareya]

Is there anything that can be done about the random appveyor build failures?

[psi29a]

Yeah, remove msvc2015 since it only happens with that and save us 25m build wait in the process.

@zinnschlag @AnyOldName3 @ananace you ok with that?

[ananace]

I'd personally prefer not dropping MSVC2015, keeping support for the two latest versions is a good policy to have. But since it seems to be an AppVeyor logger issue - and therefore 100% out of our control - I'm not sure what we could do to avoid it.

[psi29a]

Can we set it to allow-failure (similar to how we do it for clang on linux)?

[AnyOldName3]

Has the bug been reported to AppVeyor?

[wareya]

Oops, I can't leave the ground while levitating. Guess I broke one of the flying checks.

[wareya]

Fixed.

[wareya]

About this hack:

There's a hack that ensures the stairs code works correctly when the player is jumping and moving upwards, but maybe the stairs code shouldn't work in this case at all.

Vanilla does something similar, so this should stay in. My worry was that it might not, since some games don't.

[wareya]

Alright, I can't see any more major changes needed based on my own testing. Anyone want to try to break it ingame before I change the "request for comments" to "ready for review"?

[GIuka]

What is the benefit to snapping to surfaces when the player is moving upwards? An issue this creates is that the player can jump against a rope fence with ~300 acrobatics and then immediately snap onto it, losing all momentum. Sorry if this has an obvious answer.

Players with high acrobatics can also jump beneath awnings and other overhead geometry and will maintain all upward momentum. This can cause all sorts of weirdness. I know this has been an issue in master for years so this might not be entirely relevant to your PR but it might be worth looking into while you're working in this area.

[wareya]

The reason is that vanilla Morrowind does the same thing. That said, removing it is only a few lines of changes.

EDIT: This is also true of jumping into ceilings etc. from below and maintaining your vertical momentum. In morrowind's movement mechanics, air inertia is a fixed value, and doesn't change when you bounce into/slide across obstacles.

[GIuka]

I guess I just spent so much time away from the original that I forgot how it controlled. I can see value in recreating the original physics. Your way is probably for the best since people might be expecting that behavior to carry over to OpenMW and personal preferences could be better met following the great dehardcoding.

[wareya]

These parts of the engine are going to be the hardest to dehardcode, so they should be as readable as possible.

[wareya]

I haven't seen any activity on Stormy's collision system branch for a little over two months. Should I do anything?

[StomyPX]

I didn't see this, or else I would've said not to wait for me. So I'll say that now: "Don't wait for me, I at least won't be ready for 0.46, and on the off chance that I finish and it is no better than before, you would have been waiting for nothing" so yeah go ahead and I'll just adapt the new system to meet this behavior as I write it

[wareya]

Okay, so that means driving #2049 through so we can switch to AABBs for speed, or accepting the performance penalty of using the new movement solver with capsules temporarily.

[wareya]

Guys, someone's gotta make an executive decision on whether or not this is going to be held back by changing the physics system (either double-precision bullet or stomy's custom system). If it's going to be held back then I'm going to make a simpler version to get some of the fixes in sooner, so please make a decision.

[Capostrophic]

I guess it's going to be held back by a while.

[wareya]

Okay, one more vague summary of changes here so far in case I flake out and don't make a miniature version for a while:

1. actually mapping against things the collider comes into contact with instead of just doing the inertia rejection part
2. fix the lack of a safety margin, making it unsafe to do the above (this might be where a small part of the performance loss comes from because it involves an additional trace pointing away from the contact surface)
3. fix the "don't skid up steep slopes" logic so that you can jump while "+forward"ing into walls
4. fix some differences between OpenMW and Morrowind stairstepping logic (i.e. when jumping onto a ledge, either inertia is mapped onto the "ground" afterwards or not, right now OpenMW and Morrowind behave differently regarding this)
5. handle collisions between overlapping actors as a special case where they act like cylinders that are just barely touching, instead of their actual collision shape (while this plays poorly with capsules for some reason, it's better than what OpenMW is currently doing at the moment)
6. additional stairstepping hacks to make up for certain bad Morrowind assets when using AABBs/cylinders
7. detection of acute crevices and following them instead of getting trapped until running out of "bounces" (this is probably where most of the performance losses are)
8. EDIT: it makes steep slopes look like walls to the movement solver if the player would be deflected upwards by them

3, 4, and 5 can be implemented immediately. 6 is unnecessary until we switch to AABBs. 1 and 2 are absolutely vital, but might cause a minor performance loss. 7 is the most likely cause of performance losses but only matters in certain situations.

One thing I haven't tried yet is using a simple short-circuited movement solver when actors are exclusively touching "floors" and not "walls" or "ceilings". This is a situation where point 1, 2, and 7 don't need to come into play, so ideally they wouldn't be affecting performance in such situations. I've been working on something completely unrelated for a while, though, so I'll probably end up making a mini version of this that only implements 3, 4, and 5.

EDIT: point 8 can also be done immediately with no expected performance loss

[wareya]

Upon testing, the crevice detection logic actually speeds up the movement solver when it comes into play, because it causes the movement solver to exit in a decent amount of time instead of looping a lot unnecessarily.

[wareya]

I put the extra stairstepping hacks and the extra safety margin trace behind const member variables. EDIT: Oh and they're set to disabled. We want to re-enable them if we decide to use AABBs and double-precision bullet, but leave them off if we merge this while still using capsules with single-precision bullet.

[psi29a]

@wareya I would like to revisit this in light of the work being done on over here:
https://gitlab.com/OpenMW/openmw/-/merge_requests/215 (multi-threaded physics).

#2049 has also been merged, so I'd say this is ripe for inclusion in 0.47

Can we get a rebase and perhaps see how the MR on gitlab effects the situation here?

[wareya]

I would love to work on this again, but the dependency setup script for msvc silently fails part way through on my system, and it's unclear why, so I can't set up a dev environment with up-to-date dependency versions right now.

[ananace]

If you haven't rebased onto master recently then it may be because Qt retroactively disabled account-less installs a while back, which makes the official Qt installer unusable in CI scripts.
If you have rebased onto master recently though, then it may be because you're lacking Python - for the replacement Qt installer.

[wareya]

I have python 3.8.2, is that new enough?

[ananace]

Most definitely.

Could you try running the script with a -V as well, for verbose output, to see where it breaks.

[AnyOldName3]

There was also a new failure message merged yesterday, so try pulling master. Windows comes with a stub version of Python that's supposed to tell you how to install Python, but actually just dies with a permissions error if you try and run it through MSYS bash. It sometimes puts itself earlier in the PATH than your actual Python install.

[wareya]

Still doesn't work, it silently dies here:

Qt 5.15.0...
wareya@Toriaezu MINGW64 /c/openmwdev/openmw/CI (master)
$

Running verbosely gives this:

Qt 5.15.0... 2020-06-07 04:18:11,279 - aqt - INFO - aqtinstall(aqt) v0.8 on Python 3.8.2 [CPython MSC v.1916 32 bit (Intel)]
2020-06-07 04:18:12,592 - aqt - ERROR - Error while parsing package information!

[AnyOldName3]

Related to jurplel/install-qt-action#38?

[psi29a]

@wareya if you can/want, pop on discord and we can try to work things out. I would hate that we leave this hanging just because windows doesn't want to play nice.

[AnyOldName3]

@wareya I now have the same issue as you. Yay!

[AnyOldName3]

@wareya Something in https://gitlab.com/OpenMW/openmw/-/merge_requests/240 should hopefully fix it. Even if it doesn't, the error should get printed.

[psi29a]

Merged, I hope this does the trick. :)

[wareya]

The prebuild script works now, thanks. I'll build master and poke around and see what's changed.

[wareya]

Moving to #2937.