Making better use of Ogre's capbilities?

[Chris]

I see that the people previously working on animations are inactive right now. Can't have that

I kinda figured you might not want even more changes that could cause problems for the next version (which I expected to happen relatively soon). I can probably look into supporting particles and billboard nodes, or maybe getting the first-person animation/camera info loaded, but I can't say how long it'll take to get those working since I'm not quite sure how I'd do it yet.

Shall we get started with integrating the animation system into the rest of OpenMW? We aren't ready for most of them (I am still waiting for some roadblock tasks to finish), but I am sure I can find something on the tracker.

Feel free to suggest. I can't promise much, particularly with regard to the lower-level engine stuff, but I can always take a look and see if something sparks in my head.

[Greendogo]

Personally I have always seen the in-game console primarily as a tool for content development, not engine development.

Why can't it be both? After all, OpenMW is open source and helping future developers with useful console commands may some how be useful for making the engine better later.

For instance, showing the FPS counter can be useful for both content developers and engine developers, and the FPS counter can be made to show with a console command.

[Zini]

Why can't it be both?

Because the console is not very useful for engine development, except for the case Chris mentioned (use of content to test engine features). We have for better tools available for the development of the engine (e.g. debugger).

That being said, I am currently working on some console related improvements, both for content and engine development. Will post about them soon.

[Zini]

Feel free to suggest. I can't promise much, particularly with regard to the lower-level engine stuff, but I can always take a look and see if something sparks in my head.

Doesn't look as good as I thought. We really need to get the player controls sorted out first to get a good test environment. Unfortunately it doesn't look like this is going to happen any time soon. Someone was working on it, but I haven't heard from this developer for a while and he was skipping most of the clean up stuff anyway. It is important that we get rid of all the cruft in the player controls now, because else it will only get worse in the future.
No dice here, it seems.

What you could do is to integrate the death animations into the engine, though that is probably more physics stuff than animation. I can explain the required changes in the non-rendering part of the engine (or even help you out a bit with them). From what jhooks told me last time the biggest problem here will be the positioning so that corpses don't hang in midair. I don't know how much we can do about that and if it would involve moving the NPC during the animation (which will also be of major relevance when walking animations are implemented).

If you are interested in that task, we should probably start a new thread for it.

[jhooks1]

At first I thought that the death animations definitely needed a lot of physics interaction, and that we should hold off on them. Now I have a different opinion, I think we should implement them with no physics interaction, and see what kind of problems we run into with corpses hanging in midair, going through objects such as tables, etc. Then we could develop plans on how we can involve physics.

[Chris]

NPCs (and the collision box) do move during the death animation. A couple of the animations have the character stumbling away or flying back, and the collision box moves with them so they don't go right through a wall. Though the collision box doesn't change shape so they can end up partly in the wall or ground anyway, it prevents them from going through completely and being unreachable.

[Zini]

So we are interested in doing this task? Definitely a new thread please! This one is getting full.

[jhooks1]

Chris, I had a chance to finally view your work in the latest master. Overall pretty good, but there is a problem with jerkiness. It is most apparent in the ash_zombie, but I have seen it across other creatures and even npcs. I am 99% sure this problem is coming from the manual interpolation you are doing for the keyframes (to properly implement the two separate NIF quaternion and translation tracks, into the ogre keyframes using Ogre::Slerp and a formula for translations). I actually had the manual interpolation working correctly when I implemented my animexperimental branch at one point, which was based on the second release of your animation project. I am going to post a video of the ashzombie and specify the point where things go haywire in a second.

[jhooks1]

Here is a video of the ash zombie using the new animation method http://www.youtube.com/watch?v=vxZsZzeV ... e=youtu.be
Skip to 1:05 to see the zombie floating vertically, when it is not supposed to be. You can verify this is not supposed to be happening by animating the ash zombie in nifskope.

Old openmw animation method http://www.youtube.com/watch?v=En5aYi1eNPg


The ancestor ghost has some similar problems. NPCs seem to be floating slightly back in forth in areas they are supposed to stay in place.



EDIT: It shouldn't be too hard to fix this, I can help if you wish.

[Chris]

Chris, I had a chance to finally view your work in the latest master. Overall pretty good, but there is a problem with jerkiness. It is most apparent in the ash_zombie, but I have seen it across other creatures and even npcs. I am 99% sure this problem is coming from the manual interpolation you are doing for the keyframes (to properly implement the two separate NIF quaternion and translation tracks, into the ogre keyframes using Ogre::Slerp and a formula for translations).

Yeah, I'm pretty sure it has something to do with the interpolation, too. I wish I could understand why it goes wonky, though. I figured it had something to do with the lack of Quadratic and TBC interpolation support, but I haven't yet worked out how they're supposed to work. It may require converting the animations into a constant FPS track (e.g. continually step forward in time by 1/fps and create the keyframes based on the nearby keys and the interpolation type, instead of continually jumping to the next key time exactly; since Ogre only does linear interpolation, we may need to do more manual steps in between the keys to get them to move correctly).

EDIT: It shouldn't be too hard to fix this, I can help if you wish.

That would be helpful, thanks. I'd at least like to know why it's going wrong, though patches/code would be useful, too.