Alias .FBX SDK free!

General discussion about the development of the open source Blender

Moderators: jesterKing, stiv

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

I hijaked the discussion, but for good reason.

Post by bfvietnam »

theeth wrote: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.
FBX is a file format.. I admit I hijaked the discussion, but the
perfect place for these media objects to be implemented is here,
on blender.. Its the only application in open source that must use such a diverse array of file formats, why not try to localize the complexity to the
file format rather than puting it in the library and the application?
Why not start with blender?

At the very least, use a abstract interface that connects FBX API to
blender.. Then over time merge the FBX API and the FBX file into
a single object, and the abstract interface connects to a virtual machine or interpreter that executes methods in the objects.

The first step would be the interface abstraction.. The best way to research this is to find all the mo-cap file formats, and to find the simplest common denominator, call that the general interface.. Then create specialized interfaces that elaborate on this.. That will allow blender to
support newer mo-cap files without being specialized to access each file format.. With the eventual result being a convergent standard for mo-cap files, or mo-cap interfacing..

My media-object idea is just something that would evolve from this in the future to end file format specialization altogether.. Be excited, this has never been done.. And why? Because its never been tried.. The danger, viruses, worms, trojans? Rubbish that's commercial vendors talking to discourage the creation of media objects, and more generally a concept called a "agent" which is a mobile object.
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.


Complexity now goes into the libraries that read and write the files, the file s can be manipulated and changed over time rendering the files obsoleted by the progress of the file format. You can change the file format by defacto use, this is how Microsoft competes, by slightly changing languages, file formats, to signal a software repurchase or to discourage users from adopting other platforms that are compliant with older formats but not the latest format from Microsoft..

A generalized format is using void pointers and associative arrays
everywhere in the data format, which is not far off from how blender stores its own structures..

And over specialization can only happen if the format is static.. You can't overspecialize an object. Imagine how "interfaces" are used in java.. To keep a media format generalized, you require at least a certain set of methods to be implemented by the object. To keep the object from being over specialized, you can have the object specify what interfaces it implements, which would shed light on what methods in the object can be stripped from the object. You can not do this with a static file format. Once a file format becomes standard, all you can do is add data to it.. In XML its easier, but more often the extra data goes at the end of the file with flags in the file that specify irrelevant chunks. If you use objects, it doesn't matter where the data goes as long as your methods either come at the beginning or the end.. The data format can change however is needed..

There are even ways that you can guarantee object integrity to prevent tampering and god forbid Microsoft should try to sabotage every media object individually.. The reason for puting the methods in the object is to localize the complexity.. If you worry about extensibility, you can always
replace the method sets of the objects, or wrap them with helper objects..

Since the methods are written in plain text, and the virtual machine or interpretive language that executes the methods is (assumed to be) in open source, its a platform independent solution. To extend the media objects without changing the existing method set, is fairly easy as well,
just add the method on, its plain text..
- 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).
Consortiums come about in the context of commercial vendors who
need standardization that all the vendors can agree on.. In this case, the
technology would be open sourced through and through.. The only part that might need a consortium is the agreement on how to develop and design the virtual machine such as to discourage worm/virus/trojan design.. But the interface standards can adopt from research already done with CORBA interface standardization. Vendors are against any kind of standardization as it means competition, so you will find most vendors on standardization boards or consortiums there purely to sabotage or veer the standard in favor of each ones own implementation, that would
eventually lead to a monopolization. Multiple vendors are involved to
keep this behaviour from happening but the standards that develop are
usually more generalized than they should be. CORBA failed not because its a bad idea, but that the ORB implementation was not nailed down, so the vendors diverged in the area of ORB implementation. The purpose for the OMG's fast track standardization is to standardize on proven technology, its a way to break through a standards board that may contain stragically placed skeptics (that have no intention of arriving at a standard).

As is commonly said, getting companies to agree on standards is like herding cats.

You will find that once you mention that the methods in the objects are open source by design, many vendors would object just be virtue of the lack of leveragibility of such a design. I imagine some vendors would even try writing viruses and worms to exploit the weaknesses in the media objects, to encourage people to return to static content formats..

- 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.
Well the methods in the objects are in clear text or at most is tokenized, and need only be a procedural language that refers to external variables..
The methods need not have access to anything outside of the object..

As for the API that C and C++ and such connect to to use these objects.. Basically they would be talking to an object that is running on a virtual machine.. The API is not even a concern.. Its not much different from RPC or any other form of message passing. The difference between my media object idea and CORBA/COM/SOAP is that mine is open sourced and that frees up a lot of the design concerns that nail those to the floor.

The only wildcard here is the language that the methods of the media objects, and the form the data will take in the object.. The only one we should care about is the method interfaces for the objects and the language that the methods are implemented in. The data structure is
of no concern by virtue of how the data is accessed (by the methods).

The language can be some combination of PHP, Python, C, Perl, Java,
or at the very least a form of LISP. But the constraint on the language is it cannot do anything outside of the scope of manipulating data structures and processing data. If you keep the memory access to relative addressing, however the object can talk to other objects that may have system functions but this would be controllable by the user of the objects..

If you remove the use of pointer arithmetic (which is the single most cause of core dumps in C based applications) and things that are known to make writing viruses (direct memory access), worms (unconstrained resource allocation) and trojans (sockets access), the security issues fade away.. With XUL on firefox, the only security disputes people can find is phishing/spoofing schemes, but that can be fixed once XUL is limited to
only certain kinds of GUI manipulation (not an issue, in the long run)..
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.

Sorry.. But you can't make everyone happy..

I have problems that are not much different from ADD, I've had since I
was young, the clinical term is called audio-perceptual difficulty.. I don't
want to make it an excuse, but it does hav an effect on how I choose my words as words are hard to recall, I spell by phonemes, when I read my brain converts the text to audio before I can interpret the meaning of the text.. If you can imagine a blind man drawing a picture of mona lisa, that's how writing text is for me.. I have to take ideas in my head and write them in a way that the ideas come out the same way on your end. What furstrates me, is the mis-interpretation of my ideas, which just leads me to write more.

It actually may be better to interact, but like a lawyer,
I feel like revealing everything I've thought of to discourage mis-interpretation..

So considering the problem others have with interpreting my
messages, interaction would work.. However, if I say to little, it
will not stimulate a response. I break my text into paragraphs, to
seperate ideas.. But think of my messages as a collection of thoughts than
a single thought.. The problem with essays and messages that stick to a point is that they can at best describe "the elephants ear", they fail to describe "the elephant". But like a oil painter, the medium can change my ideas.. While others are limited by a sort of analysis paralysis that prevents them from developing ideas. If you are unable to conceive of a
large design, how can you code? You code in bits, and the code changes
your ideas, and inspire changes.. You never know exactly what to do the minute you start coding, unless you are some einstiein.. I'm no different,
I just do my coding in the form of descriptions, and discussions..

Coding is the most concrete form of expression, but its not the most
flexible.. And its time consuming.. This is why I prefer to discuss my
ideas, and the reason for my complex discussions is I am also trying to condense my years of programming experience which I can't assume
you all have had.. How should I know what experience you have had? Have you been involved in a OMG standardization process, have you
got a degree in computer science, have you taken courses in all the
programming paradigms from an instructor who was involved with Xerox PARC in the 70s. No, what influences you is something different..

So when I am wordy, and complex, its how I express,
but I can't imagine how I could make it better..

I guess to provide coding examples would be the only way
to communicate, but who would read? at least in plain english
I can get more eyes..

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.

Possibly to even have this media object API later to substitute for the
API to the FBX stuff.. Imagine a media object that goes between blender
and the FBX file, replacing the FBX library.. Then eventually the
FBX file gets generalized with the option of specialization by virtue of the flexibility of a object format, and blender then adopts a standard interface for accessing mo-cap data that forces the complexity into the media object, offloading responsibility on the object maker and not blender..

Blender is a general enough used application, and open source development, it could be used to drive this media object idea..

Have blender support a general interface for access to mo-cap files,
which would change infrequently, and create specialized profiles (interfaces) that inherit from the general interface.. The generalization
must be the simplest implementation of a mo-cap file.. The specialization includes all the extra stuff that you would want.. Each mo-cap file type
would probably have little or no extra interfaces, but the interfaces themselves would not represent the file type.. So if you have three mo-cap files and two provide much the same kind of content, those would
not need two seperate interfaces.. However file formats demand a seperate interface for every permuation of specialization, which demands
unification in the libraries that have to deal with file formats.

Which is easier to deal with, a file format or an object interface?
it depends.. I feel for most cases, object interfaces would be.

Which is easier to manipulate and sobtage?
File Format, much more so..

Which is more discrete?
Object format (if the method interface for an object is too complex its
a problem with the design, not the object).. C programmers often use objects like libraries, which is a problem with the programmer, not with the paradigm.. Coders are intimidated more by object oriented languages because they lack the ability to abstract their code, or organize their house.. Its a designer's job, not a programmer. Design by coding is
suitable, but its too easy to get stopped by feasibility and implementation
issues before realizing a solution.. This is why I talk and I don't code.

Also coding wastes more time than designing does..

If you need proof I can do it in PHP.. But the basic ideas are generally
understood than any coding would require.. But you won't get arrested by the coding cops for trying.. You will waste more time by not doing this
than you would doing it.. What do you have to lose?

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

Re: I hijaked the discussion, but for good reason.

Post by theeth »

bfvietnam wrote:
theeth wrote: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.
FBX is a file format.. I admit I hijaked the discussion
Then take it to another thread.

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

Post Reply