FBX/FBX SKD questions

Tools
#1

Hi,

We are looking at moving our character and animation content pipelines into Maya and one suggestion that came up is using FBX as our “Export” format for animation and potentially characters.

If anyone has done this or though about it and some point I would love to hear your thoughts on it! Also on using the FBX SDK and extensions.

Currently we do characters in Max and export into an in-house format. Animation is done in both Max and MotionBuilder and is exported in XMD files (We are using Morpheme but think want to ditch it and roll our own).

Cheers

#2

I absolutely hate FBX. It is the biggest lie in 3d software.

Remember that FBX is the MotionBuilder scene format, and that’s all it was ever meant to be. Use it as anything more than that- including the utter bullshit Autodesk feeds us year after year about interop- and buyer beware.

Writing a baked file format isn’t hard (and it’s easy to test thoroughly), and until we have a good, open, standard one, I’d say this is one area where I always suggest rolling your own.

I’ve been down this road at 3 games and every experience- widely diverse subjects, believe me- has reinforced my opinion.

First there was getting motion data from a mocap studio as FBX, instead of BVH (which we rolled a loader/dumper for but hey at least it’s understandable). But there was no .NET FBX SDK, and the entire format is undocumented, so no way to roll our own serializers.

Then there was an FBX->XMD converter. It was slow and had intermittent failures. Nothing ever beat our hand-rolled XMD exporter (actually, our DCC->inhouse intermediary-> XMD/BVH/Whatever exporter, could handle all sorts of animation).

Then there were attempts at going between XSI and Maya using FBX. What a mess. Even simple test cases didn’t work right.

There were more examples but I don’t think I need to go on.

#3

I would not recommend using FBX for moving between max and maya, I’ve been down that alley and it’s not a fun alley at all. You will have lot of problems that seems more or less random and the only way to solve it is to do the whole export process over and hold your thumbs. Lets just say that the alley has a big “Here be dragons” sign at the entrance.

I’ve used the FBX SDK for some data parsing on FBX files that has been edited and worked on in motionbuilder and it works OK and there is some documentation about the fileformat inside of the SDK… However - a big problem that I’ve seen is that some of the features from motionbuilder (characters and character extensions) can’t be access thru the official SDK to the official fileformat for Motionbuilder… Now, that is weird.

I could continue the rambling Rob started above with all the quirky things you find while working with FBX but let’s not :slight_smile:

I’d go the way Rob says - work up your own system for moving the data instead of FBX if that is a possibility for you.

#4

Don’t use it for your game format :slight_smile: I don’t hate it as much as some because it has a place and time but as a final game format to ingest, no.

Anyone that hasn’t voted yet could go add their voice for a fully opensourced FBX that I suggested.

And only then would it might be ok as a format to export to /ingest from but there are lots of things to consider as you will want to have management of the data outside of MotionBuilder or any existing tool that requires .FBX software support.

In short- no, don’t! If for some reason you still say, but it won’t happen to me go read my FBX post

and the link to the previous one that covers some of the last year of FBX nightmare

Brad

#5

Just curious while you clearly have an opinion of the usage of FBX, what is your preferred method of moving data between dcc applications? This data being of course skinned meshes and animation. We have our own game animation and mesh format exported from 3dsmax but we haven’t had the need to import it and manage animation after the fact. However, we are moving to a point where we have a need to push all of this data between 3dsmax, Maya, and Motionbuilder. Sure we could write additional C++ exporters and importers for these applications but for what purpose if FBX already handles most of this in a general sense. I’m sure I may be a bit naive not having the experience you have had in the past but it seems there is already some great benefit to using FBX in this regard. From what I can tell FBX has come a long way and is getting much better with its usage in the interop capabilities. I’m not implying that I could even consider using the “Send To” but moreso the content within the FBX format being recognized in all packages properly.

#6

I also try to avoid using FBX.

Personally, I think the ideal situation is to use importers/exporters that can use your game data. As for the ‘purpose’ of building something that FBX already mostly handles, I’d say it is the same as anything a TA touches - to constantly improve the weakest link in the system in order to improve long term efficiency and maintenance of the system. In my opinion, not having full control of your data format at all stages of development is a pretty weak link. However, I fully understand and agree that moving away from FBX may not be the highest priority (isn’t that the TA creed? ‘Is it broken? Nope? On the to the next thing, we’ll update this once everything works!’), but I think taking full ownership of the pipeline (including all data formats) is definitely something to consider in long term system planning.

Phil

#7

Randall: So first I’d say, why bother with C++? If you’re doing interop, make it slow and stable, and use your scripting languages or whatever makes it easier to develop and maintain.
Then I’d say, definitely try FBX, spend a week, if it works, great, if it doesn’t, don’t keep going. You will save a lot more than a week if it works, you will lose a lot more than a week if you try to stick with it if it isn’t working.
And regarding its ‘improvements’: Yes, I thought the same. And like I said, biggest lie in 3d software. :slight_smile:

#8

So far we’ve been quite happy with FBX (of course we don’t use it as a runtime format, but just a generic thing we can import in our tools). That being said, we’ve had to do special cases like “if asset came from 3dsmax with Z-up, do this special thing…” etc, but that’s quite normal I guess. FBX is not a silver bullet.

Bake down everything in the DCC tool, export a minimal set as FBX and we finally are free from having to write custom exporters for all random modeling packages.

SamiV.

#9

[QUOTE=samivRMD;17272]So far we’ve been quite happy with FBX (of course we don’t use it as a runtime format, but just a generic thing we can import in our tools). That being said, we’ve had to do special cases like “if asset came from 3dsmax with Z-up, do this special thing…” etc, but that’s quite normal I guess. FBX is not a silver bullet.

Bake down everything in the DCC tool, export a minimal set as FBX and we finally are free from having to write custom exporters for all random modeling packages.

SamiV.[/QUOTE]

I think this is precisely what our DCC use case will be.

I definitely hear what you are saying Rob, 12+ years of experience with the Autodesk products will leave you getting burned many times if you rely on them too heavily. However, this is the best effort they’ve made in making a format general enough to be interpreted by most of their packages in a somewhat “reliable” manner. I’m not hedging all my bets here but I am optimistic. I will keep you informed on any problems or successes that may come of our use cases.

#10

@others- I have no problem with using for DCC transfer, I use it, I like it when it works and I don’t have a problem 99% of the time, but as a final game export format it doesn’t make sense to me unless it is an open format.

A final game export format that is created external to the DCC tools from FBX would be fine and save from having to create a diffrent export plugin per software but there are just so many special cases that it doesn’t work in my mind, It is improved and there are smarter pipeline/tools guys than me but I wouldn’t want to have to deal with the end of project file bloat and processing lag that awaited a FBX only format.

Now normally I am all for removing custom tools when possible to keep steps down and just use what tools are available but I am still recommending to not use it as a final format for game data.

#11

For our Unreal character pipeline, we have recently begun to switch from the now deprecated ActorX Exporter (https://udn.epicgames.com/Three/ActorX) to FBX, as per Epic’s decision to exclusively support the format. Initially, the process was pretty painful. ActorX had the advantage of being a custom solution, and as such, it did some hand-holding and was generally more forgiving than FBX in so far as Unreal is concerned. In preliminary experiments with FBX, most of our existing character rigs failed to export as expected. However, through some trial and error we’ve managed to overcome these export issues. Due to the aforementioned rig compatibility issues and the relative ages of the code bases of our various projects, we’ve decided to continue to use ActorX for our released and near-release games. Going forward, the plan is to exclusively using FBX for recently initiated projects and future games.

I do agree that FBX should be more open, and I think that I would’ve preferred that Autodesk had gone with COLLADA for an interop format (I realize that COLLADA has it own issues and that it probably wouldn’t have made as much sense for Autodesk from a business stand point). As mentioned, the FBX format definitely has some maturing to do.

#12

Hi and thanks for all your input,

I’m mainly asking to find out if it might be a valid export format. As far as DCC “inter-op” I’ve used it in one form or another over the years and I would say It’s gotten a lot better in that time. And it’s a bit like Maya referencing. It kind of sucks, but if you need that functionality, the benefits far outweigh the disadvantages, unless you roll your own of course :slight_smile: On that note, while reading though the PDF’s from the latest Tech Art Boot Camp (they were great by the way) I realized that some studios actually have dedicated tools programmes and more than one technical artists… (Jealous)

So as mentioned using FBX should would open up some doors, mainly allowing content to be published from any app that has an exporter (in theory anyway). That’s the main selling point for me. This obviously leaves the artists and me, freer to work in whatever we want. I also like that there is a Python wrapper for the SDK, so that I – a non C++ savvy person – might read/write and potentially extend the format. Right now our exporter is in C++ and thus I’m hightly dependent on en engineer to write any additions. Waiting for the person who wrote the exporter to free up, only to have his time be re-prioritaced once he get’s to that task, could mean waiting months for something trivial to get implemented at worst. Not ideal.

A real concern with FBX is speed, as our engine uses hot loading of assets. So the time from the animator presses export, to the animation being “cooked” and available as a resource in the engine, is key. We noticed that something like the FBX binary->ASCII converter is very slow… Since Unreal, CryEnging and Untiy all support FBX, they must be doing something right though?

Anyway’s I need to talk more to our engineers about what they are actually planning. I’ll let you all know how we fare :slight_smile:

#13

Also don’t forget that FBX has an internal Bake so you don’t need to bake your anim assets prior to FBX output, it’ll do it for you on the fly.

One thing that we’ve done in our Collada is have it capable of serializing our own version of MetaData. So in the C++ core of the exporter it has a generic handler for writing and adding this data to the Collada schema. The beauty of it is that from our Python calls all we have to do to get new features into the output, is hook some data up, flag it for serialization, and the generic Collada handler does the rest for us. So no case by case adding of new features, it’s just all handled dynamically and it’s saved us SOOOOOOOO much time and work.

#14

I’m with Brad on FBX. For me it works most of the time when I’m taking stuff between Maya, Mudbox and Mobu, with Maya<>Mudbox rock solid for me. For Max I can’t really say as I don’t use it and honestly I’m not a fan of Max either, lol. I also find the transfer between between Softimage abit twitchy as well, with some things working better than others.
Personally I wouldn’t use FBX as an ‘in-game’ format either.

#15

@Mark,

That sound pretty darn interesting. Got some code snippets you want to share there? :wink:

#16

@Bellsey

Can you elaborate on that?

Also while I’m assuming it’s clear to all present, just to be crystal: We are not talking about using FBX as our run-time format. Just as our export, that would be compiled into the engines native format.

#17

Not that I can share, but the idea is very simple. In the plugin it looks for specific attribute markers on Transform Nodes that denote what attrs on this node to serialize generically, whether they’re animated, and what to marker them as in the Collada. We also then look for connected MetaData nodes and serialize those out.
It all means that as a TD we can dynamically modify the contents of data going out to the Collada without the plugin having to be recompiled and modified all the time. The import into Engine then reads the new MetaData and yes, that has to be coded to know what to do with the data when it finds it, but half the battle for us used to be modifying and adding data to the output in the first place. We don’t worry about it anymore :slight_smile:

#18

@Mark-J: This is the first time I hear about an internal bake in FBX. I have been baking all the time in Motionbuilder before exporting to FBX.

#19

FBXExportBakeComplexAnimation -v true;

It’s also in the UI options in the Animation dropdown. Forces the output to sample per frame on the given nodes rather than taking the connected anim data. It’s basically running a bake for you but without too much of an overhead.

#20

Am I correct that this command is not documented?