[Bf-gamedev] The future of FBX and/or other formats in Blender
metalliandy
metalliandy666 at googlemail.com
Tue Feb 9 23:30:12 CET 2016
Hey everyone,
I have mixed feelings about this to be honest. While I don't agree with
the way FBX is licensed (it should be open sourced ASAP, IMHO), the fact
remains that it is still the current interchange format and will be for
the foreseeable future, no matter who owns the standard or how much we
dislike it.
I would hate for this to turn into another crusade against Autodesk,
where we all just start blindly sharpening our pitchforks and blindly
head into the foray, because such things only end up hurting our users
in the long run. Yes, it would be awesome to support other formats such
as glTF, Alembic and USD, but it wont mean anything if no one else
within the games industry uses them too. We would just end up with a
Blender only pipeline and "Blender is for Blender users" crap that flew
around a few years ago. Such protectionism can only hurt Blender as you
are effectively working against de facto industry standards rather than
with them. Having a program that can't talk to other software restricts
the use of said software, and studios are simply not going to adopt
Blender only pipelines so a competent interchange format is essential.
Yes, standards do change, but this takes a _very_ long time to happen.
Remember when Collada was meant to be the new standard? Look what
happened there...
As of now no other format (aside from the ageing and less feature rich
OBJ) comes close the the level of industry support that FBX has & even
Pixologic, who have been the bastion of OBJ support (even extending the
format to support vertex colours), have recently implemented FBX support
in the latest version of ZBrush to aim interop. between applications.
This is unfortunate of course, but unless we want to alienate Blender
from the rest of the 3d world stopping support for it would be a bad
move. Blender has made so many giant leaps forward in terms of gamedev
use over the past few years and having FBX slowly break over the next
few years will do nothing but hurt Blender usability and reputation.
Most people simply don't understand or care that we can't use the FBX
SDK within Blender and will simply assume that Blender is buggy.
It's not just about current users either...we have to think about future
users that are migrating over to Blender from Max/Maya who expect
something like FBX to just work. If they cannot simply load an FBX into
Blender without issue, they will also assume that Blender is buggy as it
can't even support FBX correctly.
Next we have to think about people who use Blender on a professional
level too for things like freelance work. 80% of the time I get meshes
for texturing/baking from clients the low poly & block out mesh part of
the asset are in the FBX format. It would be extremely embarrassing and
unprofessional of me to request OBJ in the place of FBX and potentially
jeopardise the possibility of future work with new/especially picky
clients (FWIW, I used to use FBX converter to go from FBX to OBJ, but
this is ironically no longer supported by Autodesk).
In addition to the above we also have the problem of fixed pipelines. It
is usual for studios to define a pipeline during pre-production and
maintain it rigorously at the low level at least until the current
project ends. Many studios also run staggered production of multiple
projects using the R&D & pipelines of the previous "lead" project and if
we assume that a project will last between 2-4 years we are probably
talking between 3-6 years before pipeline changes are considered for
something as integral as interchange formats. Granted this is more
likely a problem for AAA studios and not many of them use Blender as a
main tool, but they do have freelancers who use Blender, which will be a
problem for them. It will also rule out Blender for such studios if they
were ever to think about moving over (assuming they use FBX ofc.)
Ignoring the problems with FBX isn't going to help anything really as
the problems will only get worse over time and there is nothing we can
realistically use to replace it with.
I guess that I find it hard to see how anyone can seriously think that
maintaining FBX is a waste of time because such support is essential for
the many people that use FBX on a day to day basis. Wouldn't it only be
a waste of time if no one used it?
Cheers,
-Andy
On 09/02/2016 19:33, Piotr Arlukowicz wrote:
> Standards can change, and the sooner, the better. World should be open
> and friendly, not closed and cluttered with crap from huge companies.
> As I don't have to use FBX, I vote against it every possible time.
> Let's make something valuable instead of supporting those bastards.
> They are famous but their so called standards are nothing more than
> bad habits. Yes, I blame autodesk and the others for being closed,
> money greedy and unfriendly to the community. That's mine five cents.
>
> pio
>
> Piotr
> Arlukowicz, BFCT
>
> **YT:*_/user/piotao?feature=guide_*
> *FB:*_/polskikursblendera_ *TW:* _/piotao
> _
> *Blender Network:* *https://www.blendernetwork.org/piotr-arlukowicz*
> *Polski Kurs Blendera:* http://polskikursblendera.pl
>
>
>
>
> 2016-02-09 13:16 GMT-05:00 Bastien Montagne <montagne29 at wanadoo.fr
> <mailto:montagne29 at wanadoo.fr>>:
>
> Well, once more time: I do not ask to drop FBX, I ask to stop
> investing time in it. Means we would keep it working in current
> state, but not try to add/support/fix new things.
>
> Le 09/02/2016 18:18, Cremuss a écrit :
>> Hi,
>>
>> As evil as FBX is, and I totally understand why you think it's a
>> dead-end (and it is, truly), I feel it is a necessary evil for now.
>>
>> Many of us pro Game Artists rely on FBX file format because
>> there's simply no other choice yet. I export a lot of animated
>> stuff to UE4 and Unity, and dropping FBX support in Blender would
>> mean I'd most certainly have to buy and use a proprietary 3D
>> software to work, which is a shame.
>>
>> A minimal FBX support would still work for me though, because,
>> /personally/, I just need to be able to /export/ animated meshes
>> and armatures, mostly to Unity and UDK/UE4. So dropping support
>> of the FBX importer, as well as the support of lights, cameras
>> and any other fancy stuff wouldn't affect me or my work at all.
>> But that's just me.
>>
>> However, I'm all for supporting an open format if it will allow
>> me to export animated data to Unity/UDK/UE4 by the time we fully
>> drop FBX support. But as far as I know, there's no open FBX yet :/
>>
>> I know Unreal has donated to the Blender Foundation to work on
>> the FBX exporter so they seems open and friendly to me. Maybe
>> there's a way to talk to them and see what kind of options we have.
>>
>> Anyway, that's just my honest opinion!:)
>>
>> Le 09/02/2016 17:49, Fillippe Chiniara a écrit :
>>>
>>> I think its a bad move for the game developers that use blender,
>>> you would abandon all of us because fbx is THE standard for game
>>> dev , we cant use anything else with the modern engines, at
>>> least nothing with the same level of support.
>>>
>>> On Feb 9, 2016 14:42, "Bastien Montagne" <montagne29 at wanadoo.fr
>>> <mailto:montagne29 at wanadoo.fr>> wrote:
>>>
>>> Hi,
>>>
>>> So, lately there's been a lot of FBX-related issues reported
>>> to our
>>> tracker. Most of those are either:
>>> - Known (half-)broken things (like cameras/lights
>>> orientation issues),
>>> over which I do not intend to spend more time, since those
>>> are not
>>> critical features to support imho.
>>> - Broken corner-cases in an area that globally works rather well
>>> (thinking about skeletons here).
>>> - Mysterious third-party applications-related issues
>>> (scaling, skeletons
>>> again, etc.), that is, bugs that show with one app but not
>>> another.
>>>
>>> I think later point is a good demonstration that FBX itself
>>> is a failure
>>> and a dead horse - if even rather big and serious companies
>>> like Unreal
>>> or Unity cannot get a reliable FBX importer working using
>>> official FBX
>>> SDK, then how are we supposed to do it without even that SDK?
>>>
>>> Further more:
>>> - In past two years a lot of time and energy was invested
>>> (lost) in FBX.
>>> - </rant> I’m just dead sick of that format, of hitting any
>>> possible
>>> table corner when trying to walk my way in that non-sensible
>>> pitch black
>>> box, etc. </rant>
>>> - Knowledge I gained of this format and its evolution is **not**
>>> encouraging at all (stupid things like supporting two
>>> different and
>>> complex transform systems [3DS max and Maya ones, btw ;) ],
>>> a very weird
>>> inconsistency at binary level, etc.). I do not have any
>>> feeling this is
>>> a sane format, nor that it is evolving in a sane direction.
>>> It seems to
>>> be defined a bit as needs arise, piling up new stuff over
>>> old ones, etc.
>>> To summarize: no clear design behind it, and a very dirty way of
>>> handling new versions of it.
>>>
>>> So I would claim to stop relying on and developing it. It
>>> would not mean
>>> we just remove it from Blender, but think it’s time to switch to
>>> something more modern and open - am aware of at least to
>>> possible
>>> alternatives, which could even be quite complementary.
>>>
>>> I) glTF
>>> Promoted by Khronos group (https://www.khronos.org/gltf), it
>>> aims at
>>> being the open exchange format for games (from simple asset
>>> to complete
>>> scene description).
>>> Think it’s still very new stuff, not much widely used yet,
>>> but it seems
>>> to have some support from several major companies (including
>>> Microsoft
>>> and even - rofl - Autodesk, see http://gltf.autodesk.io/).
>>>
>>> II) USD
>>> Promoted by Pixar (http://graphics.pixar.com/usd/), it aims
>>> at being
>>> some kind of generic pipeline format for CG studios (it also has
>>> integration of Alembic e.g.).
>>> I have no idea of its acceptance currently, but sounds like
>>> it could be
>>> a valuable option for our 2.8 'pipeline/inter-application
>>> exchange' goal?
>>>
>>> (as a side note, interesting to see that those two have a
>>> similar
>>> approach, they are not monolithic files but rather a
>>> combination of
>>> binary data and textual descriptions…)
>>>
>>> Anyway, those are very early reflections, would like to get your
>>> feelings about those two formats/projects (or others you may
>>> have in
>>> mind! ;) ), but I’m feeling much more enthusiast at the idea
>>> of spending
>>> time on modern, open-designed (or at least, open-specified)
>>> formats,
>>> than on piece of proprietary crap!
>>>
>>> Again, even if we end up deciding we stop trying to fully
>>> support FBX as
>>> our main exchange format, it would keep being supported in
>>> its current
>>> status at least for one or two years - just I would not try
>>> to add
>>> support for new versions (2016 one seems to have some
>>> incompatibilities
>>> with our code already), nor would try to understand and fix
>>> more stuff
>>> in that format.
>>>
>>> And that’s a long enough mail, thanks for reading it!
>>> Bastien
>>> _______________________________________________
>>> Bf-gamedev mailing list
>>> Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>>
>>>
>>>
>>> _______________________________________________
>>> Bf-gamedev mailing list
>>> Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>>
>>
>>
>> _______________________________________________
>> Bf-gamedev mailing list
>> Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
>> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org <mailto:Bf-gamedev at blender.org>
> http://lists.blender.org/mailman/listinfo/bf-gamedev
>
>
>
>
> _______________________________________________
> Bf-gamedev mailing list
> Bf-gamedev at blender.org
> http://lists.blender.org/mailman/listinfo/bf-gamedev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-gamedev/attachments/20160209/0df1a345/attachment-0001.htm
More information about the Bf-gamedev
mailing list