In the next major release of FBX (2013), we are planning a major change to the whole API. We are putting a lot of efforts to bring the API to a consistent level. Since the modifications are major, we wanted to let you know that your code calling FBX SDK API will most likely be broken upon upgrading to FBX SDK 2013.
What are we doing exactly?
- Renaming almost every class/structure of the FBX SDK to a consistent way.
- Moving enumerations inside classes.
- Grouping logical classes/functions together.
- Renaming file names and path names.
- Removing a lot of deprecated code.
- Exposing previously private classes.
- Unifying usage of internal classes.
- ...and many more small clean-up changes all over the place!
In this release, we will not have any deprecated calls, since this would mean the whole SDK would be deprecated. This also means a lot of functions or classes will not be available anymore, and sometimes without replacements. At some point we needed to look back and make some decisions about what the FBX SDK should offer. Decisions were mostly motivated by the fact that the FBX SDK has grown pretty large over time, and inconsistent in a way. This is ok, we’ve been working on it for almost two decades now. ;)
FBX 2013 will not be ready for a while still, we just wanted you to be aware of the upcoming major changes, and we hope to upload a build on the Beta boards eventually, thought I cannot provide any precise schedule. We are very excited with the API face-lift, and we hope you will all like the FBX SDK API rejuvenation we are working on for some time now!
If you have any questions or comments about this topic, please do not hesitate to ask below! Thank you!
Robert Goulet, FBX Dev Lead
thanks for the heads up.
To help us out with the renaming, could you ensure that typedefs for the old names are provided? e.g.
K_DEPRECATED typedef FbxNewClass KFbxOldClass;
K_DEPRECATED typedef FbxClass::NewEnum EOldEnum;
As we have previously stated, we do not intend to have any deprecated calls in this version of the FBX SDK, that would be too much work. However, we do plan to provide a compatibility header file that will typedef most of the previous classes just like you are proposing.
This will help the transition, but it will be difficult to make sure we didn’t forget to add a class or an enum to this file. I propose that once we deliver the early alpha FBX 2013 that you test it out and report any missing class, function or enum that should have been added to that compatibility header file.
I would like to ask the FBX team for something that has been asked before by other people, although I’m sure it might not be in your plans, but anyway…
The importance of memory-loading for very large projects is a must, as we run the risk of having to publish the application with all the .fbx files lumped up in a data directory, and as such, viewable by anyone with the right tools. I would like to avoid that as much as possible, so is there any possibility that you might include the option to memory-load the .fbx files onto the FBX SDK?
This would be quite a lot of help for anyone planning to release something big in the future. I hope you will give it some attention, I cannot express how much it would help me personally.
I assume that FBX SDK 2013.x will be compatible with python3.2, is that correct?
However, have you guys considered rebuilding the current release for python3.2?
There are some environments where this version of python is a natural choice
and being stuck to python3.1 due to the lack of support from FBX SDK is a little
uncomfortable, to say the least :)
For the FBX 2013.x, yes I think it would be a good thing to upgrade to Python 3.2. As for the 2012.x line, there’s another release coming down the road at the end of this summer, perhaps we can manage to fit this upgrade there, but I cannot promise anything. ;)
I’m sorry, what I am going to talk about may be not directly related to this topic, but it is very important to me . I hope you can help me . Thank you forward!
My problem is I find that memory leak occurs when I Load a .3ds file using FBXSDK 2011.3.1or 2012.1.
I have done a simple project in vs2005 to test whether memory leak occurs when loading .3ds files or .fbxs file or .obj files using FBXSDK 2011.3.1 .
The result of the test is that when loading .3ds files, memory leaks. When loading .fbx files or .obj files memory is OK.
The attachment is the test project, I hope you can help to find whether the memory leak is due to my misapplying of the FBXSDK.
Will the new FBX enable us to read AutoDesk materials. for example Revit FBX includes internal binary material description that makes it unreadable by none AutoDesk application which forces us to request users to install a Revit plugin to export formats other than FBX.
If the new version will enable us to access those materials, this will be a great plus.
The materials that are in Revit can only be used in AutoCAD, Navisworks, Showcase and 3dsMax.
There is an option on the command-line FBX Converter, called /matconvert, that will convert the objects in the original file to be Materials. However, no color or texture information will be included. The converted file will be able to have materials applied in correctly with the names of the materials that were used in the Revit file.
Will the new version support spline IK? Since it already supports IK and constraints, it would be nice to also have spline IK support so that a fairly complete character rig could be exchanged between applications.
I’m working with the FBX sdk for couple of months and so far it is extremely helpful tool.
Our project is based on Direct3D rendering engine using Left Handed coordinate system.
The conversion methods of the KFbxAxisSystem class are not working well for us and we have to overcome some issues using our own conversion matrices.
It would be nice to know if a fix for that issues is planed for the upcoming version.