Hi William, Your message arrived loud and clear! Of course we stick to keeping FBX IO to work, the discussion is mostly about:
- How to keep it maintained well, should we limit the scope a bit (design issue) - Who could be found to work on it (we have a dev fund to support that) What you (and other FBX users) can do to help is to join forces and create a reference test suite of files you want to keep working (import of fbx in Blender, export to fbx from Blender). Not a wishlist, but a maintenance list! Files that work already (and documented how), which we can use to test before releases and after code changes. -Ton- -------------------------------------------------------- Ton Roosendaal - [email protected] - www.blender.org Chairman Blender Foundation - Producer Blender Institute Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > On 11 Feb, 2016, at 15:29, William Culver <[email protected]> wrote: > > I love you guys. I've spent 8 years invested in Blender with my company. > I fight so hard as an advocate, all interns come to me with Maya/Max > training and I make them learn Blender. I'm constantly on job sites and > 99% of the time there I'm the only employer in the whole of the UK looking > for people with blender skills. > > Point being, us Blenderers are massive outsiders in the industry already.. > and despite all the technological agreement, and sound argument from > Bastien RE the FBX issue, I'm really dismayed with Blender right now. > > I feel like Autodesk is laughing at you guys giving up with FBX... You're > playing right into their hands and have just given them another small > victory by validating all of their efforts to make the spec hard to access > in the first place. Please blender devs, I know FBX sucks and i know we > should be pushing for better and more open file formats but *please *don't > alienate us further by having bit rot take away FBX. Its too soon to stop > dev when there's little momentum for industry change and so much weight > behind FBX. I know you are going to argue that stopping dev on FBX *is* > the momentum for change but come on guys we are tiny compared to Autodesk.. > FBX is a juggernaut and every single one of the MANY wanna-be game devs is > going to spend 5 minutes with blender and then hop straight over to Maya LT > unless FBX continues to work. You're going to indirectly make Autodesk > MORE money with this decision and i can't think anything worse than that. > IMHO. > > I know the format sucks and we have to reverse it to the point it could > break tomorrow anyway. I think you greatly underestimate its necessity.. I > can point straight to more than 5 teenagers I know that downloaded blender > to make a game asset for UE4 and that's just my first hand knowledge. I > think FBX export is one of the earliest things one does when dabbling in > blender and first impressions count. > > Of course no one can blame Bastien for having enough and I thank you for > your hard work to date. Please *please *put *some* continued resources > into FBX though Ton, we desperately need something equivalent in its place > before the bit rot starts to take hold. > > TL;DR.. I agree with this at a development/technical level... on a > political level you guys have scared the bajeezus out of me. > > > Thanks Blender, you're the best. > > Regards, > > William Culver > > > > > On Thu, Feb 11, 2016 at 1:21 PM, Juan Linietsky <[email protected]> wrote: > >> Ton, >> >> Here's some facts you are missing: >> >> -My Collada exporter works with Unity, Cryengine and imports correctly in >> Maya/Max too via OpenCollada plugin. >> -My Collada importer opens perfectly any scenes exported from Maya and Max >> (Using OpenCollada plugin), XSI and Lightwave. Of course it also opens >> scenes from my Collada exporter. >> >> You are free to test this yourself. >> >> The reason this failed consistently in Blender is because you guys didn't >> care about having experienced developers spend time making it work. >> Had Campbell Barton worked on it as he did on FBX, Collada would work >> wonderfully. I just used his same approach to make my Collada exporter, >> using OpenCollada library was a huge mistake. >> >> Still, I understand your concern and it is true that Collada was >> originally devised as an exchange format. But if you read the specification >> you will realize that, with each version, it quickly migrated to a format >> used to export assets for game engines. As an exchange format between 3D >> DCCs it's severely limited. >> >> So my proposal is the following: >> >> -Deprecate current Collada export support in Blender and replace it for >> mine. Change the focus so it works well with game engines as a priority. >> Having an alternative to FBX for this is a lot more important, both for >> commercial game engines and (most vitally) for OSS game engines. >> If the focus is for DCC exchange, we know it will never work properly for >> any use case and it sucks as a format for that anyway. >> >> -Deprecate current Collada import suppot in Blender and work together with >> me to implement my library, which has extremely high compatibility. >> >> -Find a more useful long-term solution for asset exchange between Blender >> and other 3D DCCs. I don't think even FBX is up to this task. If it was up >> to me to decide, I think the best solution would be to implement a >> dedicated .blend importer/exporter plugin for Maya, and make sure every >> single use case works. From there, you can go to any other Autodesk >> software using Maya Import/Export. >> >> What do you think? >> >> >> >> On Thu, Feb 11, 2016 at 9:13 AM, Ton Roosendaal <[email protected]> wrote: >> >>> Hi Juan, >>> >>> I think we mix up different use cases. >>> >>> - COLLADA was meant to be a cross platform 3d exchange format. Even >>> Khronos recognizes that this goal has issues. COLLADA has design flaws, >> it >>> is disputed, very hard to get to work. >>> >>> - Many Blender developers have put time on getting COLLADA exchange to >>> work. With Python, with OpenCollada, with own C++ code. We tried a lot, >>> discussions go back to 2004 already. In days of work, it had similar (or >>> more) attention as developers gave to FBX. >>> >>> - You made a COLLADA exporter to work as native format for Godot. That is >>> cool, COLLADA works fine that way. >>> >>> What we tried is something else, it is 3D exchange: a format to work in a >>> mixed tools pipeline. That means Maya to Blender and back. And that is >> what >>> FBX currently offers to the industry. COLLADA could have offered it too, >>> but after 12 years we better conclude it won't work for this. >>> >>> Conclusion: Blender can just get multiple COLLADA exporters to "save as >>> Godot" or "save as 2ndlife" or "save as Maya", for as much developers >> wish >>> to support that. >>> >>> Laters, >>> >>> -Ton- >>> >>> -------------------------------------------------------- >>> Ton Roosendaal - [email protected] - www.blender.org >>> Chairman Blender Foundation - Producer Blender Institute >>> Entrepotdok 57A - 1018AD Amsterdam - The Netherlands >>> >>> >>> >>>> On 10 Feb, 2016, at 21:41, Juan Linietsky <[email protected]> wrote: >>>> >>>> Guys I'm sorry. I've seen this situation happening over and over to no >>> end >>>> for more than a decade. >>>> How about some self-criticism from Blender instead of blaming Autodesk? >>>> >>>> If you guys really had cared about open standards and getting along >> well >>>> with game engines, you would have done the following: >>>> >>>> 1) Make sure you export proper Collada. The specification is pretty >>> clear. >>>> 2) Push game engines to fix their importers. >>>> >>>> Blender support for Collada has always been a disaster. There was never >>> any >>>> will to fix it. >>>> >>>> -I originally insisted against using OpenCollada due to the huge binary >>>> bloat, and the fact the spec is pretty simple. You guys wanted to go >>> with >>>> it. >>>> -The exporter was huge and full of bugs. I insisted that a lot of >>> features >>>> missing in the spec needed to be implemented, was ignored. >>>> -Meanwhile, all the missing Collada features were implemented in FBX, >>> such >>>> as blend shapes, proper keyframe baking. constraint baking, exporting >> all >>>> actions, etc. >>>> -I wrote for you guys a proper Collada exporter in a few lines of Code >>> that >>>> supported the full spec, you guys refused it to add it to mainline >>> Blender. >>>> -I insisted, the answer was "Yeah we can put it at some development >> repo >>>> and if anyone cares about it we move it to mainline". Of course, >> everyone >>>> was using FBX , so who would care about Collada? >>>> >>>> Now you cry that FBX is evil and blame Unreal, Unity and Autodesk. >>>> Now you complain that there are not any open standards being pushed. >>>> >>>> You know what guys? cry me a river.. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Feb 10, 2016 at 2:45 PM, Daniel Stokes <[email protected]> >>> wrote: >>>> >>>>> With regards to glTF exporting, we have a glTF exporter as part of the >>> Real >>>>> Time Engine addon project [1]. The exporter[2] output passes >>> validation[3] >>>>> for the glTF 1.0 (not sure if draft or final) specification. It is >>>>> currently missing animation support, and could have better support for >>>>> materials and textures. This weekend I will move this exporter out of >>> the >>>>> project it is currently in and in to its own repo so it can more >> easily >>> be >>>>> used for creating a simple glTF export addon. >>>>> >>>>> [1] https://github.com/Kupoman/BlenderRealtimeEngineAddon/ >>>>> [2] >>>>> >>>>> >>> >> https://github.com/Kupoman/BlenderRealtimeEngineAddon/blob/develop/brte/converters/blendergltf.py >>>>> [3] >>>>> >>> https://github.com/KhronosGroup/glTF/tree/1.0-final/specification/schema >>>>> >>>>> Regards, >>>>> Daniel Stokes >>>>> >>>>> On Wed, Feb 10, 2016 at 8:20 AM, Fabio Pesari <[email protected]> >> wrote: >>>>> >>>>>> On 02/10/2016 04:44 PM, Ton Roosendaal wrote: >>>>>>> A crowd-funder for 1 feature only is very risky. What precisely do >> we >>>>>> define to fund? Who would crowdfund a developer to just fix bugs and >>>>>> maintenance for 2 years? I doubt people would pay for that. I >> wouldn't >>>>> even >>>>>> know where to find such a coder... >>>>>>> >>>>>>> For 2.8 we can do a big fund raiser, and include this on the work >>>>>> planning. I think professionals rather see us to keep working on the >>>>> whole >>>>>> pipeline, starting with good PBR shader editing in viewports. >>>>>> >>>>>> Why don't you do a fundraiser organized like this: >>>>>> >>>>>> Feature X [---] >>>>>> Feature Y [---------] >>>>>> Feature Z [------] >>>>>> Maintenance [-----] >>>>>> Marketing [--] >>>>>> ========================================= >>>>>> Total [---------------------------] >>>>>> >>>>>> When people donate, they can choose where to put their money and if >>> they >>>>>> don't, it goes to "Maintenance" by default, so most donors will fund >>>>>> that. Also, any excess money from the implementation of other >> features >>>>>> also goes to "Maintenance". >>>>>> >>>>>> It'd be even better if there were set goals for each feature (for >>>>>> example, $40k for Feature X, and of course no limit on >> "Maintenance"), >>>>>> so people would know how much they have to donate in order to make >> sure >>>>>> the feature they need is implemented (with a disclaimer, of course). >>>>>> >>>>>> I think a lot more people are willing to donate if they know exactly >>>>>> where their money is going. >>>>>> >>>>>> I think generic fundraisers often fail because there aren't set >>>>>> objectives. The FSF recently managed to reach their goal because they >>>>>> set a reasonable one ($450k), and they aren't nearly as popular as >>>>>> Blender (you could say the industry hates them). >>>>>> _______________________________________________ >>>>>> Bf-committers mailing list >>>>>> [email protected] >>>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>>> >>>>> _______________________________________________ >>>>> Bf-committers mailing list >>>>> [email protected] >>>>> http://lists.blender.org/mailman/listinfo/bf-committers >>>>> >>>> _______________________________________________ >>>> Bf-committers mailing list >>>> [email protected] >>>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
