XSI bones animations does not work properly ?

I’m trying to use XSI to create 3D animations for PaperVision (a Flash 3D Engine that reads Collada).
It works when objects are not animated.
When object are animated (bones) ; Softimage’s Collada produce bad results (mesh animations are wrong !). It’s not the fault of Papervision : the same cynlinder animated in Forward Kinematic with 3ds max works perfectly with Papervision.
As I’m not a software ingeneer, I can not say exactly what is wrong with Softimage’s Collada ? With XSI’s Collada every transformation is “ungroup” with each 3 axis (posx,posy,posz…), whereas 3ds max’s Collada group (pos, rot, scale). Also, XSI export only “ID” Tags, whereas 3ds max export also “name” and “type” properties.
Is there anybody that have a workaround to make XSI’s bones working with Papervision/Collada ?

PS : I use Softimage XSI7 & Crosswalk 3.0, it’s a simple cynlinder with only two bones that rotate in Forward Kinematics. There are no other transformation apply to the cylinder. When I import it in Papervision : the mesh is not correctly animated (deformations are “strange”).

Hi Ben,

I don’t have XSI 7 yet but will soon, if you can post a sample file in XSI format that shows the bug when exported as COLLADA, it would be helpful.

I’ll also point the XSI engineers to this post and see if they can offer any help.


A new version of Crosswalk 3.1 (Softimage XSI Collada exporter) has been released. Unfortunately, there are no significant improvements and it’s still impossible to export a mesh driven by a bone into Papervision, OpenSceneGraph or Ogre3D.
I suppose that nobody is using XSI to generate Collada for those 3D engines?
Collada should enhance 3D workflow, but the fact that feeling software Collada (3ds max/maya) and softimage Collada are not compatible is a bad news for all 3d artists.
Collada can be a standard if everybody use the same rules ? For end users - like me - I should not be penalized while using Softimage.

By the way, do Softimage or Feelingsoftware passed successfully plugfest (tool’s interoperability) ?

PS. I have also post this message into Softimage forum.


We are aware that some applications does have problems importing XSI generated COLLADA files. We cannot agree more with you that it’s a very unfortunate situation.

What happen in those cases, and it’s always the same story, is that the implementers of those application specific COLLADA importers often did not code their importer by looking at the COLLADA spec. They coded it based strictly on COLLADA file exported form 3dsMax. As a result, they support only a subset of what’s totally legal in COLLADA and worst than that, they often make assumption that elements in the file (id, names, hierarchy, etc.) will be exactly as 3dsMax does export them and if they don’t, the import fails.

This is especially true with transform stacks. Even if XSI has a very simple and documented transform stack, it’s not the same as the 3dsMax one and problem can occur with implementations that supports only the 3dsMax flavour of COLLADA. One cannot expect all applications to standardize on a give transformation stack so that’s why COLLADA itself allows for very arbitrary transform stack representation to enable every application to represent their transform stack in a lossless fashion. So, that’s what we do, we express our transform stack, which is different from the 3dsMax one, in COLLADA, and it’s completely valid. A thorough importer implementer would detect if a given transform stack is compatible with his application and if it isn’t, he would evaluate and bake the transform into his own transform stack. That’s what we do. We support every arbitrary transform stack at import.

Additionally, we do make sure that the COLLADA files exported from XSI are valid. We validate our file against the COLLADA schema and we also run the Coherency Test so, you can be insured that when you export a COLLADA file from XSI, it’s valid. You can run the coherency test and COLLADA schema validation on your own file by using the COLLADA Refinery if you want: http://sourceforge.net/projects/colladarefinery If you encounter issues please do send them our way, we do care and fix those issues.

To help solve this complex situation, we do put a lot of hope in the COLLADA Conformance Test that Khronos is developing; project into which we’re participating. With that test, to be able to be considered COLLADA Conformant, applications will have to support more then the 3dsMax subset. But we’re not sitting there and waiting for that Conformance Tests to come out. We did participate to the Intel Plug Fest and we had great success of interoperability with the companies that were present. We tested our plugin with the next gen 3dsMax and Maya plugins (not implemented by FS btw), with SketchUp, Cinema4D, Daz, Poser, etc. and everything worked like a charm. The issues that were unveiled at that Plug Fest were fixed and released in Crosswalk 3.1 – only two month later. We do also contact personally companies with which we eared that there was issue with our valid COLLADA file to see what can be done. For instance, even if the node type=”JOINT” is optional in COLLADA and strictly there for editor display purpose, some do rely on that to implement skinning so we made their life easier by exporting it. It’s the same for the tag name issue with Papervision 3D. Tag name are optional in COLLADA and it’s a bad design to rely on that but adding support of that to make the life of Papervision 3D COLLADA import implementers easier is indeed on our todo list with high priority.

I hope that this long post does clarify things. Now you know that you can make a difference by contacting the implementers of the importer with which you have issues. You do have the proof in your hands with the Refinery Coherency Test that your file is valid and that they should be able to import it if they claim to support COLLADA.

On our side we do have plans to try to make things easier. As I mentioned, we do have the tag name issue on our todo list with a high priority and we’re also looking into an optional export of transformation stack into an equivalent simple baked matrix which should be simpler to digest for importer that can’t handle our already simple transform stack.

As far as your preset request is concerned, in the Crosswalk export and import dialog, you have a little file icon on the top right. You can save and load Crosswalk options preset with this. Is this what you’re looking for?


I have answer your post at http://community.softimage.com/showthread.php?t=2550 .
This is a very important problem : Collada should be a 3d file format that simplify 3D exchange of 3D assets.
It’s the reason why I think that it’s nice that major DCC package support this format. But for end user Collada should be a reality, not a wish or a dream.
Today, asking every 3D engine to be compatible with specific Collada implementation is a nonsense when you think that Collada is a standard with normalized specifications.
I ask Collada representative to take care of their format so that it can be used in major softwares that pretend to be compatible with. What do you think?