[Bf-gamedev] Proposal to (try to) get better FBX support

[metalliandy]

Hey all,

The whole point of this thread is to discuss better FBX support rather 
than debating suitable alternatives and as such I feel like this thread 
is getting a little off topic and starting to get a little noisy.
The choice of interchange format has been already made for us by the 
industry so discussing alternative formats is fine, but perhaps a moot 
point for this thread.
Could we maybe make a new thread for any non-FBX related topics please? 
If only for ease of reading. :)

Cheers,

-Andy

On 04/10/2014 21:47, Forest Hale wrote:
> I will note that the criticism expressed toward Collada has primarily been on the difficult of parsing it directly in a game engine or conversion tool - specs tend to get MORE complicated with
> revisions, not less, so this is a deadend approach if simplicity is a goal - and I believe that any source asset format (that is to say, fully featured for longterm maintenance in multiple modeling
> apps, with multiple kinds of mesh data, camera paths and other scene parameters, etc) is going to be suboptimal for direct use in a game engine.
>
> To cite an existing format that has the specific goal of being used in games, I'll point to the IQM format (Inter-Quake-Model - it originated from the Quake and Sauerbraten communities):
> http://sauerbraten.org/iqm/
>
> The iqm format has a blender plugin already, and is supported by a couple dozen games (on various engines) as a directly loaded format, its main feature is very consistent mesh formatting for optimal
> draw order in games (a critical feature for real-world use - it is not a source asset storage format like Collada), with skeletal animation, custom vertex properties (certain ones are required but you
> may add as many as you like), and is extensible.
>
> I tend to favor piling on more features to an existing standard rather than making yet another one.
>
> On 09/29/2014 06:26 PM, Andrews Magnoni wrote:
>> Why not partnering with Khronos for making Collada better?
>>
>> The last version of Collada was 1.5.0 in 2008!
>>
>> On Wed, Sep 17, 2014 at 7:56 AM, Jens Christian Restemeier <jens.restemeier at gmail.com <mailto:jens.restemeier at gmail.com>> wrote:
>>
>>          I do not think Collada is the way to go, I would even say it?s the other
>>          direction we should take, if we were to work on a new format.
>>
>>
>>      That is a noble goal, but the danger is that you end up with this: http://xkcd.com/927/
>>       
>>
>>          I would go to a minimalistic format. FBX is much better than collada on
>>          this regard, but it is cluttered with an history of crapiness - and some
>>          aspects (like its object transform model) are still crazy.
>>
>>          An exchange format does not have to support every possible feature. An
>>          exchange format has to be simple!
>>
>>
>>      One idea I had was to define a strict subset of Collada that require least effort to map into an application without going crazy. That could be tagged in the header, and if a importer finds that
>>      it goes through a fast/simple importer. If it isn't there the importer has to go through more general code.
>>
>>      Example:
>>      - fixed transform stack for nodes: Either a matrix, or a translate/rotate/scale stack for animations
>>      - fixed vertex format for each channel and "simple" layout. Instead of supporting every simple buffer and data layout, only support a base format. (basically something like FBX.)
>>      - fixed geometry format: for example support only convex polygon primitives without holes
>>      - fixed order in which libraries are defined
>>      - strict usage rules for the different name, id and sid tags and path references.
>>      - fixed armature layout rules
>>
>>      That way you have automatic support to import into other applications, and people could import and export the subset into their own code without spending ages supporting any odd configuration.
>>       
>>
>>          E.g. I like Wavefront .obj format - it is simple (even though Max
>>          managed to break it with odd expectations on smoothgroups :/ )!
>>
>>
>>      I'm not a fan, mainly because it splits materials into a separate file, and is limited by some old assumptions about how to work with geometry and shading info.
>>
>>      Jens
>>
>>      _______________________________________________
>>      Bf-gamedev mailing list
>>      Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>>      http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>>
>>
>>
>> -- 
>> *Andrews Magnoni*
>> *
>> *
>> *Desenhos: *http://amagnoni.deviantart.com/
>> *Videos: *http://vimeo.com/amagnoni
>> *<http://www.coroflot.com/andrews/Desenhos-de-retratos>*
>>
>>
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>