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?
Physics for non-moving actors
Re: Physics for non-moving actors
Nice to see you try to fix this. Hope you can come up with good solutions to the issues.
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Physics for non-moving actors
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
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?
Problem 2 was because of this:
https://github.com/akortunov/openmw/com ... f49f044eaa
scrawl committed on Jun 10, 2014
This was to fix bug #1441 https://bugs.openmw.org/issues/1441scrawl wrote:Fix dropped items ending up inaccessible when standing in objects with no collision
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?
Re: Physics for non-moving actors
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).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.
Obviously, it breaks some animated actors, so I had to remove this line.
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.
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Physics for non-moving actors
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.
As for the first issue with the camera is odd... Not sure how to solve.
Re: Physics for non-moving actors
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.
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.
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Physics for non-moving actors
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?
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?
Re: Physics for non-moving actors
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?
- psi29a
- Posts: 5362
- Joined: 29 Sep 2011, 10:13
- Location: Belgium
- Gitlab profile: https://gitlab.com/psi29a/
- Contact:
Re: Physics for non-moving actors
Can we see them and can they see us, otherwise... don't apply.
Re: Physics for non-moving actors
Just a quick test:
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.
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);
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.