Bug #4241

Everything about development and the OpenMW source code.
thegriglat
Posts: 24
Joined: 12 Jan 2015, 16:22

Re: Bug #4241

Post by thegriglat » 12 Dec 2017, 13:41

Hi guys,

After some coding, I'm a bit confused what can be done next to fix this bug?

What we have now in PR:
* camera position depends on head x,y-coordinates, z-coordinate depends on RootNode (committed as workaround basically). Unfortunately, this changes camera view :(
* head targeting is disabled in FP. It seems OK, but after changing to 3rd Person player's head starts to rotate from camera view (forward). Maybe it seems logical (as in FP you control what you see and in 3rd Person -- not) but this behavior differs from vanilla.

The main problem -- moving camera underwater is not really fixed and I don't know how to fix it. Because z-rotation of a camera is based on spine deformation instead of head rotation (the same in vanilla). But this, of course, allows you to see hands when you look up or down.

User avatar
drummyfish
Posts: 108
Joined: 22 Oct 2017, 10:13
Github profile: https://github.com/drummyfish
Contact:

Re: Bug #4241

Post by drummyfish » 12 Dec 2017, 16:44

At least we know what's going on with the head now and the head tracking bug might be fixed, so that's something. I'll try to check out what you have, hopefully today. I'd really like to figure out why the hands rotate weirdly when you change the relative node for the neck controller - that might lead to fix.

EDIT:
* head targeting is disabled in FP. It seems OK, but after changing to 3rd Person player's head starts to rotate from camera view (forward). Maybe it seems logical (as in FP you control what you see and in 3rd Person -- not) but this behavior differs from vanilla.
You mean this?:

1. I'm in 3rd person, I get attacked and my head tracks to the enemy.
2. I switch to FP and then back to 3rd person.
3. My head is looking straight forward immediately after the change (but starts tracking shortly after).

It's because when you change to FP, the tracking target is set to empty Ptr (as suggested at GitHub) and so the head is reset to the original position, which we want, but after the change back it takes some time to set the tracking target back (there's a timer so that the tracking isn't updates each frame) and for the head to rotate. I personally like this behavior because it's logical as you say and even look nice, kinda adds more dynamic feel, but if you say it's different from vanilla I don't know - what do others think? It's only minor cosmetic difference which I think looks better and would take some effort to get rid of.

thegriglat
Posts: 24
Joined: 12 Jan 2015, 16:22

Re: Bug #4241

Post by thegriglat » 12 Dec 2017, 23:18

Trying to fix segfaults at continuous savegame reloads

Code: Select all

            if (mTrackingPtr.isEmpty())
                return position;
            const ESM::Cell* cell = mTrackingPtr.getCell()->getCell();
            if (!cell)
                return position;
            if (!(cell->hasWater()))    // <<<<<<<<<< segfault here
                return position;
            const osg::Node* baseNode = mAnimation->getNode("Right Foot");
            if (!baseNode || baseNode->getParentalNodePaths().empty())
                return position;
            const double waterlevel = mTrackingPtr.getCell()->getWaterLevel();
            const osg::Vec3d positionBase = osg::computeLocalToWorld(baseNode->getParentalNodePaths()[0]).getTrans();
            if (positionBase.z() < waterlevel &&
                positionBase.z() + mHeight * mHeightScale > waterlevel &&
                position.z() < waterlevel)
                position.z() = waterlevel + 0.5;

thegriglat
Posts: 24
Joined: 12 Jan 2015, 16:22

Re: Bug #4241

Post by thegriglat » 13 Dec 2017, 11:56

it seems segfault is fixed.
But anyway camera starts updating before cell is full loaded.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests