Oh, thanks for the reply.
Good find, will document it properly. Or even better, see whether the COLLADA exporter can be in a repository under OpenMW and just link that. It's something we mentioned some time ago but haven't gotten to yet.
Yes, it is an OpenMW fork by unelsson
. The patch is for the purposes of OpenMW I think. Hmm, and since my test failed either way, I am not sure if you need the patch or not... I assume it was made for good reason, though!
I don't think Collada support is a hugely important feature if it takes too much effort, since .Nif is working fine since Blender's NifTools plugin was updated to 2.80+. The rest is stuff I was writing before you replied, so here it is:
OK! I've done a bit of fiddling and research and here's my conclusion: In order to make it feasible to do replacers for things, I need a way to find out what animations the file has and which frames they are on. Or at the least, the names of the animations the file is expected to have. Without this, knowing how to animate the file is shooting in the dark, so any replacer will have to use the same rig (and thus the same proportions). This wouldn't be so bad if the files imported well, but whether it's due to the proprietary format being hard to interpret, or the awful practices of the early 2000's, the models come into Blender with extremely wonky poses and transformations. This makes any work on the original files a chore.
Moreover, I have noticed that the animations store only the keyframes that are being used, so sometimes they expect the rig to be in a certain state before they begin (idle animations should be playing first), so even importing the animation into Blender will lead to incorrect results. There are files in which a different model is used in the death animation, too, and I don't have a clue how that sort of model-switching works, nor how to replace it. There doesn't seem to be any visibility animation, and I doubt animation in the materials would import or export. There's other little oddities, like shadow-meshes that don't seem to have any special identifiers... how does OpenMW know they're shadow-caster meshes and not the main geometry? There are probably a lot more little things like this.
Finally, the old files seem to use vertex animation (also known as shape keys or blendShapes). I don't know if there's anything important to know about when dealing with vertex animation in OpenMW. I don't know if the exporters support it.
So, here's what I need:
- Some way to learn about the AI of individual characters -- which animations they play, hardcoded links between files (humanoids, for instance), which animations depend on others... (I expect this is very difficult to do)
- How do weird features like model-switching and shadow meshes work?
- Knowlege about how vertex animation is handled by importers/exporters/OpenMW.
I think in order to get OpenMW to work with a more modern pipeline, it's imperative to make it easy to make art for it. Having to make guess about stuff that was hard-coded into the game 20 years ago is as hard for the artist as it is for the OpenMW devs! I hope it doesn't seem like I am complaining, as I am well aware that this entire project started with a huge amount of guessing and extremely difficult tech-detective work. I'm willing to do some of this, but I don't think I have a big enough brain to do it all myself.
In the meantime, I have succeeded in making a .nif body replacer, but because I don't have the ability to replace the rig, it's unlikely that I'll be able to improve on Better Bodies. The longer I fiddle, the more it seems that the flaws in BB are due to the constraints they were working under. Same goes for enemies and such. I want to improve on them, but I doubt I can surpass other artists without the ability to redo the rigs and animations.
Edit: EVEN WORSE! The files that reuse rigs/animation can also change them... so the rest/binding pose of a rig can be different from file to file. Which is yet another complexity to work through!
Edit: I have made a wonderful discovery. While I was unable to find the text keys that identify the start/end of an animation group in the .NIF file itself using NifSkope... it turns out the text-keys are stored as plain text inside the .nif file. It would be fairly easy to figure out the groups being used this way. Unfortunately... the frame numbers are still stored in binary format. The grind continues! It may be easy to find the numbers, since I probably only have to convert them from something. Hexadecimal? I'll keep looking into it.
Edt: I am an idiot. It's easy to find in NifSkope if you know where to look. The node is "NiTextKeyExtraData".