Animation

[Zini]

1) No, they don't play at all when I try them in Morrowind, I think they must depend on variables somewhere. For now only the basic groupNames work (stop, start, loop stop, loop start) and all works too.

Okay.

2) I switched it back to actor physics, I really don't know enough about openmw physics to improve it at the moment.

So the problem is in the physics, not in the animation? Makes sense. A job for gus?

@gus: Wanna give it a try?

At some point we are going to need very advanced physics for actors, including actors colliding with the ground and other objects.

Not so sure about that (at least for 0.12.0). Capsule shapes seem to work well enough.

3) All that is being written out now is play animation, when you play an animation. Do you want this removed? Also I think, but am not sure, that "changing to interior" was added by me, if so I should get rid of that.

Yes, please. We should try to minimise cout output. Large structural changes (e.g. cell loads) are okay for now. But anything more detailed is really too spammy.

4) Handled with the commit I just made. By default they are not outputted anymore, use --anim-verbose to output them.

Okay. But unless I am mistaking, you are still storing these files alongside the binary, if this switch is on. You don't have writing rights in this directory on most operating systems (when the game is installed). Instead you should store them in the openmw user directory.

[gus]

2) I switched it back to actor physics, I really don't know enough about openmw physics to improve it at the moment.


So the problem is in the physics, not in the animation? Makes sense. A job for gus?

@gus: Wanna give it a try?

That's OK for me, but i would prefere to finish the journal task first (switching branch with git takes a looong time).

[Zini]

Really? Switching branches is almost instant for me. But okay. No hurry.

[gus]

Well, switching branch is instant. But switching branches means recompiling the whole project which takes something like 30mn/1h on my computer. (and it means messing with CMake^^)

[jhooks1]

Last night I committed a change that greatly improves animation performance, for both npcs and creatures. I am now getting 115fps animating one npc, and 30fps animating all 10 at once in Beshara. Also animation files are now placed in the correct directory

EDIT: I tried hardware skinning with the new changes, no additional improvement (and all the colors mess up). I think I may have turned off ogre skinning. We handle our shapes and there corresponding vertex weights through our own handleShapes function. I think the ogre weights attached to submeshes weren't really doing much for us anyway. At this point I think that hardware skinning is not applicable to our project, but I am not completely sure.
The new changes work well though, so I am happy

[jhooks1]

Made a buffer designation correction, probably won't really affect anything (had it set to static write, should be dynamic write)

[Zini]

Found two problems with the animation code.

1. The update function was hooked up to the wrong update (in-game time instead of real-time) and it also was redundant in one place. I pushed a fix to a new branch (animationfix). Looks like animation is still working properly.

2. The functions setObjectPhysicsRotation can't stay in MWWorld::World. These functions expose internals of the MWWorld system and can potentially break class invariants. They are also very confusing. World should not expose any functions that can bring the World into an inconsistent state. I am not sure what to do about them yet.

[jhooks1]

We can get rid of setObjectPhysicsRotation, I was using it to experiment with npc physics - we don't actually use it now.

[Zini]

Right. Got fooled by some outcommented piece of code (which showed the function as still in use). Would be nice if you could go a bit lighter on these in the future (we have access to old code via git, so there is little point in storing it in comments). Anyway, I will remove these functions.

[gus]

Okay I corrected the position of the capsule shape. NPC activation should not be a problem any more. But it might require adjustment when NPC physic will be activated. Also, some race seems to be taller than others. For now, the physic system doesn't take that into account. Should it?

BTW, my changes are in openengine.

Edit: this raise a new problem: this suppose that the scene node is located on feet, and it does also affect the camera scene node. So when physic is on, the camera is located on feet position. The camera should be translated of 70 in the Z axis (the Y axis for Ogre?) but I don't know where to do this change in the new render system.