Animations 2013

[Zini]

It would be fine as long as I don't access 'this'.

In theory, yes. But we should avoid relying on this behaviour. It is just too fragile. A minor change in the respective function and suddenly everything collapses.

I think the crash is because accessing the 'ptr' reference implicitly accesses 'this', which was junked because the actors list changed.

Maybe. Could also have been the update loop, because that is definitely broken.

[Chris]

Maybe. Could also have been the update loop, because that is definitely broken.

Even the current version?

Code: Select all

PtrControllerMap::iterator player(mActors.end());
for(PtrControllerMap::iterator iter(mActors.begin());iter != mActors.end();++iter)
{
    if(iter->first.getRefData().getHandle() == "player")
    {
        /* Make sure player updates last (in case a cell transition occurs) */
        player = iter;
        continue;
    }
    iter->second.update(duration);
}
if(player != mActors.end())
    player->second.update(duration);

[Zini]

Totally. If you are moving a NPC (other then the player) across a cell boundary, your iterator will still be invalidated. If you keep the "doing player last" part and switch to a while loop that increases the iterator, before you are doing the update everything should be okay.

An alternative solution, which also should cover your original problem, is to add a deleted flag to the CharacterController, which is then set instead of actually removing it from the container. You would have then to iterate a second time over the container and delete all flagged actors.

[LizTail]

I think jumping and falling is actually just additional force applied to the character, completely separate from the animation accumulation (does the jump animation actually move you vertically? it doesn't seem to).

Yes, I think so too. That's what I meant by being able to have an animation run that doesn't use any accumulation - it doesn't affect the movement of the character and the character is moved by code instead.

IIRC, there are rotation animations, but they're merely animations that play as you rotate and don't actually rotate you themselves.

Ah yes, the turn in place animations ::nods:: You're right.

What I'm kind of interested in, actually, is if the death animations rotate the collision box. A small problem I'm facing is how some animations (mostly death and knockout anims) move the accumulation node down, making it try to accumulate downward movement. When that fails (because of collisions), it would cause the body to float. So unless the rotation is applied to a the collision box/capsule, I'm not sure how it could be allowed to move down.

Currently this is handled by filtering out any Z movement from accumulation, so you visibly see vertical movement but it doesn't affect the object's actual position.

I think that's probably the correct way to do it. Most likely Z translation is never accumulated. In Gamebryo's later exporters, this would have been done by only moving the X and Y animation to the accumulated node, but perhaps Bethesda implemented this themselves by simply ignoring the Z component of translation.

I think swimming and levitation work the same way. The character always stays upright, but moves up or down based on the viewing direction (as if you were TCL; which probably means there's a simple flag I can pass to specify if you're being affected by gravity or not). At least with Morrowind... Oblivion may have fixed that so you do face up or down while swimming.

Interesting, I thought you pitched up and down when swimming, but it's been a while since I played Morrowind.

No problem. I need all the help I can get here.

I'm happy to do what I can.

[Chris]

I think that's probably the correct way to do it. Most likely Z translation is never accumulated. In Gamebryo's later exporters, this would have been done by only moving the X and Y animation to the accumulated node, but perhaps Bethesda implemented this themselves by simply ignoring the Z component of translation.

My only real doubt with this is that the "area" for an actor does change when they get knocked down or killed. When they're killed, you have to look down at them to loot them, and when they're knocked down IIRC you have to aim your attacks down to hit them (might be wrong on that; anyone confirm?). Maybe this is special-cased though, and/or you're interacting with something else other than the normal collision shape.

In any case, the latest code is pushed to my repo. The movement solver was moved to mwworld/physicssystem.cpp, and the actual movement stuff is handled like it used to be; a vector of objects and their movements is built, then it's handed off to World::doPhysics to do the actual moving. A copy of the Ptr and list of actors is used, so there shouldn't be an issue with objects moving out of the scene, and the player is handled last so external cell transitions work. I also fixed the input handling, so you move left and right correctly.

I do notice some issues, though:

1) There's trouble walking up the stairs/slopes in Beshara. You seem to get stuck like it's too steep or something. Perhaps the step size should be increased, or the max slope increased?

2) Movement is sometimes rotated wrong. If you kill certain NPCs, they move in the wrong direction. Also when TCL'ing, looking up while walking will move you downward.

3) NPCs don't seem to be getting affected by gravity. Haven't looked into this much yet, but either they don't have an associated PhysicActor, it's failing to properly look up their PhysicActor, or they're in noclip mode.


At this point, I think all the pmove stuff can probably be deleted. I don't think it's being called at all anymore.

[Rhys]

Perhaps the step size should be increased, or the max slope increased?

Has anyone done test for slope angle (including effects from differing levels) and also step height?

Btw I notice when morrowind decides you need to step up, it happens instantly (ie pops you to the top of the step).

[LizTail]

I think that's probably the correct way to do it. Most likely Z translation is never accumulated. In Gamebryo's later exporters, this would have been done by only moving the X and Y animation to the accumulated node, but perhaps Bethesda implemented this themselves by simply ignoring the Z component of translation.

My only real doubt with this is that the "area" for an actor does change when they get knocked down or killed. When they're killed, you have to look down at them to loot them, and when they're knocked down IIRC you have to aim your attacks down to hit them (might be wrong on that; anyone confirm?). Maybe this is special-cased though, and/or you're interacting with something else other than the normal collision shape.

Don't the characters have a collision box that's part of their skeleton? For bipeds, I think it was stored in the main shared skeleton NIF file. I would think that if the game animates a character into a crouching position, all the collision boxes would animate along with it, so you would still need to aim downward to shoot them.

When I said the Z animation probably isn't accumulated, I mean it probably doesn't affect the movement vector that you calculate and pass on to the physics system. It should still be applied to the animation.

Anyway, congrats on all the progress you're making! Very exciting!

Edit: I looked at one of the NIF files from Oshiel's animation replacer, and it looks like there is a "Bounding Box" node that has no animation, as well as boxes around each body part. I'm not really sure if Morrowind uses these smaller boxes for collision detection or if they're just placeholders for body parts. It might just be using the same sort of picking code that activation uses to make sure you actually have to click the character's polygons regardless of their animated position. I guess the way to find out definitively would be to edit the size of these boxes to see if it affects the game somehow.

[nopoe]

Go ahead and increase the max slope for now. It's at 45 IIRC and it should probably be more like 60 or something. Current step size is more than adequate. If anything it might be too big. In some areas it could move the bounding box up so far that it intersects the ceiling during the forward movement of the step, leading trace.fraction to be zero, so the step will basically fail, meaning you have to move using clipping alone, which doesn't work on some geometry. The problem is we can't get it below 27 without breaking favel ancestral tomb's stairs.

I was going to play around with the physics yesterday but I didn't get around to it. I suspect that increasing maxslope will solve the problems in beshara, though. If it doesn't I'll have some investigating to do.

I think I had a maxslope variable in both the regular movement function and the step function, which is kind of embarrassing. Watch out for that if you do change it.

[Chris]

Don't the characters have a collision box that's part of their skeleton?

They have a RootCollisionNode yeah, but it's not actually part of the skeleton. It doesn't move with Bip01, and it never has an animation applied to it. What it's for is apparently to specify the position and size of the collision area. Taking this screenshot from Unity's character controller, for instance:
http://docs.unity3d.com/Documentation/C ... oller.html
the RootCollisionNode seems to basically specify the Height, Radius (width/depth), and Center. It's completely up to the engine to move this with the character, the animation doesn't do it.

When I said the Z animation probably isn't accumulated, I mean it probably doesn't affect the movement vector that you calculate and pass on to the physics system. It should still be applied to the animation.

Yeah, that's what it's currently doing. The accumulation root doesn't take into account any changes along Z, and the NonAccum child still animates along Z, but that movement is never passed to the physics so it's a purely visual change.

Anyway, congrats on all the progress you're making! Very exciting!

Thanks.


@nopoe I'll try raising it to 60. Thanks.


Also, I figured out why the NPCs stay floating. PhysicActors all default to being in noclip mode.

[LizTail]

Don't the characters have a collision box that's part of their skeleton?

They have a RootCollisionNode yeah, but it's not actually part of the skeleton. It doesn't move with Bip01, and it never has an animation applied to it. What it's for is apparently to specify the position and size of the collision area. Taking this screenshot from Unity's character controller, for instance:
http://docs.unity3d.com/Documentation/C ... oller.html
the RootCollisionNode seems to basically specify the Height, Radius (width/depth), and Center. It's completely up to the engine to move this with the character, the animation doesn't do it.

::nods:: That makes sense. Maybe the bounding box is actually shortened by code when you crouch? I'm guessing for searching bodies it uses picking to get the exact polygon mesh you clicked on, and it could do the same thing for the player shooting at NPCs, but that wouldn't work from the NPC's perspective, so it might make sense for the game to just shorten the box when you crouch. Otherwise NPCs could still shoot you if you were crouching behind things.

I look forward to seeing NPCs walking around in one of the upcoming videos!