Support for other 3D file formats?

[justint]

Is there planned support for other 3D file formats (DAE, FBX, etc)?

[jbrettle]

We want to add support for more file formats. Interested in hearing requests around which formats to add next.

[bhouston]

I would suggest trying to stay with just individual mesh compression rather than handling scene graphs -- because trying to represent scene graphs and materials is a hugely problematic area. Instead I would focus just on mesh compression and decompression. Thus only support stl, obj, ply and other pure single mesh formats.

[waldyrious]

Perhaps OFF would be a nice addition, since it's so simple and similar to OBJ -- I suppose it could be relatively to extend the supported formats to include it, leveraging existing parsing code.

Same for BYU, although to a lesser extent since each line contains edges (6 coordinates) rather than vertices (3 coords).

Not sure how widespread (if at all) these are, though -- it may not be desirable to stimulate format fragmentation.

[vinjn]

Or add a assimp-struct-converter, then we support tens of formats for free.

[Meai1]

it would be better to offer some kind of plugin api so that i could add my own 3d format

[ngaloppo]

How about an encoder API and catch all of the above?

[yhydra]

I think In games, FBX would be the most useful since you can use it with skinned models.

[bhouston]

I would recommend against fully supporting an FBX file, but if the Darco project provided a means to create a darco resource for each unique mesh encountered in an FBX file and let another format handle the scene hierarchy, materials and animation, I'd be okay with that. I strongly believe that if you expand Darco to scene hierarchy, materials and animations you'll be lost in the weeds for years and the core file format will be less valuable and it will bring along too much additional baggage.

[yhydra]

@bhouston
That makes a lot of sense.

Lets say that Draco just handles the mesh, what file format could handle the hierarchy, materials and animation? And when you say scene hierarchy are you talking about just mesh instances?

[bhouston]

@yhydra There are tons of scene graph formats, ThreeJS for instance is a decent great one that I've contributed to. There is glTF that could just use Darco for the binary asset bundles. Or we at Clara.io handle the scene graph as well. Basically the issue with scene graphs if that there is tremendous variety of formats and features you may want in them and it is incredibly hard to get right, and then it becomes obsolete again as innovation continues. Individual mesh asset formats is not that type of challenge though, it is well defined and not a moving target. And it is easily composeable with various scene graph formats.

PS. I think most serious apps will have their own scene graph format that reflects their individual needs. Darco is composeable with that very easily.

[yhydra]

@bhouston

Thanks for the explanation. I use Playcanvas for html webGL and the scene graph works well, also uses Json files for the model and same for the animations, so i understand what you're saying.

Q: So currently i can convert fbx to skinned .obj ( with .anm?) and encode to draco file format and use that with json animations ? Is that the correct route?

[scottmsinger]

The question sort of becomes - is it a file format or is it a compression scheme? I would love to see Alembic support, but that might just be too much to support.

[ondys]

Draco library provides an API that can be used to encode mesh and point cloud data from any source. Currently we have a built in support for PLY and OBJ files, and we plan to support more formats. It should be also pretty straightforward to integrate Draco into third party scene graph data structures (that's something that would have be done by maintainers of the scene graph libraries). We currently don't have plans to support scene graphs as an integral part of Draco.

Note that in many cases, it is better to use the decoded Draco data directly rather than converting it back to some standard file format. For example, if the goal is to use a mesh in WebGL app, its better to use the decoded Draco data to directly fill the target GL buffers or threejs data structure (as opposed to converting the data back to, let say PLY, and then parsing the PLY). An example of threejs workflow is provided here.

[iceberg1370]

I would love support for the dae format (Collada) since it’s used for Interchange between other formats so much

[scottmsinger]

I think the key is to make it easy to integrate into pipelines using industry standard DCCs (Maya, Max, Houdini, etc). The best way to do that is to probably to provide a high level Python API for building the geometry. Most DCCs have Python bindings for accessing and looping over their internal geometry descriptions. Keeping it in C++ leaves out small dev studios without dedicated R&D teams and means they have to integrate it as a plugin to the DCC which can be a real barrier to entry for studios made up of technical artists.

[donmccurdy]

I would love support for the dae format (Collada) since it’s used for Interchange between other formats so much

Hi @iceberg1370, This would be a bit analogous to compressing a .PSD (photoshop) file with its edit history intact — you certainly could, but a .JPG would be a better starting point. COLLADA is great as an interchange between tools and formats, but not ideal as the final delivery format. The Khronos Group (authors of COLLADA) is developing another format for that purpose, glTF, and there is active work to include Draco there. I think that COLLADA -> COLLADA2GLTF -> glTF+Draco will be a good solution for the need you're describing here.

[iceberg1370]

@donmccurdy you make some good points. Unfortunately I am using Apple SceneKit which only supports their own scn format or the dae format. Apparently Xcode compresses the dae locally but I need to send over the wire. Dae compresses well as zip, but would be even better I take it with Draco. It’s seem unwise perf wise (than zip) to send it natively as Draco and then convert to dae to work around it. I can ask Apple to support other formats, but native dae support would be nice despite it being a psd style format. In my case no edit history would be saved, it’s just a model format.

[FrankGalligan]

Closing due to inactivity.