From BlenderWiki

GSoC 2012 - FBX Importer Proposal

Name

Alexander Gessler

Email / IRC / WWW

Email: here

IRC: Aramis_acg (present on #blendercoders)

webpage/blog: www.greentoken.de

My forum nickname is usually either acgessler or Aramis (sometimes with a suffix).

Synopsis

FBX is a powerful file format most commonly used to interchange data between Autodesk (tm) products. With its highly-developed pipeline it offers a very efficient way of dealing with scene data, unfortunately, being proprietary to Autodesk and by design accessible only by a SDK, support in the Open Source world is rare.

Open Asset Import Library (short name: assimp) is a general-purpose 3D model import library that reads around 30+ file formats and converts them into a unified data structure. Assimp does not support FBX yet.

My proposal is to implement a FBX importer in Assimp and an Assimp importer for Blender. The goal is to give Blender FBX import while offering a solution to the problem of maintenance. Aside, this will give Blender access to all formats that Assimp supports now and in future.

Having FBX support in Blender will allow artists to roundtrip their work between Blender, Maya, Unity, Google Sketchup, MotionBuilder and other standard industry tools as well as their own applications. The result is thus a better integration of Blender with the non-OSS world.

Having open FBX importer code in Assimp will benefit many other OSS projects as well. In fact, all Assimp users will get FBX support with no further work and in return help maintaining it.

Deliverables

In the end, Blender will offer an FBX import option alongside the FBX exporter. There will be no changes to the existing importer workflow, FBX importer will be 'just' another menu item, requiring as little user input as possible.

Assimp will support reading FBX and also provide appropriate test coverage for the format.

A wiki page will provide user-level documentation as well as a thorough listing of the supported FBX features and how this may affect exchange with other software.

Project Details

FBX is a 3D format that is developed by Autodesk and used for data exchange between their products. The Autodesk FBX SDK is the "official" way to read and write FBX files.

From an outside point of view, there are different FBX flavours matching the release series of Autodesk products (2006, 2009 - 2012).

The actual differences between these versions are rather minor (but potentially tedious: devil in the details). Internally, the file format is defined by a major version number and a flexible sub-versioning scheme for all data structures contained therein. The highest number of structural changes can be found between major version 6 (pre 2011) and 7 (2011).

There are also two different encodings for FBX files:

ASCII
Binary

(both of which contain the same information and use the same data format).

As of now (Blender 2.62), there is a FBX exporter included with Blender. The aim of this proposal is to implement a FBX importer using Assimp, matching the feature sets of import/export to enable a seamless roundtrip in between.

Having Assimp in Blender means that Blender gets easy access to all formats supported by Assimp, half of which are already supported by Blender. The only thing that would need to be done is to expose them to the user.

However, this will NOT be part of my GSoC project, I'll focus on getting FBX into Assimp and Assimp into Blender, more integration work could be done later on. In a long term view it would certainly be desirable to offer Assimp's full range of importers.

In the following sections I will outline the scope of the project.

"Which" FBX?

Since users can easily convert their FBX files between different format versions using Autodesks FBX Converter, there is no need to directly support all format versions from the beginning on (even though it would certainly be desirable in a long term view). My initial focus will be to support ASCII files in 6.1 format, which is the same format as Blender's current FBX exporter writes.

Feature Set

I started a BA.org thread to find out what potential users would need. As it turns out, there are clear overlaps between the individual requirements. The emphasis must lie on getting these core features stable, rather than trying to implement as much as possible.

The following list represents the feature set in the order in which I think it should be implemented (i.e. with decreasing priority).

the must-have core is solid geometry with basic materials, that is: mesh, scene hierarchy, multiple UVs, basic materials cameras and lights with rendering settings animations, this includes: fcurves, keyframing, skinning weights, bone hierarchy / bind pose mesh modifiers The current export already handles most of these points.

Architecture

The core FBX importer will be implemented in C++ as part of Assimp. Assimp implements a generic interchange data structure ("aiScene") with relatively fixed semantics. Internally, all assimp importers output a slightly different, more diverse representation but Assimp implements a configurable pipeline to unify the differences and to return a stable data structure to the caller.

Blender, on the other side, will need to

embed assimp (see below)
implement a converter for Assimp's data structure.

To embed Assimp, there are basically two options

use Assimp's C (or C++, it has both) interface directly. This means assimp would become a direct dependency of Blender and my main work within Blender would be done in C or C++ (similar to Blender's use of OpenCollada). use Assimp via Python. This has the disadvantage that Assimp's Python bindings are not complete (i.e. they don't cover the entire feature set), so I would need to invest time to update them. Also, this will inevitably be slower (if this is a concern) and bridging between C/C++ and Python twice is much more error-prone. Personally, I prefer the first route. The Assimp-to-Blender converter could then be written in C or C++ and offered in the Blender Python API. This has three advantages:

I can write the frontend (UI) for the FBX importer in Python. easy to add importers for formats that Assimp supports but Blender doesn't. Just add another Python importer that invokes assimp. easy for existing importers to support assimp as fallback/option. Again, the two latter points are not part of my to do list for this proposal, but I want to leave these open for future work.

Assimp Limitations

Assimp originally aimed at real-time rendering systems (i.e. 3D engines) and its data structure is a bit specialized. This means, Assimp is not capable of capturing all information present in FBX files.

From the list above, it has 1-by-1 mappings for meshes, materials, scene hierarchy and bones/skinning so there is no problem reading "the basics".

However, Assimp stores sampled animation values instead of parametrized curves (i.e. control points but no interpolation mode). Some other FBX features (mesh modifiers, ..) also have no Assimp counterparts.

My proposal is to accept these limitations during the first work period and to use Assimp's data structure as is. Later on in the project I can extend the Assimp data structure to keep arbitrary meta-data associated with nodes in the scene. This would solve all problems at the cost of uniformity in Assimp's output (which I'm fine with).

Testing / QA

There are three things to consider:

Assimp import. Alongside Assimp we maintain a small test suite of files and we regularly do automatic regression testing against this suite. FBX will be no exception. This will cover the format basics with very little extra effort. Importer/exporter roundtrip within Blender. This is the primary focus for Blender users and also easy to verify, I intend to use a simple test suite with a runner script. Exchange with other FBX-capable software. For this I hope that potential users will help out with continuous testing during development. Appropriate FBX test cases will surely be provided by the community (and there are plenty of resources available anyway).

Maintenance

The FBX importer logic willl be completely within Assimp and the Assimp team and users will be maintaining it. The amount of new code for Blender will be kept at minimum, thus reducing maintenance work.

FBX bug reports from other sources as well as from Blender users can be centralized in Assimp.

Project Schedule

Much of the "milestoning" is already contained in the feature set and format discussion above, this is just to put things together. The dates are roughly matched against GSoC's timeline.

• 2-3 Weeks (May-Early June)

Assimp importer for Blender. Since I've already done the opposite way (Blender to Assimp), I don't expect too many problems here.

• 5-7 Weeks (June)

Importer core within Assimp supporting the feature subset outline above. I expect animations to be the trickiest and most time-consuming part of this.

• 1 Week (Early July/Midterm)

FBX importer frontend in Blender. Setup a test suite to verify the importer/exporter roundtrip with Blender.

• 2 Weeks (Midterm/Late July)

Solve Assimp limitations with regard to animations and mesh modifiers.

• 1 Week (Early August)

Binary FBX reading, support sub-versions, maybe 7.n format.

• 1-2 Weeks (August)

Documentation, further test iterations together with community.

• If any time left: implement more features :-)

My personal summer plans: I do have some exams scattered across the summer and I won't be available August 16-18th. I haven't planned other vacations yet, but at maximum I will be away for a week (which does not necessarily mean that I could not code during this time ...)

Being new to Blender development, I will need some time to get into it, but considering that I am not unexperienced writing importer code, I hope to get started quickly should I get accepted (i.e. early in May).

Bio

I'm a first year undergraduate at Stuttgart University studying Computer Science. I've been programming for around 5 years (to be honest, I don't know when exactly I started). I tried various things, but having some kind of natural bias for aesthetically pleasing imaginery I ended up doing graphics/3D programming most of the time. I started four different 3D engines, each of which taught me a lot, but was quickly superseeded by the next one (for exactly this reason). Originally I used C++ with DirectX, but later switched to thin layers of C++ with Python as scripting language and OpenGl as my graphics API and, even later, to JavaScript with WebGl.

In 2008 I started working on Open Asset Import Library together with two other guys I knew from a small graphics programming forum (www.zfx.info). I wrote many of Assimp's importers and some of its geometry processing tools (and learned a lot from mine/our mistakes on the way). Assimp includes a loader for Blender's DNA.

My experience with Blender importing/exporting is somewhat related to Assimp: Blender, with its high variety of exporters has always been of great use in making test files, converting files, etc. - also, for my engine work I used custom exporter scripts (pre 2.5, though) and also did some modelling, even though this has never been my focus.

The top reason why I'm perhaps a good candidate for this job is that I have a lot of experience writing tools for 3D data exchange. I know what's important to users and also where common pitfalls lie. I don't underestimate the amount of maintenance work required for importer code and I also won't run away given that I already maintain assimp.

Apart from all the nerdy stuff, I love reading, watching movies and I enjoy maths (somehow). I also like cats.