I’m trying to solve an issue I’m having trying to import a collada file exported from Maya into Blender 2.73a. The version reported in the XML for both is Collada 1.4.1. I have managed to get a successful import of the rig, and all looks well, until I try to export it again for testing on the target system. I managed to solve some of the problems it has by rotating the entire armature 90 degrees on the Z axis, but the bone scales are still very badly broken. I have also tried manually adding the data I found in the collada xml to custom ‘restpose_*’ props, but this doesn’t quite produce the results I’m expecting, which I suspect has something to do with the props being global in scope rather than inheriting from the parent bone, but I’m not sure. Questions I have are:
Is there detailed documentation anywhere about the latest collada importer and exporter for Blender? I’d like to be able to find out what the importer reads, what it expects, what happens if it doesn’t get what it expects, what it converts and how, and what, if anything, it ignores, and compare this to the raw XML of the file I’m trying to import.
It’s strange to me that the armature looks and behaves perfectly fine in Blender but breaks on the target system (Opensim/SL). Is there anything about the collada exporter that could explain this behavior, even when the appropriate preset is used?
Are the custom ‘restpose_*’ props calculated as if they are global or do they follow the parent/child inheritance structure of the armature? Specifically I’d like to know how restpose scale is handled. As I said above, I suspect they’re global (while the values from the file are local) but I want to be sure.
When a file is imported that uses the Y as the up axis, what is Blender doing to the data to convert it to its native Z_UP space? If there’s something that I would need to convert manually I’d like to know roughly what steps to take. Related, what steps would need to be taken on fixed data if the whole armature were rotated?
From what I know of the math behind it, the formula to convert local restpose values to global ones, if indeed that be needed, would be something like ‘global = local * parent_global’. Is this correct or is there something I am overlooking?
Thanks in advance,
I did lots of conversion back and forth from Maya and XSI (also Max, sometimes) back then, since the studio I was in at that time don’t really use standards and each lead artist are free to use whatever software they’re comfortable with and handed 1 project on their own mostly consist a team member or two.
The best conversion I had was with .dotxsi format, everything was left intact, but we don’t use much scripting nor custom scripts/plugins for the rig, just traditional bones/skeletons and we’re doing it quick and dirty.
I’m not sure whether .dotxsi is still developed today or not. Maybe you should consider it for an alternative. But it is opensourced back when Softimage was still around. Not sure about collada, since back then it was still young and I chose .dotxsi over collada because collada can’t do it (problems like you had now). But that was probably 4-5 years ago or so and I haven’t touched collada since.
Thanks for the reply, lycanthrope.
I hadn’t considered using another format besides Collada, as I did not create the mesh and would need to ask its creator for another format, or ask for the FBX, download a trial of Maya, and hope for the best. I did briefly attempt to use some third party plugins and software to convert the Collada file back into FBX and import that, but when it did work, it resulted in an export that had unreadable skin data. Searching for a .dotxsi importer/exporter also didn’t yield much in the way of results.
I went ahead and tried treating the scale values from the file as local, inherited scale values, and used the formula I posted previously in a spreadsheet to convert them all to their global counterparts. After noting some interesting patterns in the data, namely the appearance of symmetry, I tried them out in the custom ‘restpose_*’ properties, which resulted in an exported mesh which is very, very close to the one untouched by Blender, with a few caveats:
Likely due to the fact that scale inheritance was lost, the mesh looks like it has been blown up like a balloon when previewing the skin weights. However, on the target platform itself, the mesh looks normal.
Boundaries between sub-meshes no longer appear seamless in the version exported from Blender, yet no overlap can be seen.
When the untouched mesh is used as an overlay, the meshes ‘fight’ for the foreground in the renderer, where if two unaltered meshes are equipped, with one as an overlay, this does not occur.
Upon close inspection I think the issue in the latter two cases is that the scale is just a tiny bit larger in the version exported in Blender. I’m guessing that some decimal precision was lost somewhere to cause this.
Hopefully I’m on the right track, please feel free to correct me if not.