Re: [rant] crosswalk / fbx import

Date : Thu, 25 Oct 2007 09:23:42 +0200
To : XSI(at)Softimage.COM
From : André Adam <a_adam(at)49games.de>
Subject : Re: [rant] crosswalk / fbx import
The fbx im- and export is based on the original Autodesk dlls, unfortunately nothing Softimage can do much about. A while back we encountered crashes with a whole bunch of fbx files; support was able to get us the exact line number where the Autodesk dll crashed out, but obviously couldn't help us any further. It turned out that even Maya crashed the exact same way on this data, and the fbx files were generated with a current Motionbuilder release.

Bottom line, it's Autosdesk who can't read their very own file format.

   -André


Sam Cuttriss wrote:
And who says sarcasm doesnt translate well online!!?

ive flared up on this one occasionally myself, and wholeheartedly agree with you.
i just assumed it had been fixed as their hadnt been much noise about it.


_sam


*Sam Cuttriss * Janimation 3D Aficionado


peter boeykens wrote:

[start of rant]

Any have any ideas what the "rate" value in the import options might be for?
For some weird reason I expected it to be related to frame rate, as in: amount of frames per second. I typed all kinds of values, such as 25, 29.97, 30, 1234,0.0001 to find out that they all have the exact same effect on the imported data: none at all. A bit frustrated I tried typing fcukall, and to my amusement the tool didnt blink an eye, and happily digested a string where a float should apply. No errors whatsoever. Bottom line - the way to get a correct import is to set sequence frame rate before calling the import, and to ignore the option otherwise.


Also great idea to import the camera onto the default camera that is constrained to an interest and set some weird fov value and leave all else untouched. At least the resulting imported camera is so far of the mark, that there can be no confusion about the need to go in a verify and rectify a thing or two.
No worries, giving the camera an obscene name and hiding it in a model outsmarts the importer, and a new camera is made, that has untouched positional and rotational data. Now if only it was kind of vaguely directed at the scene?
luckily, at the end of the day, a bit of swapping axes, adding a couple of 90 degree rotation offsets, some negative signs and all's good?
Well the rotational values still dont match the FBX data - actually there is a one degree offset on all three axes. (wonder who didnt do his homework...) But I'm not going to let that hold me back now.


Oh right, camera settings! Luckily in this all-digital age I thought of scribling down all values on a piece of paper - so I can now type them in - and after a few attempts even conclude that it is actually as simple as that? typing the same values in the proper places simply works!!
Repeatedly on over 20 shots now, so I quickly script the thing - takes about ten minutes of work - make a little plugin out of it - and yes! now I have a tool that fixes all the errors the importer makes. (at least the ones I found so far)
the FBX data is consistent between three other 3D applications on import and export so I assume they're not collectively wrong.


Lets just hope none of this gets fixed in an upcoming release - I would hate to uninstall my first self-installing plugin.

[end of rant]

--- Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body: unsubscribe xsi


Search the XSI List archives here or use the advanced search form to search across mailing lists. Searching help is available.
This site supposedly brought to you by Benjamin Grosser and the Imaging Technology Group.