amade: the new version should load the rigged mesh correctly. The "problem" was just a scaling problem that BrfEdit added
for some reason on export. Anyway, now I add it too, so OpenBrf will happily inherit SMD rigged meshes left by BrfEdit.
Niiiiice rigged armor, btw. Impressive! And thanks for the test data.
Thanks for the compliment
Import works fine now for all SMDs of various sources (except for one case, see bug report below), but export is still mostly wonky.
BUG REPORTI tried to export skeletons to make new animations and got this:
Going back to the rigged mesh SMDs:
This was exported from a rigged mesh that was already in a BRF (I'm following the same test as I did with ver 0.0.7) - the scale is right, I checked with old SMDs, but the bones are still pointing the wrong way in Blender. To further test this SMD, I moved some vertices around and
re-exported it from Blender into SMD and then import it back into openBRF. Blender's export works fine so I expected it to still work alright by unmessing the bones like in the previous version but it gave me a new error when I tried to import:
So I reimported the SMD back into Blender to see if I can still open it but Blender gave me this error instead:
Weird... since when was there a named bone? All bones were numbered instead of named. So I checked the SMD I exported out using openBRF in Blender again and found out that all the bones have been renamed:
As you can see in the weight paint mode, the verts are all still properly rigged but the bones and vertex group names have been renamed. I don't know if this is the cause of the problem.
I tried to import openBRF's exported SMD using BRFedit, it imports fine but it looks like this:
As expected from how the bones are shown pointing the wrong way in Blender.
There's still an
import problem related to exporting. I can import an SMD into BRF but when I try to export it out I get this error:
SMDs I tested included native's, blender's, and
openBRF's own exported SMD (ver 0.0.8 ).
One more exporting issue: It seems that it changes the SMD's material name to "material_name"? This gave me quite a bit of headache when I needed to import into Blender with textures (usually I import without textures but I need to import with textures to preserve the UV info), but it's an import script related problem which I managed to solve by copying a DDS file and renaming it as "material_name" and placed it in the same directory as the SMD. Though it'd be nice if in the future openBRF exports with the material reference given in the BRF, I wouldn't have known what the problem was if the import script didn't tell me what to look for!
Tul: problem with the import of rigged mesh "kind of" fixed. It was related to that >4 bones per vertex. But, even if now it load them, it is a bad idea to allow >4 bone per vertices as M&B will not use them. Thanks for the data!
Good info, I'll keep that in mind.
...
Whew!
Sorry for the long winded bug report, took me about a couple of hours to write it up with countless edits so hopefully it isn't confusing. There's bound to be some contextual errors I left in it. At any rate, great progress so far. At the very least I can still use this to import rigged SMDs
+vertex animation (now I can import those female armors, yeehaw!)*. Keep up the great work!
*I just found out the Blender export script I use can't export animation sequences, I found another export script that can but need to test it thoroughly first.
