Physics for non-moving actors

Everything about development and the OpenMW source code.
User avatar
akortunov
Posts: 435
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Physics for non-moving actors

Post by akortunov » 04 May 2018, 11:02

Here is my first draft of fix for bug #3803.
The main idea: do not apply gravity for non-moving actors, as in vanilla game. This approach allows to fix some mods (such as Animated Morrowind and Arktwend) and reduce CPU usage by physics subsystem (up to half on my i7-7700).
This approach has a drawback: if actor's ground suddenly disappears (e.g. after end of levitaion), actor will hang in air.
So I check twice per second if actor hangs in the air, if yes, apply gravity.
This trick allows to keep advantages of original approach, but workaround its main drawback in many cases.

Of course, current implementation have some issues:
1. There are problems with player's position upon game load, so I had to disable this feature for player for now.
2. I had to disable position adjusting here since it breaks animated actors. But I suppose it was added for reason, right?

User avatar
lysol
Posts: 1069
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Physics for non-moving actors

Post by lysol » 04 May 2018, 12:27

Nice to see you try to fix this. Hope you can come up with good solutions to the issues.
Normal mapped texture replacers, exclusive for OpenMW:
My Nexus page

User avatar
psi29a
Posts: 4274
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Physics for non-moving actors

Post by psi29a » 04 May 2018, 14:41

Doesn't problem 1 get solved by itself (2 times per second) by having the player check to see if it mid-air and not moving, then is gravity applied? Or am I misunderstanding the issue?

Problem 2 was because of this:
https://github.com/akortunov/openmw/com ... f49f044eaa

scrawl committed on Jun 10, 2014
scrawl wrote:Fix dropped items ending up inaccessible when standing in objects with no collision
This was to fix bug #1441 https://bugs.openmw.org/issues/1441

Basically... if items are dropped, they were going through objects like a rug and becoming un-accessible.

I'm wondering if this is even necessary anymore with all the changes we've done to the physics systems already.

Can you test that this is no longer a problem? If not, then we can delete that one line of code.

Another thing we could do... is that when an item is dropped, why not just 'drop' them from half the player's height and let it fall. When it comes into contact with another object, then gravity shouldn't be applied anymore?

User avatar
akortunov
Posts: 435
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: Physics for non-moving actors

Post by akortunov » 04 May 2018, 17:03

psi29a wrote:
04 May 2018, 14:41
Basically... if items are dropped, they were going through objects like a rug and becoming un-accessible.

I'm wondering if this is even necessary anymore with all the changes we've done to the physics systems already.

Can you test that this is no longer a problem? If not, then we can delete that one line of code.
Works fine for me without this line. Actually, in upstream code we adjust position only for actors (move them 20 units above, then trace down).
Obviously, it breaks some animated actors, so I had to remove this line.
psi29a wrote:
04 May 2018, 14:41
Doesn't problem 1 get solved by itself (2 times per second) by having the player check to see if it mid-air and not moving, then is gravity applied? Or am I misunderstanding the issue?
There is a strange camera behaviour upon game load. If you move a bit, camera will behave normally. I guess we use some magic for player or camera.

User avatar
psi29a
Posts: 4274
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Physics for non-moving actors

Post by psi29a » 04 May 2018, 18:24

So long as the bug no longer effects us, then this hack s no longer necessary and instead of commenting it out, just delete it. :) Second issue is now a non-issue.

As for the first issue with the camera is odd... Not sure how to solve.

User avatar
akortunov
Posts: 435
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: Physics for non-moving actors

Post by akortunov » 05 May 2018, 16:25

I think I figured out, what is going wrong with camera. Take a look at this screenshot.
Here I started game in Balmora and loaded game in Vivec, Temple. An engine still considers player in Balmora, even if this cell is not loaded already.
That's because player is not moving upon game load. Applying gravity to player immediately after game load allows to workaround this issue, but I am not sure if it is a good solution.

User avatar
psi29a
Posts: 4274
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Physics for non-moving actors

Post by psi29a » 06 May 2018, 10:08

Brilliant!

What is the flow here? Are things just not initialized and that is why OpenMW considers the player to be in Balmora instead of Vivec? Was that with a save-game?

User avatar
akortunov
Posts: 435
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: Physics for non-moving actors

Post by akortunov » 06 May 2018, 14:16

psi29a wrote:
06 May 2018, 10:08
What is the flow here?
We update player's position here, so there already should be physics calculation after game load.

Anyway, it would be nice to have some testing and benchmarks.

P.S. Since we touched the physics performance theme, I have a question.
We have AI processing distance = 7168 units. By default, with "exterior cell load distance" = 1, we have scene radius = 8192 * 1.5 = 12288 units.
I suppose all objects from this radius are added to physics scene (collision world? I do not know a right term), right? Since we really update physics only for actors in AI processing area, physics scene contains nearly 3x more objects than really necessary. With "exterior cell load distance" > 1 multiplier is higher. How it affects performance, especially in large cities?
Can we implement some kind of visitor to check if object is too far and remove it from physics scene?

User avatar
psi29a
Posts: 4274
Joined: 29 Sep 2011, 10:13
Github profile: https://github.com/psi29a/
Contact:

Re: Physics for non-moving actors

Post by psi29a » 07 May 2018, 16:27

Can we see them and can they see us, otherwise... don't apply. :)

User avatar
akortunov
Posts: 435
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation
Github profile: https://github.com/akortunov

Re: Physics for non-moving actors

Post by akortunov » 08 May 2018, 08:50

Just a quick test:

Code: Select all

diff --git a/apps/openmw/mwworld/scene.cpp b/apps/openmw/mwworld/scene.cpp
index 2c2d401d1..ff35ba5c3 100644
--- a/apps/openmw/mwworld/scene.cpp
+++ b/apps/openmw/mwworld/scene.cpp
@@ -19,6 +19,7 @@
 #include "../mwrender/landmanager.hpp"
 
 #include "../mwphysics/physicssystem.hpp"
+#include "../mwmechanics/actorutil.hpp"
 
 #include "player.hpp"
 #include "localscripts.hpp"
@@ -69,10 +70,16 @@ namespace
         if (id == "prisonmarker" || id == "divinemarker" || id == "templemarker" || id == "northmarker")
             model = ""; // marker objects that have a hardcoded function in the game logic, should be hidden from the player
 
+        MWWorld::Ptr player = MWMechanics::getPlayer();
+        osg::Vec3f playerPos(player.getRefData().getPosition().asVec3());
+        osg::Vec3f pos(ptr.getRefData().getPosition().asVec3());
+        float playerDistSqr = (playerPos - pos).length2();
+
         ptr.getClass().insertObjectRendering(ptr, model, rendering);
         setNodeRotation(ptr, rendering, false);
 
-        ptr.getClass().insertObject (ptr, model, physics);
+        if (playerDistSqr <= 8192*8192)
+            ptr.getClass().insertObject (ptr, model, physics);
 
         if (useAnim)
             MWBase::Environment::get().getMechanicsManager()->add(ptr);
Profilier results on my hardware (physics line) in cities:

With "exterior cell load distance" =1:
Master: ~4
Ignore standing actors: ~2.5
Ignore standing actors + limit collision world radius by 8192: ~1.5

With "exterior cell load distance" =2
Master: ~5
Ignore standing actors: ~3
Ignore standing actors + limit collision world radius by 8192: ~1.75

With "exterior cell load distance" =3
Master: ~7
Ignore standing actors: ~5
Ignore standing actors + limit collision world radius by 8192: ~2

IMO, it is worth to investigate.

Post Reply

Who is online

Users browsing this forum: No registered users and 5 guests