Alias .FBX SDK free!

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

Cyberdigitus
Posts: 46
Joined: Tue Oct 29, 2002 3:27 pm
Location: Belgium

Alias .FBX SDK free!

Post by Cyberdigitus »

Alias, having acquired Kaydara a while ago, just made the .FBX file format originaly used in MotionBuilder but also in wide use as a general format, more accesible by lowering the sdk price from 3500$ to free...

press release

Alias FBX site

Several people including myself have expressed intereset in .fbx support for blender, and it would make blender play well with other pipelines even more. I hope this announcement will make it happen, it would be mad not to support it (and be mentioned on the Alias site :) )

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Hmm open source?

Post by bfvietnam »

This looks like a container format for interchange between media platforms.. It would probably be suitable to have support for that in blender, it would beat supporting every file format under the sun.. But with every proprietary standard for file formats and interfaces, there is some vendor-lockin pushing it from behind.. Just as Cg is favorable to NVidia, and Direct-X is favorable to Microsoft, Quicktime is favourable to Apple, is there a container format that favors open source?

One?

Somewhere?

Then, I would have to wonder if there is a way to open such "container" formats to be completely open source..

I can understand the need, being able to communicate with other packages and share information, this is not a problem for blender to support this.. The only reason this is a NEED of the users, is that
the packages they use use their own file formats and interfacing methods. For any number of reasons: ignorance of the developers about open standards, lack of open standards, to encourage purchases (*vendor lockin schemes *). The one way to test if a standard is trully open is
if its open sourced.. If it is not open sourced, its not open. Its openly defined, but its not openly controlled (by what is popular to the consumers).

But you may say so? So what, I want FBX support..

But one should look at it closely to see if its offering something unique and useful, if something better in open source can't be devised. The ultimate solution might be to have some open source library that connects with this SDK, offers this service but also offers a number of other interface standards, using a library that unifies everything under a open source, open standard. To encourage the opening of all 3D, 2D, Video and Audio formats, so that these formats can't be used to leverage anyone into a purchasing decision.. An example is how every Microsoft release of Excel or MSWord encourages a sort of peer pressure to repurchase of Excel and MSWord to allow communications between peers.

Other examples...

Blender's file format is foward and backward compatible.. I have yet to find a commercial equivalent.. I believe it would seen as not be a good business choice to make a forward/backward file format because it doesn't force the users to repurchase the next revision based upon file compatibility, which is the very least that would encourage a repurchase of an application.. In the same way I don't expect any business to make a completely open sourced object oriented interface standard or object based file-format, as it only opens them up to external competition (outside their sphere of influence).




Let me explain my idea for the solution...



We replace file formats with open sourced object standards.. By open sourced, I mean the code that controls the storage and retrieval of information to and from the file is with the file. And the application that uses the file instead executes and interfaces-with the code that knows thw file format better, that is the code that with the file itself. Code with data is the definition of an object. That summarizes my idea..



The less condensed form..




By objects, I mean data with functional methods.. I mean the data: video, audio, 2D, 3D information, everything, would be given the rights to interpret themselves and manage themselves..

Its taking the library that creates the file, and distributing it with the file, as one, and calling it an object. But the library would be open sourced, by mechanism, by coding the methods in a interpretive language like Java or Python. There are ways to make this library (stored with the object) efficient and secure (by limiting the complexity of the language to where its only useful for file intreptation operations).

It is a bit like how blender stores its files now, but instead of puting the support for the file format in blender, it would be puting the code that interfaces with the file format in with the data itself, which is the definition of an object.. So that the code that uses the file doesn't have to be as complex as the file it uses..

So instead of supporting every audio, video, 2D, 3D format under the sun, you need only support a single audio, video, 2D, 3D object interface standard, and every audio file is wrapped in a library that interfaces it with the outside world. And the code need not know anything about the specifics of the data format..

Of course, I expect every commercial developer to tap me on the shoulder at this time ans say "but that would make it impossible for us to leverage people into purchasing our applications just by changing file formats or interface standards".

BINGO

Yes, all poor purchasing decisions and vendor-locking methods begin with acceptance and encouragement of a change in the language of communication. So why not make the change impossible mechanically, standardize the method of using media so it can't be leveraged again..

On the more rational side of the argument, I would say

Wouldn't you rather get a movie object and not a MOV, AVI, WMV, ASF, ASX, RM, RAM, MPG.. Wouldn't you rather have a single application that you prefer that uses all these? Wouldn't you like to not ever have to deal with another proprietary format ever again? If you are a developer, wouldn't you rather not have to deal with the complexities of obtaining a image from a movie format.. Or locate the motion data for a joint from a proprietary mocap file? Would you rather not have to have special relationships with commercial software snobs that want you to pay for their SDK to access their special sauce formats?

It all begins with changing the language of communication..

BTW- I carried on some discussion with Richard Stallman about this..
I haven't continued it in months, but I plan to start it up again.. I really wish there was some world wide push for this kind of change.. Its not anti-commercial so much as its obviously pro-consumerism.. For me its non-political, I just can see the politics of file format standards and why they are and have become what they are.. Unless somebody says something, and somebody listens, nobody will understand..

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

One thing I'd like is people to right shorter posts and not long winded monologues.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

mchs3d
Posts: 0
Joined: Thu Feb 03, 2005 6:05 am
Location: Loveland, CO

Post by mchs3d »

I read about this. Sounds good to me, but a long project.

Zarf
Posts: 46
Joined: Mon Oct 14, 2002 3:54 am

Post by Zarf »

I am downloading the FBX sdk now. It is very strange, because about 6 months ago I tried very hard to get Kaydara to give us acess to the FBX SDK and even got Ton to talk to them about it. Now anyone can get it for free. It's funny how things work out.


Cheers,
Xarf

dandeloreon1984
Posts: 0
Joined: Wed Jan 21, 2004 11:12 pm
Contact:

Post by dandeloreon1984 »

i just downloaded and installed the sdk... I put the license information about the fbx sdk ast the attached file on this post (on my forum ):

http://s7.invisionfree.com/CXP_Forums/i ... wtopic=181

stas
Posts: 0
Joined: Sun Feb 27, 2005 3:28 pm

Post by stas »

as a reply to bfvietnams post:

say you've got an object which consists of a 3d scene and the information on its interpretation. say you've created this scene with maya (for example) and you've got "soft bodies" in it, which are still not supported by blender. now if you want to edit it with blender you either won't be able to do it at all, or the object itself will have to tell blender how to handle soft bodies. In the first case the compatibility of such a container among different applications would be so low that it's not worth the time spent on its design. In the second case you would make specific functions accessible to other programms, functions on which companies spend a lot of money to program, so you can't really hope to ever achieve that.

Soft bodies is just an example, similar things will happen with most of the other object types.

sten
Posts: 177
Joined: Sun Oct 13, 2002 7:47 pm

Post by sten »

theeth wrote:One thing I'd like is people to right shorter posts and not long winded monologues.

Martin
Hey I agree on that! :?

hey bfvietnam,
I rarely read all your long posts, have you ever consider to cut them down?

They are way to long to read to get a grasp of you really want to say.

please keep it short ;) just my suggestion

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

stas wrote:as a reply to bfvietnams post:

say you've got an object which consists of a 3d scene and the information on its interpretation. say you've created this scene with maya (for example) and you've got "soft bodies" in it, which are still not supported by blender. now if you want to edit it with blender you either won't be able to do it at all, or the
I'm not talking about the implementation of the primitives, eg. soft bodies, but
the data structures that represent the primitives (or in this case, soft bodies).. See I could store the soft bodies thousands of ways on a file.. But for every way there is a different file format.. But if there is a object format for soft bodies (or subformat) I could offer up a standard interface for Maya soft bodies, an interface for general soft bodies, and an interface for primitives (bounding box), an interface for extracting mesh data, etc..


Developers sometimes move stuff around in the file to discourage interpretation (from competitor's applications).. A real world example of this, is the use of what I call proprietary parking lots.. How construction companies design parking lots such that customers can't travel from one lot to another, so that the customers are discouraged to travel due to inconvenience.. Its the same case here.. The file formats encourage a sort of favoritism that companies like Apple and Microsoft relish.. If they were interested in convergence, they would open source their file formats and they wouldn't bother to patent the file formats, as Microsoft has done with WMV, which is a format based on ASF, with the difference that it uses new codecs and the container format is patented (try loading WMV or ASF in
Virtual Dub).. The purpose for this is to discourage competition.. Its easier to patent a file format because it has a specific form.. It would be possible to patent a object interface, but the data storage implementation would
be impossible to patent.. You could copyright it, but like open source, ideas are free, it would be impossible to discourage ideas from flowing around.. It would lead to convergence..

So in your case..

Say Maya 7 made the file, and blender became Maya 7 compatible. When Maya 8 comes out, Alias/Wavefront could change the data around such that blender would then have to be able to read Maya 8 files, even though fundamentally nothing much has changed with the data.. Its just been reorganized..

Its like moving furniture around. No matter how
you arrange your furniture, its the same furniture, its just positioned
some other way..

So why should you not recognize it if the stuff is re-oriented.. This is not a problem for a person, but for a computer program, it requires writing code that can descriminate/recognize the the patterns in the structure of the file format and extract the useful information from the file.. Its very subjective, even for the programmer.. All in the name of controlling the market and discouraging competition..


Is competition even an issue in the sphere of open source? Do open source projects compete? Why would they? Its design driven by use, not by monitary success, the person that develops the source develops in the interest of convergence/flexibility/fun/ease/to-communicate-unpopular-ideas, not much in the favor of survival or fiscal domination. So the ideas that shape capitalistically driven software should not drive open source, because the intents and constraints are different..


Rather than describing the scene with a data format, we would use methods to place the data (or soft bodies) into the scene.. And when reading the data out we would use the object's methods to get it (the soft bodies) out of that data format.

Thus whatever changes are made to the format of the data is kept transparent to the application that uses it and any reformatting of the
data that needs to be done can be done transparently to the application..
And since the methods are with the data, the data storage and retrieval source could be changed at any time without disrupting the original format of the data or its use..


Don't even think about commercial adoption.. People adopt formats like they adopt languages. If you need to use it, you learn it.. But what is the difference between using French or Japanese, or Chinese.. If people could, I'm sure they would speak the same language.. But with computers its far easier to standardize methods of communication. The reason there is less standardization is in the interest of remaining incompatible,
encouraging software repurchase, training developers who must remain compliant, to discourage market overlap, discourage extra tech support issues, all in the name of getting access to data, you already have..

So why do the open source developers continue to play this game.. Why not engineer the formats such that they are impossible to leverage and must be open source, such that they must be explicit, can not be obsoleted, can be optimized, simplified, secured, all without spawning yet another file format.. Converging on a standard approach, a standard way of communicating.. You can't do this with a file format.. You can do this with objects and interface standards. That's why it mystifies me so much..
Why this hasn't happened yet..

Software businesses are not in favor of convergence, not unless they have to.. The purpose for incompatibilities is to discourage competition, to discourage market overlap, support of third parties with different intents
that may be contrary to business..

In open source, what tends to develop
are applications and designs that are popular because consumers want them, and the developers are the consumers too.. But in commercial software development, the developers are most likely not the users. The developers care not how the application is used, they want their pay and want to get home.. But in open source, is driven by interest and need, the designs converge on the best and most flexible use, or in support of a multitude of methods that eventually converge due to popular use..

So why hasn't this happened with the file formats.. Why are we still using a multitude of data file formats, that are static, proprietary, non-convergent (like parallel lines that never meet or cross over)? That require special API's to access and extract, re-encode, store, manipulate.

Anytime you can't use a file just because you don't know the secret handshake, you shouldn't have to be dealing with that..

But I'm sure some of the ones that will object to my views are pro-capitalists that are afraid that such ideas would become popular.. Its the same kind of objections I got from Eskil when I started talking about "agent" objects (mobile objects that can travel between systems) in the confines of his Verse concept.

He preferred to
use a protocol between stationary objects versus objects that could
travel from system and talk amongst themselves.. The card that Eskil
pulled was "but that would allow for viruses".. But that's only if you have a predictable environment and the language that the agents have access to enough resources to do something naughty.. If you control the access to questionable functions (according to the intended use) you can eliminate the viral behaviours.. Same with the control of resources.. Its like how the XUL language is designed and optimized on firefox.. Firefox has these extensions that are objects (data and a special Javascript language that is incapable of accessing the Internet directly, so it can't be used to make spyware).

Its the same concept as with XUL, but instead of being designed to work with a web browser, these objects (or file wrapping objects) would be designed to work between and application and the data.. At most the methods in the objects would be capable of suplementing all the features of an application like Maya, at the very least, it could just hand the raw
data underneath over in a favorable format to the application.. But overtime the freedom of doing either approach and all in between, will cause a convergence of file formats to a common approach.. Making file format leveraging impossible and unpopular..

And no capitalistically driven software developer would ever want to implement this unless they are charitable.. That's why it would never be developed in closed source.. So why do we continue to support a variety of file formats that all store the same kind of information, only in a different arrangement?

You tell me!!

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

ztonzy wrote:
theeth wrote:One thing I'd like is people to right shorter posts and not long winded monologues.

Martin
Hey I agree on that! :?

hey bfvietnam,
I rarely read all your long posts, have you ever consider to cut them down?

They are way to long to read to get a grasp of you really want to say.

please keep it short ;) just my suggestion
code + data = object

file formats = data

libraries that read file formats = code

media objects = libraries + file formats

(actually libraries that wrap the file formats).

Then take the library, write it in a custom language that
discourages the creation of viruses, worms, tampering, etc.
That focuses primarily on the encoding and decoding of data into
files..

Then over time as application developers and users use these objects,
I imagine that objects will converge on a design.. The only way this can happen is if the code is in the objects are open sourced by mechanism.. And that the code in the virtual machine that executes the objects' methods, is also open source by popular preference.


Now what I want are reasons that this will not work..

What I suspect I will get is silence, or people claiming that I
am not concise enough.. What I will not get is sound, counter-proofs.

A challenge..

I was going to talk about what I thought of Martin and his usual
response to my messages.. Obviously he is nervous,
he said "right" when he should have used "write".

-efbie-
Posts: 0
Joined: Wed Oct 27, 2004 9:47 pm

Post by -efbie- »

to make it short : the FBX sdk isn't compatible with the GPL, so unless someone code it from scratch, i guess we won't see it integrated soon...

a truely open format would be cool. doesn't vrml already does that ? If not you should find someone to code it and realease it under bsd or MIT, but it won't be easy...

And Bfvietnam, you should really get to the point when you write posts, it is a pain to read all that when english isn't your first language. (that's why i usualy don't read them...)

blendix
Posts: 51
Joined: Wed Oct 16, 2002 1:00 pm

Post by blendix »

-efbie- wrote:to make it short : the FBX sdk isn't compatible with the GPL, so unless someone code it from scratch, i guess we won't see it integrated soon...
That shouldn't be an issue. It just can't be statically linked, but instead needs to be loaded as a dll/so (just like it's done with quicktime now).

theeth
Posts: 500
Joined: Wed Oct 16, 2002 5:47 am
Location: Montreal
Contact:

Post by theeth »

Your idea in itself isn't so bad, except for the fact that it had very little to do with the topic in a thread about FBX inclusion.

Those are the potential pitfalls that could cripple such a project (IMHO, of course).

- Over generalisation or specialisation of the file format Too generalised and it would make it unusable without people adding unspecified meta data formats. Too specialised and the file specifications would become huge while a good proportion of the softwares using it would use very little (bloat). The latter is the worse organisation wise, but the best for outside developers looking for complete feature set.

- Creation of a large consortium for decision making This in itself isn't really a problem. You can't decide on a format by yourself and except people to use it if they have no say on what the said format can do. However, this can lead to biased decisions in favor of the members that want solutions tailored to their needs (the openGL consortium had problems with that).

- Language dependant API specifications This is less of a problem if you limit your API to object oriented languages (but even then, the flavors vary wildly), but if you want to integrate a C API, good luck keeping it looking the same accross the board while not downcasting it to the lower denominator.


bfvietnam wrote:What I suspect I will get is silence, or people claiming that I am not concise enough.. What I will not get is sound, counter-proofs.
People don't answer because they are at loss in front of your lack of rational writing skills. Your posts go everywhere seemingly without intent, and I'm not the first one to say that.
bfvietnam wrote:I was going to talk about what I thought of Martin and his usual
response to my messages.. Obviously he is nervous,
he said "right" when he should have used "write".
Obviously yes. :roll:



Back to the topic at hand: FBX integration.

Blendix summed up pretty nicely the linking issue. Also, as is the problem currently with openEXR, having it dynamicly linked is also very good when the library size would double the size of the application. Very easy to make it a plugable addon then.

Martin
Life is what happens to you when you're busy making other plans.
- John Lennon

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

-efbie- wrote:to make it short : the FBX sdk isn't compatible with the GPL, so unless someone code it from scratch, i guess we won't see it integrated soon...

a truely open format would be cool. doesn't vrml already does that ? If not you should find someone to code it and realease it under bsd or MIT, but it won't be easy...
vrml is the "open inventor" scene language.. Open inventor was
released in the mid-90s as a library to allow 3D/2D applications development on SGI's, it works atop OpenGL.. VRML just came out
of the scene graph language that Open Inventor used for storage.

What I'm proposing about the media objects could be implemented
in something like VRML.. What you would do is create a VRML format
with methods in the data structure that contain python code. Then
write the python code to access data in the VRML file..

IF you do that, I guarantee you will find value in this that would beat
using a static data format. Its just a matter of it being done.
And Bfvietnam, you should really get to the point when you write posts, it is a pain to read all that when english isn't your first language. (that's why i usualy don't read them...)
I wish more would say this than saying my messages are too long. I have determined that is the major reason discussion is so terse on the blender site.
Last edited by bfvietnam on Thu Mar 17, 2005 5:26 am, edited 1 time in total.

bfvietnam
Posts: 0
Joined: Wed Apr 21, 2004 8:54 pm

Post by bfvietnam »

blendix wrote:
-efbie- wrote:to make it short : the FBX sdk isn't compatible with the GPL, so unless someone code it from scratch, i guess we won't see it integrated soon...
That shouldn't be an issue. It just can't be statically linked, but instead needs to be loaded as a dll/so (just like it's done with quicktime now).
To explain..
When you compile a program (the process that turns source into something you can use), you have the choice of statically linking the binaries (which compiles the library into the executable, in this case blender.exe) or calling the library dynamically while executing..

The problem I would see with linking the libraries into blender, is that
there would need to be compiled versions of the library for every operating system blenders works on, otherwise the library couldn't be linked into the executable (or would have to be selective about what to execute).

The other problem I could see is that static linking adds to the executable size, which uses real memory, storage space and adds to the load time..

So GPL requiring dynamic linking isn't such a big deal, it saves you
in other ways. It just clutters the disk space.. But if its a problem for you,
you could always just zip blender and the dynamic libraries together into a self-decompressing executable and call that blender (if possible). Its better this than adding uneeded complexity to blender and the compiler process.

Post Reply