XNA seems mainly geared towards the FBX format, but as I recall it also supports X. Why not simply give it a try and see how it works out?

Quote:I can't believe it is this hard to export content from a 3D package into XNA.

Well, it is indeed tailored to Autodesk's products, but at least it's a step up from the old X approach. Perhaps the FBX converter might work for truespace file formats?

Quote:Ah, an official converting tool from autodesk. It only seems to support 3ds, dxf and obj files though. Truespace can export to 3DS, but does that format support skeletal animation?

According to this thread it supports only keyframed vertex blend animations and isn't a particularly good format. From my limited knowledge DXF and OBJ also aren't suitable for skeletal animation, so you might be stuck with X for Truespace.

A start would be to export to textual X (so non-binary) and see if the bones and animations are exported correctly. Next, try looking at the world transforms generated by the animation player to see if those make sense. Maybe that'll help in tracking down the problems you're having with X.

Quote:Btw, are there any guidelines that graphics artists should follow when rigging a model for use in games. I know about the limit on bones and influences per vertex. Does anyone have any experience setting up a functioning art pipeline for their game? Would be very interesting to know.

We've got two distinctly different XNA based pipelines set up for two projects right now, which goes to show how much the pipeline depends on what the project calls for. There is no "right way" to do it afaik. In fact, I realize I haven't really come across anything like best practices yet. If anyone has something to share on this, please go right ahead [smile]

For all its complexities, this is where the XNA content pipeline really shines though. You can start off with the built-in FBX loading for static meshes and drop in additional content processors as the project requires more custom functionality. The ability to manage the content and processors directly in the IDE takes another good bite out of the difficulties in creating art pipeline tools from scratch.

As for the art guidelines, these depend on what your XNA pipeline supports and can be extended by customizing the XNA content pipeline. In theory you could add processors and importers for just about anything, but mostly we found the default stuff works out fine. We had little to no problems animating some models that weren't designed for XNA, or even realtime rendering in the first place.