Dont Maya and Houdini and also Vue use Python?
see here
I think someone needs to put a little muscle in this request.
Is there a possibility of legal action being taken? Arent certain companies in this industry becoming
unfair monopolies?
The way I see it, there are 4 options:
- petition, write, call Autodesk to change the FBX policy
- petition, write, call the sites that sell assets to use more open file standards, and/or take your business elsewhere.
- find a coder who is fluent in legal-ese who can write a kosher importer
- Find a middle-man app to convert it.
Some of these are difficult, but you can’t put the blame or responsibility on Blender.
The problem is that this huge hole is never identified or seen as a problem because of the Open Movie financing methodology.
It’s only January and this is already in the running for the biggest wtf statement of the year, congrats.
Yeah right, demanding a US corporation… sounds nice 
(I just pictured an autodesk representative going LMFAO so hard…)
Anyways, you can’t demand them “For allowing an unfair monopoly”. The only application that can’t use the SDK is Blender, due to it’s open source nature, and restrictions Autodesk put in the SDK. Blender Foundation can be demanded back for “unfair competition” since they are offering a software that does many things they do for free. (A sin in the US, By the way).
Also, it doesn’t exists that monopoly you mention. There’s still C4D, Lightwave, Modo, Zbrush, solidthinking and others.
Of course is possible to use the SDK in a way that you can’t be sued neither by Autodesk, and neither by the FSF, and is the same method that was used to allow Blender to use files in DWG format in the 2.4x series: Use another application.
Autodesk offers converters for OBJ, DXF, DAE and 3DS to FBX and viceversa. What you need is to choose one of these and make sure is fully supported on Blender, code a python wrapper that makes system calls (so no linking methods is used) to the corresponding converter, and that is. To export, make Blender export internally to the better supported format, then do a call like “convertor -from $file.any -to $my_file.fbx”, put the file where you specified and you’re set. The inverse process to import. Of course you also need to pray, so Autodesk doesn’t include a statementin their license that forbids to do so.
Sure is a hack of quite monumental size, But i think you can thank Autodesk for that. After all, is their SDK, their format, their rules.
Good luck finding a developer willing to do it.
The only application that can’t use the SDK is Blender
Or meshlab and wings3D. And AD 123D apparently can’t deal with fbx: http://forum.123dapp.com/123d/topics/why_no_fbx_import?from_gsfn=true I was pretty surprised meshlab couldn’t. I could have sworn cekuh… cekhune… Claas posted an online file conversion service a while back.
You’re right… i forgot about wings… Quite looooong time since i used it anyways…
I don’t know very much about all this, but I am curious as to how Blender can have an FBX exporter but not an importer. Wouldn’t the same licensing rules apply for an exporter (which we have)?
AFAIK fbx files created by Blender uses the FBX ascii format (human readable).
AFAIK, the problem is with FBX binary format. Also Autodesk doesn’t publish any specifications to the format, so i assume it was reverse engineered. Hard thing to do, since, AFAIK FBX changes everytime autodesk releases newer versions of it’s software.
I don’t think it is a question of BF being stupid – and I never said that. I think it is a question of BF being unreasonably dogmatic. In other words, I think it is a question of “What do we really want Blender to be?”
I’m not sure why the License should be a deal breaker. Why can’t it be provided as an add-on? I didn’t see anything in the license that gave Autodesk any rights over Blender if their SDK is used as an optional add-on. True, the add-on would not be open source. But that seems to be a decision the user could make before installing it.
The only section in the license I saw that even pertained to Open Source was this:
2.1.4 Use of Open Source Software by Licensee. If Licensee uses any third party software (including free or Open Source Software), whether or not in conjunction with the Software, Licensee shall ensure that its use does not: (i) create, or purport to create, obligations of Autodesk or any of its affiliates with respect to the Software; (ii) grant, or purport to grant, to any third party any rights to or immunities under Autodesk’s or any of its affiliates intellectual property rights; or (iii) cause the Software to be subject to any licensing terms other than those set forth in this Agreement.
How does that poison Blender? I’m not an attorney, but it seems to me that it is simply saying: “If you use this in Open Source, fine, but it doesn’t obligate us in any way to support it, or make our stuff Open Source.”
And because of that, we can’t have FBX import?
I don’t get that.
The problem resides with the distribution terms of the software using the SDK. GPL says on thing, but the SDK license clashes with it.
Is not a dogmatic thing, is a LEGAL one. Considering this, is a probably that at least Ton contacted a lawyer regarding the situation, and thus, there is a response written by Ton himself, located in the wiki…
http://wiki.blender.org/index.php/User:Ton/Autodesk_FBX_EULA
… IMHO pretty hairy thing. The SDK license is long and is quite easy to get lost in it. But after all, is the typical autodesk license.
I use Blender alongside my main app C4D and would love to see even a basic fbx importer. Getting animation into Blender is usually a chore so I usually only import geo and animated cams.
Unfortunately due to the stranglehold Autodesk has on the industry I don’t see the SDK restrictions being lifted…ever. A pity that Kaydara was assimilated into the Autoborg, since they were a very cool and innovative company (as well as Softimage). Getting the FBX format , which was originally a more open format, was Autodesk’s main goal in acquiring Kaydara, getting Motionbuilder merely being a bonus.
In light of Ton’s recent tweet about the possible removal of Collada from trunk, there is danger of Blender becoming an island:
http://lists.blender.org/pipermail/bf-committers/2012-January/035006.html
At the very least I would really like to see the mdd modifier added to trunk. Then animation import via obj/mdd is at least viable. Wouldn’t want to do a whole scene that way, you would need something more like a blender version of point oven for that. In the long term maybe Alembic will be the solution?
Hmm, no collada and no fbx means that blender WOULD become largely an island. Ugh. There’s gotta be a way to support fbx. I still don’t understand why it can’t just be a separate add-on. It would be separate from blender and therefore legal, yes?
mfoxdogg said earlier the community can make one they just can’t distribute it with Blender or the FBX SDK. So unless I completely misunderstood - If someone made an add-on and put it up on Google Code or whatever and required you to download the FBX SDK from Autodesk to use I don’t think it’d violate anything. Blender itself just can’t ship with that functionality out of the box. Just to reiterate, I may be completely wrong - I’m just going with what I understand from the thread. 
Bingo.
This very idea has been discussed(or at the very least, mentioned by ideasman) before, but nobody really seemed to actually bother doing that
Not to the same extent as Blender and certainly not for import/export.
To do an importer/exporter that works as an addon, you’d have to first create a wrapper for the entire library (in C++) that adds necessary Python hooks. Only after that would you be able to write an import/export add-on. It’s a ridiculously large task for something that can never be officially supported by Blender (and probably not Autodesk either, if I read correctly).
WHY do we have to dump collada?
Its not working - true.
BUT , open collada models import beautifully – with the RIG AND ANIMATION !!
try it.
How much to write it for an average programmer who could do it you estimate? { Theres a lot of commercial companies
who could help fund it, through purchasing a copy }
if blender dumps collada they will lose a lot of people who use blender for modding games…
It’s not just writing it. It would also have to be maintained to keep up with any arbitrary changes that Autodesk makes to the format… as well as changes that happen on the Blender side of the fence. Doing a real estimate of the cost to do all of this is more involved than I currently have time for… and as I don’t currently have a pressing need for FBX support, it’s harder to justify allocating that time (even to draft a proper estimate).
That said, if there are these commercial companies with with the need for such an importer/exporter and have the funds to pay for it, it’s probably worth asking why they haven’t developed it themselves or spearheaded such a development effort. It’s likely that you’ll find that either they don’t have the funds or their pipeline is built in such a way that they don’t need the importer/exporter.
But Blender could always stay a couple of revs back on the Autodesk changes. To this day, you can still export older versions of FBX within the Autodesk suite – they have to maintain some level of backwards compatibility for their users who aren’t on maintenance.
The thing is, for someone to try to pick up Blender AND the Autodesk SDK and write an import routine would be extremely difficult. Although it is work no matter who does it, the amount of work it would take a current Blender developer to do it would be significantly less than some newbie from the community who tries to do it with no understanding of either side.
It seems to me that someone could take a look at the Autodesk SDK and write Blender’s side of things and stub-out the library calls for the Autodesk side. With that template in place, it becomes MUCH more conceivable that someone from the community could finish the task.
I do this all of the time at work. Not in the exact circumstance, but we write high level libraries with stubs so we can swap out different GUI libraries, or backend database components all of the time. I’ve never dealt with graphics data files, but I have done a lot of other integration work.
Why can’t an import/export framework be built that is a jumping off point for ALL of the imports – Collada, FBX, MDD, everything…? I might be overly naive, but how different is importing an FBX file and a Collada file? At some level, I would think the process must be very similar.