viewtopic.php?f=6&t=4648&start=10
And Chris replied:scrawl wrote: ↑19 Sep 2017, 19:29It's a conceptual difference that can't be converted (well, you can convert the standard way to NIF's way, but not always the other way around). Most skinning systems will assign a bind matrix to each bone. NIFs assign a set of 'bone, bind matrix' pairs to each skinned mesh. This just complicates things, for the minimal 'benefit' of being able to use different bone bind matrices for different meshes on the same skeleton, something that's not really required if you design all of your assets with the same conventions. I don't think it makes sense to implement this in osgAnimation.What exactly is the issue with Morrowind's way of skinning? I'm sure it's been mentioned before, but I don't know where. Would it be possible to improve osgAnimation to support what we need? Would it be possible to convert Morrowind's way of skinning to something osgAnimation can work with?
As for the 'optimization reasons' thing, our component is mainly faster due to:
* Software skinning is done in the Cull phase, not the Update phase, to skip unneeded work for objects not on screen.
* Not using a synchronized draw traversal (instead, the internal geometry is double-buffered)
When I briefly brought up these ideas on the osg forum, there didn't seem to be much interest. The first one breaks when using camera-multithreading (which OpenMW doesn't use), and I haven't gotten to revising the solution to work with that. The second one is controversial because it complicates the implementation, uses more memory, and not everyone will see the same speed-up OpenMW did (mainly helps cpu-limited applications).
Anyway, I get the impression that osgAnimation isn't, or wasn't intended to be, much of a standard or a mature component. The way callback objects are used for updates makes serialization awkward (i.e. implementation details slip into the format). And recently, there's been a PR that happily broke backwards compatibility for a basic feature (defining bone weights), until I advised them not to.
I think we really only have two good options:
* Write a osgAnimation -> OpenMW converter and run this at load-time. This way we can, in theory, make use of osg's importer plugins for all sorts of formats and use the osg blender exporter as-is.
* Ditch the idea of using pre-made importers and write our own ones that will use OpenMW's animation system to begin with. We'll also need to write our own blender exporter for our own .osg format.
Chris I have started to work on this so I hope that's ok.Chris wrote: ↑20 Sep 2017, 08:22If there's no models that rely on being able to bind different matrices to different meshes on the same skeleton, I would imagine it's possible to take the 'bone, bind matrix' pairs of the skinned meshes and pre-map them to bone-specific bind matrices when loading (IIRC the PC/NPC skeleton nif contains a dummy mesh, perhaps giving a default set of bind matrices to map skinned meshes to). That's probably just a bit of hopeful optimism, though. It's been a while since I dealt with the horrors that is the NIF format.scrawl wrote: ↑19 Sep 2017, 13:29
It's a conceptual difference that can't be converted (well, you can convert the standard way to NIF's way, but not always the other way around). Most skinning systems will assign a bind matrix to each bone. NIFs assign a set of 'bone, bind matrix' pairs to each skinned mesh. This just complicates things, for the minimal 'benefit' of being able to use different bone bind matrices for different meshes on the same skeleton, something that's not really required if you design all of your assets with the same conventions. I don't think it makes sense to implement this in osgAnimation.
Option 1 does seem to be the better option to me too. I imagine the biggest issue may be that most animation systems prefer to split each animation group into a separate track, rather than having one large track with text keys indicating where each group is. Back before when we were using Ogre3D I always wanted to split the groups into individual animations (if for no other reason than to make selecting a group more efficient, since we need to do a linear search through almost the whole set of text keys to find where a group starts and ends, but also it would make it easier to replace individual groups), but didn't manage to resolve the issues. I probably could take another stab at it, but I'd need to get acquainted with how NIFs and OSG are being glued together nowadays first.I'd probably prefer option 1, but I'm not sure how well osgAnimation's keyframe system maps to OpenMW's (never used the former).
The link below is my first stab at an object level comparison of the nif and osg formats using the objects I found in base_anim.nif and xbase_anim.kf:
https://docs.google.com/spreadsheets/d/ ... sp=sharing
I've put N/A in the osg object column for the objects in these files which I feel should already serialize for import to osg just fine (haven't confirmed in all cases). I also need to still fill out the current openmw object being used for each nif object. Let me know if something looks out of place.