6 replies to this topic

[Goz]

Has anyone else out there ever used FBX files? I'm finding them a REAL pain in the arse. Whatever I try and do FBX just seems to get in the way. For example I am trying to simply process a file. Alas it seems you need to use the bloody FBX library to do things such as loading but, alas, loading is currently heavily abstracted away from the engine (So that I can change the loading scheme to work from whatever system i chose, a ZIP file for example). Is the only way round this problem to add my own reader into it that wraps my reader system?

So far im THOROUGHLY unimpressed with FBX ... IT seems an overly convulouted method of doing EVERYTHING include 99% of the stuff i couldn't give an arse about :(

Any thoughts? Any good examples of how to actually use FBX in a handy way from C++ and DirectX?

I'm beginning to feel i'd be better off writing my own exporter because, so far, collada AND FBX appear to be waaaay more trouble than they are worth :(

[MarekKnows.com]

the FBX SDK comes with code examples showing how to load FBX files and display the results using OpenGL. I used these examples to build my own parser which works fine.

I suggest you start with the ImportScene example. It has everything you'll need.

[Jare]

I recommend the middle ground between loading FBX in your engine and writing your own exporter: writing a post-processor that reads the exported FBX and writes an engine-ready file with only the stuff you want, in a format that is tight and fast to read.

[Goz]

mmakrzem said:

the FBX SDK comes with code examples showing how to load FBX files and display the results using OpenGL. I used these examples to build my own parser which works fine.

I suggest you start with the ImportScene example. It has everything you'll need.

Yeah great .. but it handles all the loading internally. Not much use if you want full control over what its doing.

[Goz]

Jare said:

I recommend the middle ground between loading FBX in your engine and writing your own exporter: writing a post-processor that reads the exported FBX and writes an engine-ready file with only the stuff you want, in a format that is tight and fast to read.

TBH it took me 2 days to write an exporter for Maya ...

[MarekKnows.com]

Goz said:

Yeah great .. but it handles all the loading internally. Not much use if you want full control over what its doing.

As Jare suggested, what I did was used the SDK to load everything into memory. Then I extracted the bits and pieces that I wanted to use, and exported them into my own custom file format which is what my game engine uses. Now when I load any resources I don't have to use the SDK because everything is saved in my own format.

The only downfall is if I want to change something in the original format, I need to run it through my custom parser to make a new version of the file in my own format.

[Jare]

mmakrzem said:

The only downfall is if I want to change something in the original format, I need to run it through my custom parser to make a new version of the file in my own format.

For anything but a very small project, that is actually a benefit, because it's dead easy to set up a batch system to take care of that for you anytime a piece of art changes and is reexported, but if you want to make changes to the runtime format, you don't need to reexport everything from Maya. Even if you write your own exporter, the two-step system makes a lot of sense.