Writing a Book, Need Fact-Checking

[Anonymous]

I am writing a book for Addison-Wesley Professional on advanced game architecture for iOS with a heavy focus on optimizations for 3D graphics and the engine pipeline.

The book will focus on 3D and I want to provide some reference chapters at the end that explain how to build a custom 3D file format by converting from either COLLADA or FBX.

For each file format I plan to list the pros and cons.

I want to fact-check my cons for the FBX SDK.


There are basically 2 major cons that I intend to mention.

#1: The new releases of the SDK often break old code. This is an extremely serious issue. In fact, understandably, I can’t put code into the book that is virtually guaranteed not to compile 6 months later.
Where does Autodesk® stand on the policy for future versions of the SDK?
Are future releases going to require heavy code changes on our end if we want to keep our converters up-to-date, or has Autodesk® finally finally finally decided to enforce a reasonable backwards-compatibility policy?

My book proposal had very good reviews and targets an audience that has never been targeted before, and in fact one of them asked what the FBX SDK is. This is a good chance for FBX to gain popularity and spread to a large audience that has never used it before, but I can’t put code in the book that will quickly be outdated and uncompilable.


#2: There is no ability to embed custom data, unlike COLLADA.
I intend to provide light-weight physically based shaders in a topic that covers the basic shaders suitable for next-generation graphics.
FBX SDK has no means of supporting the parameters for common physically based models such as Oren-Nayar, correct?
Is this something that is planned for the future? This is the last generation in which games without physically based shading will exist, so I can’t imagine that Autodesk® has no plans to add these types of materials.

That being said, I will show in my book how to create correct parameters for Oren-Nayar based of the standard Phong specular power, and the same power (without conversion) can be used in the physically based Blinn-Phong I plan to present, so I will be able to downplay this disadvantage as far as that goes, but to be unable to later support Ashikhmin-Shirley or Cook-Torrance will still be a con for the FBX SDK.


Can anyone from Autodesk® give me an idea about Autodesk®’s plans for these 2 points?
Perhaps neither are valid concerns if Autodesk® has plans for both of these problems.


Any information on these 2 points I could present in my book, especially positive information that downplays the severity of these cons, would be appreciated.


L. Spiro

[RobertGoulet]

Hi L. Spiro,

for #1, this is because the FBX SDK is a very old library, and it needed to be cleaned and updated. The most significant push we've done toward this was in the 2013 version serie. While we are mostly done with API refactoring, this can still happen in the future as we are finishing to polish the API. Most of the time, we remove or just rename functionality. I would expect the FBX SDK API to become more and more stable in the future, thus gradually reducing the chance of breaking old code.

#2 It is totally possible to embed any kind of data in FBX files. Some of them are directly implemented in the API, such as textures, but others can be done via "blob" properties which can contain any arbitrary binary data. As for shaders, we do have classes to import/export them, look for FbxBindingTable, FbxImplementation, FbxSemanticEntryView, etc.

[Anonymous]

If Autodesk allowed it, you could ship the version of the FBX SDK in your distribution. That way you would be certain that your code would compile and run properly.

[Anonymous]

Why even include FBX or Collada? Why not write your own optimized file format exporter,
exported straight from the 3D modelling package, like Maya or 3dsmax?

An exporter based on scripting commands won't break for a long time.
Nor does it need to be recompiled with a SDK.

[Anonymous]

pakiman, I want to be lame and tell you to just read the book, but I will explain basically what the book will explain.

Making an exporter for 3D Studio Max or Maya directly is only an option for either major middleware vendors or studios with in-house engines.

The reason is fairly obvious. An individual making an exporter for either tool is an obvious waste of time. Next version of Maya means you have to rebuild, relink, and sometimes modify your tool. And you have to keep up-to-date not only with Maya but with 3D Studio Max, LightWave, etc., for each new version they create.

If you are a middleware studio with a budget that is fine.
If you are like my game company where the only engine we use is our in-house one (http://www.youtube.com/watch?v=6cuXgRVMvZ0 (this is real-time on a PlayStation 3)) then you can enforce that your workers use only Maya, and then it makes sense to make Maya plug-ins directly.

But this is not the target audience of my book.
The target audience is individuals who want to progress with their 3D game engines beyond what existing books detail.
For indies, nothing else makes sense but to use exchange formats such as FBX or COLLADA, and this also reaches the largest target audience for my book. If I showed how to make a plug-in for Maya I would obligated to show how to make the same thing for 3D Studio Max, LightWave, Blender, etc., and that is just not reasonable.


Basically, read the book. It explains it all.


L. Spiro

[RobertGoulet]

It is possible, but the permission must be given from Autodesk.

[Anonymous]

How would I go about getting such permission? It would be helpful to be able to provide something that is guaranteed to allow my book’s code to compile in the future.


L. Spiro

[RobertGoulet]

I will check with the legal department internally. Please contact me by email for the follow-up.

[Anonymous]

I would like some clarification on this point: “It is totally possible to embed any kind of data in FBX files.”
This means opening a .FBX file for read/write and using the SDK to add data to it, doesn’t it? Or can this somehow be done during the export process from Maya or 3ds Max?

My book will only cover how to export from vanilla Maya or 3ds Max, load a .FBX file via the SDK, and convert to a custom format. The file will be read-only. Is the ability to embed custom data compatible with this? And if so, how?


L. Spiro

[Anonymous]

Trying to load your models in-game ( on the device ) from Fbx or Collada file is insane.
It is literally asking for minute long startup times for your app on iOS.

You don't need to be a large studio to write a converter from Fbx to a custom mesh/animation format. The last thing you want is Fbx SDK evaluating animation curves in real time for a fbx file with dozens of animations and then having your code convert it to some sort of internal format ( which you will have to develop anyway.)

Why not do it ahead of time and store your data in such way that you can literally blast them from the file to VBOs without evaluating anything.

Or if you don't want to come with your own mesh/animation format , use something like Imagination Technologies POD format which is very lean and mean , binary only and loads models/animations in milliseconds.

[Anonymous]

I am not sure where you got the idea that I would be loading anything directly from FBX into the game. I said in my post just above that I am showing in my book how to make a converter from FBX to a custom format that can then be loaded by the game, basically exactly as you explained.


L. Spiro