Page 2 of 2

Re: Bug #4241

Posted: 12 Dec 2017, 13:41
by thegriglat
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.

Re: Bug #4241

Posted: 12 Dec 2017, 16:44
by drummyfish
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.

Re: Bug #4241

Posted: 12 Dec 2017, 23:18
by thegriglat
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;

Re: Bug #4241

Posted: 13 Dec 2017, 11:56
by thegriglat
it seems segfault is fixed.
But anyway camera starts updating before cell is full loaded.