Making better use of Ogre's capbilities?
Posted: 02 Apr 2012, 01:40
Something I've noticing is that many of Ogre's existing systems aren't being utilized where they probably could be. For instance, the animations don't seem to be using Ogre::AnimationTrack, which automatically applies time-based transformations to an Animation, which in turn can affect a set of vertices, nodes (eg, bones), or numbers. Currently it looks like the transformations are done by manually poking at the bones or vertex data based directly on the Nif data. Perhaps it would be more efficient to build an animation track based on the Nif data, and let Ogre worry about the nitty-gritty details? I'd actually be very surprised if Morrowind did not take advantage of hardware skinning, and Ogre would probably be in the best position to do that with its own meshes.
OpenMW would just need an animation manager, to make sure the various animations are put into the proper animation time, the proper sounds are triggered (which likely need to be positioned on specific nodes, not objects), and so on. This should even extend to particle animations simply enough, because particles are just animated nodes that display billboard sprites.
Another thing is that some of Nif's node types seem to have very close (if not exact) analogues in Ogre. NiUVController -> Ogre::TexCoordModifierControllerValue and NiTimeController -> Ogre::WaveformControllerFunction for instance. It would take a lot of work off OpenMW's shoulders if we only need to worry about translating the Nif data into their respective Ogre/Bullet components, for those that exist anyway, then all we have to do is make sure it all runs correctly. Ogre will worry about whether it's hardware of software skinning, Ogre will take care of keyframe blending, Ogre will take care of controlling and morphing nodes and vertices given a time index, Ogre will make sure textures properly scroll, etc.
IMO, it may be worth looking at Niflib, which is more mature at handling and parsing the Nif data structures. It may also be worth considering to consolidate all the Nif loading code into a single place, and which is triggered by the mechanism that loads objects into cells (when an object comes in that references a Nif, all the components of the Nif (meshes, animations, collision, etc) are loaded manually into Ogre right then. That will help keep the Nif handling synchronized between components and subsystems, since it will all be together and happen at once.
I'd love to try doing something like this myself, but unfortunately the Nif format really does a number on me. I once started a project where I tried to load a Nif model into Ogre and display it... and I got a number of meshes looking close, but there were almost always a few things wrong with them (detached limbs, bad orientation, etc). Trying to load and apply the skeletons to the meshes just kicked my a**, and that was the last I touched of the project. But that was also me trying to tie the nif loading into Ogre's automatic resource management, which given various assessments (Nifs contain many types of resources that are interdependent), was probably the thing that was hampering me most.
OpenMW would just need an animation manager, to make sure the various animations are put into the proper animation time, the proper sounds are triggered (which likely need to be positioned on specific nodes, not objects), and so on. This should even extend to particle animations simply enough, because particles are just animated nodes that display billboard sprites.
Another thing is that some of Nif's node types seem to have very close (if not exact) analogues in Ogre. NiUVController -> Ogre::TexCoordModifierControllerValue and NiTimeController -> Ogre::WaveformControllerFunction for instance. It would take a lot of work off OpenMW's shoulders if we only need to worry about translating the Nif data into their respective Ogre/Bullet components, for those that exist anyway, then all we have to do is make sure it all runs correctly. Ogre will worry about whether it's hardware of software skinning, Ogre will take care of keyframe blending, Ogre will take care of controlling and morphing nodes and vertices given a time index, Ogre will make sure textures properly scroll, etc.
IMO, it may be worth looking at Niflib, which is more mature at handling and parsing the Nif data structures. It may also be worth considering to consolidate all the Nif loading code into a single place, and which is triggered by the mechanism that loads objects into cells (when an object comes in that references a Nif, all the components of the Nif (meshes, animations, collision, etc) are loaded manually into Ogre right then. That will help keep the Nif handling synchronized between components and subsystems, since it will all be together and happen at once.
I'd love to try doing something like this myself, but unfortunately the Nif format really does a number on me. I once started a project where I tried to load a Nif model into Ogre and display it... and I got a number of meshes looking close, but there were almost always a few things wrong with them (detached limbs, bad orientation, etc). Trying to load and apply the skeletons to the meshes just kicked my a**, and that was the last I touched of the project. But that was also me trying to tie the nif loading into Ogre's automatic resource management, which given various assessments (Nifs contain many types of resources that are interdependent), was probably the thing that was hampering me most.