[Bf-committers] Importing Assets: FBX VS Collada

Toni Alatalo toni at playsign.net
Mon Apr 28 08:29:18 CEST 2014

@Chad yes that is possible, it was discussed on IRC the other day and
Ton dismissed (I think sanely) due to it being too difficult for
people to install the separate converter (for FBX for example) due to
the licenses preventing the distribution of the FBX SDK together with

@Stefano seems to be making a strong case in my view. Also because the
current Collada support has worked fine for us so far (game related
exports, sometimes imports - we even once used it to bring Blender
2.4x scenes to 2.5 for some blends that otherwise just crashed on

I took a look at the Collada <-> FBX converter. Works fine as
expected, installed it more to check the license. I think it talked
about 'single install' etc. and am guessing it prevents distribution.
Have no idea for real though, IANAL. But is it really that bad that
someone who works professionally on game content has to install one
app? If Blender converters can then automated calling it etc.

Also with Ogre that has been the case: the Blender exporter just
outputs Ogre XML and then the separate OgreXMLConverter (by Ogre
folks) is called automatically by the blender2ogre add-on -- but the
user has had to install the converter (a native cmdline app) manually.
Is ofc not as nice as direct export but certainly has not blocked the
use, I haven't heard complaints even.

BTW does the FBX SDK license really prevent distribution? Ah
apparently Ton has clarified this back in 2011 already:
http://wiki.blender.org/index.php/User:Ton/Autodesk_FBX_EULA . If I
understand that correctly, distributing the FBX SDK with Blender would
mean that we'd have to deny people from redistributing Blender etc.
which is just not possible (not compatible with any free software or
open source license, impossible for linux distros where apps come from
dist repos etc). I wonder if Autodesk could relax that single point,
just allow the distribution of the closed SDK binary. Am not holding
my breath :)

BTW SecondLife uses this tech of piping with a separate process to
distribute the whole of (L)GPL 3d app code (slviewer) + closed binary
for the proprietary voice impl (SLVoice.exe using Vivox). That would
be exactly like Blender shipping with and using FBX SDK. Folks have
also written an open source SLVoice.exe replacement using Mumble then
so the idea of free software indeed remains intact in those cases --
the inter-process protocol is open for anyone to implement how they
wish. So technically and regarding the GPL it is all fine, only the
Autodesk license prevents it (according to Ton's summary).

Again, @Stefano's points seem strong to me and using FBX via Collada &
the converter would probably be fine for me. And with some luck
calling the converter can be automated like with Ogre's export. I
think the converter is freeware, no limited time evaluation licenses
or something like which Ton refers to regarding the FBX SDK. But my
view doesn't weight anything in this, I don't even need FBX at the
moment and am not familiar with the deep issues, will just go back to
happily using three.js and Collada (import when get models from web
collections as dae, export for glTF conversions) now..

I guess folks who use FBX can test this easily: if you bring your FBX
to/from Blender via that converter & the current Collada support, do
the things you need work?


On Mon, Apr 28, 2014 at 5:03 AM, Chad Fraleigh <chadf at triularity.org> wrote:
> Just curious..
> Would it not be possible to include a generic sub-process/pipe
> import/export feature in blender. This would allow an external utility to
> be run (transparent to the user, once install) which would be given the
> filename (and/or sent the data via the stdio pipe) and in return it would
> send a .blend formatted file (or sub-set of) back. Then it would be
> processed like a file append. Exporting would be similar, only with
> reversed data along the pipe.
> After that, create a separate add-on [sub-]project with code that uses the
> FBX SDK with a compatible license, which users could install if needed. It
> would also allow other formats to better supported if license incompatible
> native libraries exist for them.
> -Chad
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list