Yes I am also looking at this from game dev angle. Collada did not come exactly from emptyness there as Sony made it for getting data in for PS games..
We've also always used engine specific formats, earlier Ogre's formats and now Three.js's JSON. Those always worked so Collada never seemed necessary. However, the reason we've touched also Collada recently is Khronos's glTF. That works so that Collada is converted to json + binary (gl buffers, optionally with mesh compression) + glsl sources. It is basically made for straightforward fast loading to (Web)GL. Has worked well in our tests -- exporting skeletal animations from Blender as Collada & converting with collada2gltf and playing back with both their reference webgl viewer & the gltf loader they made for three.js. One motivation for us to possibly use glTF in the future (with realxtend.org) is that have understood that Autodesk tools already have good (enough) Collada exports. So e.g. the three.js community wouldn't need to maintain exporters for all the modeling tools. And in our tests so far Blender's Collada export is fine for it too. I'm however not totally convinced and so far we still usually use engine specific formats. Also because glTF spec is not finished yet. Another reason is that if there's a prob it is easy to modify the py written three.js json export. Not equally so with Collada in blender & collada2gltf converter, both c++ using the OpenCollada lib. But it still seems that Collada might possibly be useful this way. If glTF becomes successful I'm not surprised if we some day have a direct export from Blender to that and skip the intermediate step as Collada.. About the spec I don't really know, have understood that they've made it more straightforward and fixed some probs of Collada in glTF but it's largely similar too (used to be called collada-json). @Campbell - cool to hear that FBX maps to Blender well. If it's a sane format perhaps it is ok for it to become standard .. by Blender folks reverse engineering and documenting it :p . Even if it's not publicly specified by Autodesk I suppose they can't break it as then many apps with support for it would break .. unless they'd require always using updated versions of the SDK. ~Toni On Fri, Apr 25, 2014 at 4:41 PM, Ton Roosendaal <t...@blender.org> wrote: > Hi, > > Obviously, but a lot of game makers use special engines with own formats and > are quite happy to directly use Blender python for export. > > For game makers we should keep fbx to work too - but even better would be if > they start directly supporting .blend files. I'd love to see efforts for that. > > -Ton- > > -------------------------------------------------------- > Ton Roosendaal - t...@blender.org - www.blender.org > Chairman Blender Foundation - Producer Blender Institute > Entrepotdok 57A - 1018AD Amsterdam - The Netherlands > > > > On 25 Apr, 2014, at 15:33, Benjamin Tolputt wrote: > >> On 25/04/2014, at 10:37 PM, Ton Roosendaal <t...@blender.org> wrote: >> >>> What Alembic would offer - just baked meshes - is probably the best future. >>> Any serious attempt to match rigs, constraints and modifiers between 3d >>> apps is doomed anyway! :) >> >> This might work for uses related *solely* to still picture & animated film >> development, but it does pretty much strand the game development folks >> trying to use Blender as an option in their pipelines. Animated armatures >> with skeletally attached meshes being imported and exported into/out of >> Blender is kind of essential for this area of Blender use. >> >> -- >> Benjamin Tolputt >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers