Making better use of Ogre's capbilities?

[Chris]

Yes, it works! Now to make it look smoother.

Cool Feel free to swipe my animation loading code. It does the interpolation to prevent jerky movement.

For shapes without skins, the best solution at this time may be to just modify buffer positions. Most creatures/npc parts containing a skeleton do not have a shape like this, so it shouldn't slow us down to much

If you're not using separate entities, the shape's vertices will need to be weighted to the last node defined before it, otherwise it won't animate with the bone[1]. The shape's vertices shouldn't be transformed since it will be connected to the bone, which is initially at the skeleton's root, and move with it.

There is a bit more to how unskinned trishapes are connected to the bone, though, which I haven't figured out. For instance, with "meshes/wolf/xskinnpc.nif" I have to rotate the head using

Code: Select all

rot.FromEulerAnglesZYX(Ogre::Degree(0), Ogre::Degree(90), Ogre::Degree(15));

to get it to fit. However, with "meshes/r/xhircine.nif" that rotation is incorrect and causes the spear to be oriented wrong (it needs to be translated by some amount instead of rotated, to line up as expected).

[1] Do note, though, that there seems to be a very noticeable drop in performance when I weighted the whole werewolf head to the head bone, even with just one skeleton instance and one copy of each mesh. Attaching the unskinned trishape to the bone using attachObjectToBone performs much, much better, but requires separate entities to be built for each trishape.

[jhooks1]

Tried your code that makes interpolations, looks like it needs some work. At the beginning and end the creature sort of floats through air. Probably going to try to rig up something that does interpolation when we need it .

[jhooks1]

I rigged up my own implementation which uses the Nifskope time index function for interpolation between frames. Everything looks good with the ash zombie, animation looks the same as the current custom openmw solution.

[Chris]

Cool. How does it perform in comparison to the previous method?

Another thing I notice is that the vertex buffers are not using a shadow buffer (the last boolean param to createVertexBuffer). Without hardware skinning, which we can't do with the custom shaders, this will require a (slow) readback from the hardware to modify the vertices, then rewrite them. The shadow buffer prevents the readback by telling Ogre to keep a local copy to work with.

The vertices, normals, and uvlists should have shadow buffers since they can be animated, though it'd be best if we could differentiate between animated and non-animated trishapes to keep the use of extra copies (and inefficient HBU flags) down.


Also on a similar topic, the amount of work done in NIFLoader::loadResource method should probably be cut down, a lot. The loadResource method should just worry about loading its respective resource type's data (in this case, the mesh's vertex data). I don't think it's appropriate, for example, to handle the collision and visiblity flags, or the extra data, in handleNode since they're not part of the (sub)mesh info that needs to be loaded here. The materials should also likely be handled in NIFLoader::load, so they're only created/mapped once, as opposed to NIFLoader::loadResource (incidentally, it looks like materials should have a manual loader too..).

Only data that's lost when the resource gets unloaded should be loaded in loadResource, because it can happen multiple times over the life of the resource. Like the skeleton name, all the other info can be set or stored once after its initial creation.

That would be something I could look into doing once this is done up and merged into master.

[jhooks1]

Haven't made a comparison yet, waiting to do a few more things first (NPCs). I think the new ogre implementation with hardware skinning will blow the old one out of the water though.

[Chris]

I think the new ogre implementation with hardware skinning will blow the old one out of the water though.

Yeah, but as I mentioned, we won't have hardware skinning with the custom shaders. Hardware skinning is done by passing 1 to 4 transformation matrices (depending on how many are needed for all the vertices in the (sub)mesh) to a vertex shader, which then transforms the input vertices and normals on the GPU.

Though I don't expect it to be any worse than the previous method. And it does open the door to hardware skinning if there's some way to get our shaders to play nice with Ogre's mesh skinning. I'm just not sure if our current way of using shaders will work.

[scrawl]

Hardware skinning shouldn't be a problem, just need to merge it with the standard shader we currently use.

Besides, it affects the vertex shader only, so there's nearly no risk of making the shader too big or hitting the limit of vertex to fragment passthroughs.

[Chris]

Just wanted to make a further note that Ogre has AnimationStates associated with Animations. Using this you could split up the various animations (Idle1, Swim Left, etc) into separate states, then enable/disable them as needed to change which animation plays. You can even blend multiple animations this way by having more than one enabled at a time.

The only tripping block is that, as far as I can tell, some of Morrowind's animations can have a looping portion within a non-looping state (so you can have a lead-in, followed by a continual loop while the animation is used, then a lead-out when stopping). I don't think Ogre supports something like this natively, but it should be possible to do it "manually" by breaking them up into separate states and controlling what state is used when.

[jhooks1]

Trying to get non-skinned shapes working along side skinned shapes. Have not figured it out yet.

[jhooks1]

Good news guys, I got unskinned shapes working within creatures without using attachObjectToBone or modifying buffers. Unskinned shapes are responsible for rendering the flame atronach's hair and the ogrim's head, and much more. Gonna commit my code in a sec. We are getting closer to having ogre animations work completely, which I think should give us a sizeable performance boost.

We may be able to get rid of the handle shapes function entirely, right now the only purpose for it is morphing animations.

EDIT: Also we were having a problem that I fixed. Not all bones have KeyFrame controllers, the ones that don't need an initial position and rotation to be read in from the NiNode.