@m9105826 - could you report a bug? (with Blend file and FBX that worked) if another Blender-FBX exporter can handle this, I’d expect the official exporter should be able to as well.
I agree, it is a complex topic and I don’t at all intend to trivialise that. Honestly, I wouldn’t want to be the one stuck having to reverse engineer a proprietary format covering what FBX with all the complexities that involves.
That said, it is a little snippy to be telling us we’re getting “carried away unnecessarily” when the Blender Foundation chairman, lead developer, and all round big boss man when it comes to Blender Foundation paid development writes something down in the official developer meeting notes.
If this is indeed a big misunderstanding (and I agree it looks like it is), can I suggest that Ton not go making “off hand remarks” like that in the published meeting notes? They’re supposed to be a summary of current status, progress, & future direction of development effort, so when comments remarking on the desire for alternatives because it’s depressing the developers come up - it’s shouldn’t surprise anyone that said remarks get taken seriously & with the same level of gravitas as the rest of the notes.
Great power, great responsibility, and all that. Ton is head honcho, the man holding the purse strings, and the guy that basically flipped off the forums because of how we reacted to a decision made about game development related funds. It doesn’t take Sherlock Holmes to work out that flippant comments along the lines of this one are going to cause grief.
To be clear, this isn’t an export problem, it’s an import problem. The character and rig are from SI, and it’s based on using null objects (empties) as joints. In Blender, all it does is import the empties, and it doesn’t even import half of them in the right place, preventing me from writing a simple script to just add bones in the right places.
I’ll add a bug report though.
Nobody proposed this, likely its a comment from Ton,
after listening to devs complain about full FBX support being difficult.
Thanks for clarify it for us. See that when BF gave up COLLADA that started just like that: “is too difficult to maintain… let’s find a alternative… etc”, i really really hope FBX is not going to the same path. It would be a disaster for Blender as a Tool for game development.
I only say this because “looking for an alternative” is being interpreted as “dropping FBX support”, then discussing the consequences, angry users… companies… etc - that is getting carried away, if you seriously worry about this - mail bf-developers list replying to meeting minutes and ask for clarification.
How many times have I mentioned the fact of that Autodesk can theoretically use their control of the .fbx format to control how well Blender can exist as part of a pipeline. I said before that Autodesk isn’t real open to Blender even being relevant in their target markets and now we’re seeing efforts on their part to ensure that Blender can never break out of ‘walled garden’ status.
In a serious note on this, this is a major reason why Blender needs to get to where it can often be the sole app. in a production, this includes the BF using official resources to bolster and enhance the built-in game engine (since it’s proven to be quite difficult to reliably support any commercial solution).
The BF decided to risk Autodesk controlling the quality of their I/O functionality, Autodesk is now making their move, care to guess what the goal is?
I think people have to understand the difference between short term and long term thinking. Short term FBX is the easiest way to get assets a whole bunch of places. Long term FBX is a format dictated by Autodesk and has a license that means that Blender will have to reverse engineer every feature that Blender wants to support. It is at worth at least looking at what other options are out there that will serve Blender better in the long term.
The options are…
- Somehow put pressure on Autodesk to release FBX with a license that is compatible with Blender (good luck with that).
- Keep on battling on the reverse engineering side and always being a bit behind in what Blender can offer.
- A standard on top of Collada - the problem with collada is that it is too flexible and as such every application is pretty much able to store data in the way they see it natively and means that the decoder has to understand how each other applications data works. This makes it really difficult to make things work. What is needed is a standard representation or intermediate representation on top of what Collada already offers. This is somewhat like option 1 but probably Khronos are the people to deal with and I suspect they might be more willing to listen.
- OpenMDL - This one has something of the opposite problem in that it in that it might not be flexible enough to do everything that Blender wants to do, but it exists and is somewhere along the way of getting out there as a thing.
- Come up with our own format… Option 3 would almost certainly be easier than this, but it is possible. Just a lot of work.
I don’t think that there is any insurmountable obstacle in going with a format other than FBX. Most devs understand the problems that the format poses for Blender implementing it well, all content creation apps do support import export plugins as do the popular game engines. In fact one of the jobs at work on the top of my list is building a custom import addon for UE4 as it doesn’t support some features we need via FBX.
All he wrote was the gamedev mailing list was going to check in if there were alternative options, because FBX support is difficult. People took that and assumed the sky is falling for some reason. Personally, I saw it as a positive that there was a “long discussion on FBX I/O.”
Here is the mail on the gamedev mailing list:
Hi all,
So, as everyone probably already knows, we are struggling like Hell to
try to support FBX format in Blender. We already spent a huge amount
of energy on this, for rather mitigated results so far (to summarize,
roughly static object/mesh/material export works quite good, basic
animation too. Camera/lamp orientation handling are buggy, and armature
handling is kind of nightmare).
Now, what I propose is to add a second fbx io addon (as contrib),
clearly flagged as experimental, where we can put any
dirty/bad-tested/etc. development. The point is, I want a place where I
can do whatever I want, without considering things like ‘good code’,
‘maintainable code’, ‘readable code’, ‘stable code’, ‘non-crashing
code’, etc. - and yet get it in all and every Blender release and build,
so that anyone involved in FBX pipeline can easily test it, without
waisting time in mails pingpong and such.
Once an issue is clearly solved in bad experimental addon, we can think
to a good and nice way to implement it in good one.
I would start to put Jens’ work in this experimental version, and see
whether it enhances armature handling for artists.
In the mean time, I’ll try to go over all unfixed FBX reports I got in
past months, and establish a list of basic, simple FBX test cases I need
to try to understand those issues better. Then, I’d ask artists having
‘ref FBX applications’ to generate such files.
Please let me know if you see something wrong in here, or something to
add (and yes, I know experimental addon is dirty).
Cheers,
Bastien
I am not sure why Blender > own format (or some robust format as Alembic) > standalone converted > FBX wouldn’t work? Standalone converter can use official FBX SDK.
I was asked today why Blender doesn’t use official FBX SDK, and I know we discussed that somewhere already (ideasman42 explained it clearly), but I can’t find it 
Can someone please point me to that thread with explanation ? (maybe it’s a good idea to put that into Wiki for future references?)
Because you’d loose data which the intermediate format doesn’t support. (Alembic doesn’t support armatures for eg).
Short answer, we can use the FBX-SDK
… but there are complications both with the GPL (which we can work-around) and distributing it (see autodesks EULA - we can’t work around that if we want to include FBX support in blender.org releases, we would just require each user downloads the SDK separate), see:
http://wiki.blender.org/index.php/User:Ton/Autodesk_FBX_EULA
Ah, I didn’t know that. So basically BF would have to implement its own format to support everything FBX supports, and that would probably be larger headache than maintaining FBX ?
Pretty much.
Though we could create some format which is basically a dump of a blend file, with optionally baked animations, constraints, fcurve-modifiers, mesh-modifiers, normals etc… then an external background process can translate this into some other format (FBX, 3DS… etc) without having to replicate the logic in Blender for every constraint, modifier… etc (the main reason reading Blend files directly isn’t so useful at the moment).
(this is what I’d do if I were to use the FBX-SDK), this wouldn’t be a format exactly, just intermediate data, the user wouldn’t even have to be aware of it, functionality wise nothing has to change.
That actually sounds pretty good. And it could avoid the pitfalls of reverse-engineering fbx. What were the drawbacks that have kept this from happening?
And for the record, I would have absolutely no problem downloading the fbx-sdk and installing fbx support into blender separately from the blender.org package if that meant less of a headache for the devs and more reliable, easy-to-maintain fbx support.
Mainly that it wont work out-of-the-box for Blender users, and its a fair bit of work, FBX-IO was been good enough* so far, but if we conclude supporting it directly, this is my plan-b.
… also note - a lot of compatibility issues wont go away simply by using the SDK, though it would have the advantage of being able to load different versions of the format.
* mostly referring to exporter, which has been used quite a bit with Unity3d, importer is newer and harder to support well.
Please, let’s clarify this - exporting to FBX from Blender has no issues (and FBX produced by Blender reads fine in UE4/Unity/etc.), only importing FBX produced by MAX/Maya/etc. has a lot of issues. Correct?
http://opengex.org/
how about pushing something like that?
of course it is no alternative to fbx at the moment (so fbx import/export should still be worked on) but maybe later if enough projects start to use it.
The OpenGEX format was created because Collada, the open standard that we all hoped would provide a well-supported asset exchange format, has proven to be an unreliable mess. The most common source of problems has been the poor quality of the Collada export plugins available for software such as 3D Studio Max and Maya, and we attribute this to Collada’s over-engineered design and its mutating under-specified format.
blender isn’t the only project dissatisfied with collada and fbx.
(edit: maybe it would also make sense just as an intermediate format for a standalone FBX converter. such a converter would be cool outside of the blender community too i guess? 
)
What about a brutal image of Blender internal format (plus written specification), in XML format? With XSLT/XPath anybody could yank out the parts he is interested in, opening the road for all kind of exporters. And, if Blender could read back this dump, it would open the road to external tools which can add functionalities (awkwardly…) to Blender.
Oh, so it’s supported with an externally-developed plugin in Max and Maya. Cool.
Now it only needs support in Modo, Mari, Substance Designer, Substance Painter, 3dCoat, Softimage, Quixel, Handplane, Marmoset, Meshlab, Mudbox, Sketchup, UE4, Unity, xnormal, Cinema4d, Lightwave, Marvelous and Motionbuilder. Probably a few others too.</sarcasm>
Yeah, top-notch FBX support is really important.
Not sure what you mean by brutal image - otherwise this stuff can be decided by whoever takes on the project, tho am not convinced XML is appropriate for a 3D format, if its important we can have some XML/JSON representation.
Simpler: in addition to .blend file format, have a .blendx file format which follows the same philosophy of OpenDocument (.odt etc) files: an XML description, ZIP/GZIP/whatever-you-like compressed to save disk space. The .blendx format documented in a public domain specification. Just a file format, no pesky licenses involved.
The workflow becomes: save as .blendx, open/refresh the file in the external application, do whatever you like with it, possibly resave the modified .blendx, possibly reload the scene into Blender.
For our problem, somebody writes a blendx2fbx and an fbx2blendx converters, using non-GPL code, merrily linking Autodesk DLL and the problem is “over”.
B.t.w., this approach would also partly fix the plugin problem: people could write completely proprietary applications capabable of reading/writing .blendx files.