Maybe it is not important, especially after Tomato, this is very disturbing in my opinion.
On the end of 2011 I’ve asked PFHoe support about new export to Blender.
I understand company’s business policy, but… Look at this:
<b>[Re: When new Blender export?](http://www.pfhoe.com/forum/viewtopic.php?f=10&t=751#p1977)</b>
[](http://www.pfhoe.com/forum/viewtopic.php?p=1977#p1977)by <b>[daryl](http://www.pfhoe.com/forum/memberlist.php?mode=viewprofile&u=9129)</b> » Tue Mar 13, 2012 1:15 pm
Hi. We're aware that a Blender export is a popular request. <b>The problem lies with Blender being open source</b>, which makes it difficult to develop support for it. We've created tools for Blender, only to have the code broken by an update to the application, wasting time that could have been spent elsewhere. If Blender would build in support for some standardized scene formats, like FBX for example, the problem would virtually disappear.
We have no timeline for this as said previously. If and when this becomes available we’ll certainly let the PFhoe community know.
Blender was changed. It is true. But IMHO this policy is dangerous… This is message for users: Open source = troubles, use only commercial software. Maybe would be good to talk with Pixelfarm? PFHoe is not important at this moment. I’m only not important user, but maybe developers or Blender leaders?
What they say is it’s not commercially viable to develop and mantain a blender exporter. And indeed after Tomato it’s pretty much nonsensical to try to compete with a free and fully integrated solution.
The problem (in this case, at least) isn’t necessarily that Blender is open source. Yes, there’s the well-documented difficulty of supporting FBX, but the real issue here is Blender’s rapid release schedule. Commercial applications simply don’t do releases nearly as often as Blender and it’s asking quite a lot for them to keep up with maintaining support on such a fast-moving target… particularly for such an indeterminate financial gain.
This has nothing to do with being Open Source or not.
It isn’t the Open Source nature of anything that causes problems (if anything, the opposite is true).
This is just a problem that every program has when they try to support other 3rd party applications,
if a program changes, they need to update their exporters as well. And that requires some work to monitor every change and maintain the exporter.
But since .blend is the default format for Blender and this format is OPEN SOURCE it is very easy to actually provide support for this.
There where proprietary formats might cause problems, because they are proprietary not everyone is allowed to use those or develop support for them.
This is with open Source never a problem.
Blender offers enough to work with, Blender is Open Source so easy to support, what hooks does PFHoe offer for Open Source?
To me it sounds like a bad excuse to leave out anything that is Open Source, which says enough,… right?
But they can offer the hooks required for Blender,… it is Open Source after all,
and they do not need to change their program if they implement what they need in Blender…
Do you know of any app except Houdini that supports .hipnc?
Do you know of any app except Maya that supports .mb?
Even between these two industrial monsters, import/export is a segfault adventure. Why on earth would one application support the native filetype of another? That’s what things like FBX, OBJ, and alembic are for. If you ask me, Blender just needs to support these and other intermediary filetypes. PFHoe can help by investing some cash and/or manpower. Let the burden of updating fall on Blender, however, since we need these kinds of filetypes supported anyway.
[Edit] I can see that this would be an issue if the intermediary types are not opensource. But it’s not Blender’s issue.
As far as I know, the FBX format has some licensing incompatible to the GPL which prevents Blender from having a full implementation. The FBX format is owned by Autodesk which historically hasn’t been receptive to the Open Source paradigm.
The fact is that there’s nothing the institute can do unless there was a way to change the licensing of Blender, which would be nearly impossible considering the Free Software Foundation’s specifications on what must be done to change it. The GPL has also been friendly to Blender as it makes it illegal for commercial software companies to use Blender code in their products, though it has created headaches for those who need something but can’t because of the choice to choose the GPL as a license since Blender was first open sourced.
The best thing to do in your case would be for Blender to adopt the latest in open standard formats like the EXR and Alembic formats, otherwise there’s nothing the developers can do. Otherwise you might want to direct your concerns toward the creators of the GPL, which is the Free Software Foundation itself.
Blender’s GNU GPL license is sometimes considered restrictive, since we can’t link to or include non-GPL-compliant software. Many users would love to see Blender get a good FBX import working, for which Autodesk released an SDK (closed library for linking, not open source).
Apart from restrictions on the GNU GPL side, there’s a really big restriction in the Autodesk FBX SDK license as well.
FBX SDK EULA, Full text, rtf
Apart from the enormous long texts claiming excessive limitations and Autodesk exclusive rights on the SDK itself (similar to Maya etc), there’s only 1 point really describing what your rights are:
1.1.3 (you can) reproduce, distribute and sublicense free of charge or for a fee Licensee Product(s) provided that Licensee must sublicense the Software, the Developed Software, the Library, the Sample Code(s) and the Modified Code(s) “as is”, without warranty of any kind. Various License Types are described in Exhibit B. In any case where the License Identification does not specify a License Type or Permitted Number, or there is no License Identification, the License Type will, by default, be the Evaluation License and the Permitted Number will, by default, be one (1).
Exhibit B describes only licenses similar to how Autodesk releases software. These are all restrictive, individual, non-transferable and non-shareable agreements. More over; the default Evaluation license expires usage after 30 days.
Even when we would add a GPL exception clause to link with the FBX SDK, the restrictions on FBX itself would still impose an unacceptable limitation on spreading Blender.
Unity3D.
Indeed there was a period when they didn’t support 2.5x .blend files, while they waited for the python api to settle. That time has passed, and now it works fine.
It has nothing to do with the fact that Blender is open source. Also, as noted already in this thread, this happens between commercial apps as well. I remember that for about 10 years 3dmax couldn’t accept adobe illustrator files if they were any later than version 8 (from 1998!).
Really this is just an excuse on the part of PFHoe, reflecting the attitude you quite often find at the lower end of the industry; open source is to be discouraged. It’s a shame, but it’s their loss.
Blender already supports Collada, it is meant to solve these issues.
Everyone supports one standard which is open for everyone to use.
You can’t demand or expect any application to support 3rd party native proprietary formats.
That is why .blend is so easy to adapt to,… yes it is, compared to closed alternatives.
But also it is relative easy to submit/commit the required changes to the Blender Trunk for support of any 3rd party format.
They don’t seem to understand the basics of Open Source and what it can do for them.
They have paying customers, if their paying customers request functionality,… hey it is where they pay for… isn’t it?
What do they offer for Blender to support the formats in demand?
If i remember correctly, Alembic was mostly for just geometry, to store it in a compact fashion for a renderer to use.
The real universal format is supposed to be COLLADA, but it’s so broadly defined that it’s not standardized properly that usage across applications is poor. I’m hoping that changes in the future…
I think Unity still relies on the fbx exporter in blender according to their current documentation. When you place your .blend file in the asset folder its imported under the hood using the fbx exporter of Blender
the inspector also seems to say fbx import if IIRC.
True, true. However, from the user’s perspective, Unity accepts a .blend file.
I must admit I don’t know of any commercial app that natively supports .blend, but then I don’t know of any other apps that natively support .mb or .max either.
I think the problem itself is more a common symptom of open-source development, not a general feature of it.
Blender shows complete disregard for authors of external scripts/addons. Not a release seems to go by without changes being introduced that break some stuff, and as a commercial developer you really can’t put up with that crap for long. This may have been justified during the beta phase between 2.5 and 2.6, but now this is simply unacceptable, and it is still happening. And even if things improve on that front, blender now simply has a reputation of being a moving target to develop for. (just as people still believe java is slow)
