Using a 'Common' Intermediate file format in an art pipeline

Hey,

Does anyone have any input on using a common format type for an art pipeline, for instance fbx?

Right now, we export from max directly to our optimized game format and we’re researching exporting from max to a different format, for various reasons, and then a back end process will convert that data to the optimized game ready format.

We don’t really have the bandwith to write our own intermediate format, so we’re looking at existing technologies.

So my question is, does anyone have any experience/horror stories/directions to research on this subject. Right now were just investigating and Fbx is the front runner for a prototype, though we have briefly looked at some other formats (USD, collada…).

Thanks.

FBX is the go-to choice. It’s far from perfect but Collada is a lousy standard: overly complex and the implementations are all over the map. USD isn’t widely supported yet so you’ll have to implement it someplace – plus it’s not really about game data.

If you’re just moving geometry, OBJ is still rock solid and easy to reimplement but it’s only for static.

it’s a very good idea to decouple your output and your input - you don’t want to spend a lot of energy on managing the wierdness of a DCC tookl in your game.

If your needs are simple you can also look into a JSON based roll-your-own; it’s easy to pass between Max/Maya and something else and easy to extend. It’s also usually a big space waster so if you have old fashioned engineers who care about disk space it may be a problem.

Thanks Theodox, much appreciated.

Unfortunately we definitely need a format that can handle skinned geometries and skeletal data, hence why fbx is the front runner. Basically we want the format to wrap as much as we can for the artist, if possible, so they only deal with one file format.

One main reason were looking at a common format is, currently we have no importer for our game data, so we’re faced with writing one from our exported data format, or saving in a format that can natively be imported… again fbx checks this box.

We’re aware that we’ll need to implement our own custom data, for our needs, which fbx allows also with its sdk. However my concerns are fbx may not support some key piece of data that we require, and require heavy implementation of something.

If you, or anyone else, has any more details on fbx’s shortcomings, I’d love to hear them.

Here at Volition we made the conscious decision about 2 years ago to dump all of our custom 3ds Max -> game format compiled exporter plugins and use FBX instead. While, like Steve said, FBX is not perfect, the entire pipeline is much better for the change. We now have 0 compiled Max plugins. Moving to a new version of Max is very simple since MaxScript is always backwards compatible. We also now have the ability to move data between practically every commercial DCC app and to do some custom integrations between our bespoke world editor and DCC apps. For instance, we can now move timelined animation data between MotionBuilder and our Editor, with the ability to modify the timeline in either app. It’s very handy for our animators.

Eventually we want to be as DCC app agnostic as possible. Right now we still have to go through Max for all exports, but only because we haven’t fully implemented parsers for our custom material format in anything but Max.

Thanks Jeff.

The practicality being able to use fbx in most DCC apps is a plus we are looking to leverage, for sure. However, It’s a [pretty big] bonus feature right now, if FBX doesn’t fit our needs in general. Though having said that I know it will be one of those features that, when it’s available to you, could turn out to be hugely beneficial.

Definitely, one key for us, with our pretty limited tools team, is to reduce coder support and minimize plugin recompiles or updating scripts as much as possible, going forward. So your points are great to hear, and will be music to our tools Dev :D.

Debugging simple issues in the game format is a HUGE pain and time sink, right now, so a format anyone can open and look at, even in a standalone app, would be massive time saver across the board for us.

Sounds like fbx is getting a general thumbs up.

Great stuff.

Well - I’m working in CDProjekt RED and we’ve used to use FBX, but it failed us so we’re developing our own intermediate format. It’s also far from being perfect but it matches our needs perfectly. We have all debug tools we need and we can modify it any way we want (we i.e. can keep bitmaps along with skeletal animation in one file).

Every company has a different needs.

Thanks Kroopson. Yea, unfortunately rolling out our own format is, pretty much, ruled out for us at this point. I have worked in companies that have their own solid in house formats and it totally pays off, if you have the tools developers to manage it. Unfortunately, right now, limited manpower is directing us to an existing format.

Could you elaborate on why fbx failed for you guys? At this point we are preliminarily assessing fbx, so any information on the issues other people have run in to could really help our tools dev, who is about to put time on this.

Many thanks.