FBX Models

I am also thinking to use fbx format in the future.

The big pros I can see with it is that:

- many modelling programs support it (especially Autodesk softwares of course), this gives you a wide range of tools to use already and you aren't tied to one program
- programs are able to load .fbx files too
- it is been developed actively
- SDK is available with pretty good examples
- format supports binary / ASCII modes

So if you don't have much resources to use (time), I think it would be worth to use .fbx format (or another equivalent format)

Best regards!

I am also thinking to use fbx format in the future.

The big pros I can see with it is that:

- many modelling programs support it (especially Autodesk softwares of course), this gives you a wide range of tools to use already and you aren't tied to one program
- programs are able to load .fbx files too
- it is been developed actively
- SDK is available with pretty good examples
- format supports binary / ASCII modes

So if you don't have much resources to use (time), I think it would be worth to use .fbx format (or another equivalent format)

Best regards!

Hi!




Thanks for your feedback! It's really appreciated!

But I definitely do agree with you. There are massive pro's to using FBX. Just trying to see if anyone with valid hard facts to "not use it" can shine some light on the con's.

Some of the "bigger complaints" I've read is that it's not an "open" source.
OK I understand this but how many people are using PhysX? It's not exactly an "open" source either. Yet ... too many to list AAA game companies are using this bad boy.
Also they (Autodesk) mentioned that they would be making more "private" details more public in future releases of the FBX SDK. So I too agree and think this is the way I want to go.
Not only because Autodesk is supporting and keeping it updated, all their modeling packages from 3ds max, maya, motion builder, etc use FBX natively.

Recently attempted to export a Biped animated model to .x format and well lets just say it's not pretty. Thinking either way I go I'll have to spend several days 'fixing' an
issue with the .x exporter or just wrap up and create my own .fbx loader with the SDK. And well all the pros listed above seems to be the FBX format loader is the way I should be heading.

Yes, I'd like to hear some real world experiences too on the FBX SDK. Otherwise, I'll be able to tell them in few weeks

Cheers!

Hi, I've recently added FBX support to a preprocessing tool, and this is what I think.

If you only want to load models, it's decent. If you just want to load polygons, normals, etc. then you can do it pretty easily and without concerns about speed. It may take some time getting used to the SDK, but support is good and I think it's worth it.

Now the ugly part comes with the animations. In a debug build a file with a single animation can easily take more than 2 seconds*. The humanoid.fbx that comes with the SDK takes more than 8 seconds. In release it's pretty much instant (didn't time it) so it may not really be a concern. I also should mention that some malformed files caused the SDK to crash.

Now speed aside, I went into a lot of troubles because each program likes to export things... differently. Let me explain. At least in the files I used, the animation keyframes in a file exported with version 6 would contain absolute values for the translations and rotations, whereas a file exported with version 7 would contain values relative to the previous keyframe. And even worse, files from Maya have to be loaded differently than files from Max. (see here) **

I wouldn't use it directly in an engine, but that's mainly because I prefer having a private format that I can load safely.

* [size="1"]At least in my experience. Opening the file and calling Import() is what causes the big slowdown. However be advised that my implementation may be faulty and I may be loading more than I should, even if I'm setting most options to false.
** [size="1"]You can avoid this by having the SDK evaluate the complete transformation at a given time.

Using FBX is not bad, but it could be slow. There could be two performance issues:
1. reading and parsing text based formats is slower than its binary counterparts. This might not be an issue with lowpoly models, but what happens when you need to read a scene of a few 100k polygons, lot of animation data etc. ?
2. Postprocessing:
Eventually you need to transform your model data into some binary form you want to use in your renderer/physics engine. To do so you often want to "optimize" it for your engine, i.e. removing duplicated vertices, smoothing normals, adding metainformations etc. FBX or collada are model formats, written for modelling tools and not with performance or special rendering engines in mind. At first this might not be an issue, but later in development you want to add more features/optimizing which adds to the postprocessing stack resulting in a potential performance issue.

Loading time is often a point of annoyance and it will sum up (reading audio,texture,model, script loading and compiling, shader compiling etc). Even when you don't see the impact of 2s to 10s as problematic, it is a 80% performance save you will eventually need to decrease loading time to be acceptable.

My sugguestion is to write a FBX-to-your-game "compiler". This could be integrated into your engine first:

read FBX ==compile==> binary ==readFromMemory==>interal data

Later on you could implement it as stand-alone compiler/converter:

compile: read FBX ==compile==> binary ==> write to disk
game: readFromDisk==>interal data


I've heard countless comments of "it's slow" "it's not meant for that" etc. Can anyone point out why it's "slow" for loading or "not meant for use
in a 3d game engine" over say .x format?
You can save FBX as ASCII and look at the contents in notepad which don't look any more "complex" than .x. (yet no "don't use .x!!!")

Another question I have is XNA uses FBX, Unity has a default FBX importer built in (so you can just drop fbx models into unity and they'll work properly). Maybe
I'm just misinformed .. Also browsing through some top games game content packs (the model viewers) e.g. for. WOW or TorchLight I see it's littered with FBX models.
So uh ... these games are actually saving the FBX model to disc, loading them and then saving them again in another format? That doesn't sound very "AAA" company like ..(?)

Performance is relative. Something that's fast for someone can mean slow for someone else.

FBX stored in ascii format, (just like .x can be ascii or .obj can be ascii) has the advantage that it is easy to parse (== easy'ish to write a loader for, and can be debugged/modified using notepad to some extent), but for runtime loading purposes, ascii formats are suboptimal compared to binary formats.

A good development file format can be different than a good end-use release file format. At development time, it is useful if you can load files of any types. For Unity and other middleware, it is advantageous to have loaders for about everything, so that the user has the flexibility to produce content in whatever format their CAD packages can provide. In Unity, for the shipped release version, the input files are run through a content builder, which packages the data to a format that is optimized for loading into Unity mesh buffers.

To get an optimal performance format, the usual simple mechanism is to generate a file format that is just a dump of the raw data you feed to your internal Mesh/Texture/Shader/... data structures. To load these binary files, you don't do much else than a single fread() to stream in the header, followed by a fread() to read in the actual per-vertex data, and that's it. Because this method will not involve any kind of per-element parsing (e.g. ascii->binary) and is not filled with small-sized file loads (e.g. fscanf to get individual lines at a time), loading is an order-of-magnitude faster.

Binary formats do have their drawbacks, e.g. supporting multiple versions can be more difficult than with ascii data.

Someone mentioned 0.2s loading times for .fbx meshes. If that sounds adequate, then it probably is. If you're looking to stream in meshes at runtime, that's most likely not enough (0.2s == 12.5 application frames if running at 60Hz).

For FBX, I'll restate these two comments from the previous posts:

"Some of the "bigger complaints" I've read is that it's not an "open" source."
"I also should mention that some malformed files caused the SDK to crash."

This can be a huge deal for some cases, or depending on your game, it might not mean a thing.

First off awesome responses so far thank you everyone !

Performance is relative. Something that's fast for someone can mean slow for someone else.

FBX stored in ascii format, (just like .x can be ascii or .obj can be ascii) has the advantage that it is easy to parse (== easy'ish to write a loader for, and can be debugged/modified using notepad to some extent), but for runtime loading purposes, ascii formats are suboptimal compared to binary formats.

Understood. But I was just pointing out when exported into ascii to view the contents it's not much different than .x in ascii. You can export FBX into binary

To get an optimal performance format, the usual simple mechanism is to generate a file format that is just a dump of the raw data you feed to your internal Mesh/Texture/Shader/... data structures. To load these binary files, you don't do much else than a single fread() to stream in the header, followed by a fread() to read in the actual per-vertex data, and that's it. Because this method will not involve any kind of per-element parsing (e.g. ascii->binary) and is not filled with small-sized file loads (e.g. fscanf to get individual lines at a time), loading is an order-of-magnitude faster.
[/quote]
Awesome! I've wondered what magic was going on for such "per engine custom formats" hah nothing more than a simplistic read header read info based on header settings! Here I was fathoming some huge magical dragon .. haha.

Someone mentioned 0.2s loading times for .fbx meshes. If that sounds adequate, then it probably is. If you're looking to stream in meshes at runtime, that's most likely not enough (0.2s == 12.5 application frames if running at 60Hz).
[/quote]
Agreed and understood, but my comment about the load of less than 0.2s was refering to ascii and debug release. I'm sure it'll be much quicker in a release build and binary format however your point is heard, some more food for thought for me. Thank you.