Support for other file formats

[gpvigano]

Even if the only supported format is currently OBJ, the idea is to create a common framework on which the support for other formats could be developed, allowing the exchange of data with other applications.
I created this issue to collect suggestions about the support of new formats, maybe with an hint about the implementation.

[Damerzone]

Hi Giovanni,

It could be cool to implement FBX format. I'm working on low poly model for hololens dev and that's the best format we can use ! 😄

[gpvigano]

FBX support in AsImpL? It should be great! But...

You really hit a nerve, for a number of reasons.

• There are no plans to port the FBX SDK to work on Android at this time.
• FBX SDK is not open source
• It is written in C++, even if several C# wrapper exist.
• Autodesk does not provide any file format specification for FBX
• The license of FBX SDK prevents to repackage and distribute it without written consent by Autodesk.
• Alternatives to FBX SDK are incomplete and do not well support the numerous versions of FBX.

My feeling about FBX support in AsImpL is that we will never be able to develop (and maintain) a complete and full-working support for this format.

If we opt to FBX SDK we must be aware about license issues: we can't include it in AsImpL and we must handle the support for the different platforms.
We also cannot forget the lack of support for Android, thus, to prevent binding AsImpL to only the platforms supported by Autodesk FBX SDK, we should provide the support in AsImpL as a separate extension, so we will not break the Android support in AsImpL.

We could try to develop FBX support from scratch or from one of the existing "Autodesk-free" projects (like https://github.com/mpreble/UnityFBXImporter or https://github.com/izrik/FbxSharp). These projects anyway have a limited support for only a few ASCII FBX formats (this is perfectly understandable, due to the previously mentioned reasons).

This would be a huge work, but this does not prevent someone who needs it to start developing a even limited support for his/her needs, I am available to collaborate, as much as I can, from the AsImpL core library side. As you can see the current data structures cannot hold all the features coming from FBX or other formats, anyway an extension is obviously required for supporting new formats. Furthermore changes are needed to import the new data to Unity scene.

[yosun]

Regarding Android - it seems that you can just cross compile C++ to anything... There is also an FBX importer asset that seems to support Android, though I have no tried it yet. They don't support WebGL yet. https://assetstore.unity.com/packages/tools/modeling/trilib-unity-model-loader-package-91777

[gpvigano]

Thank you for your suggestion, I'm quite busy now, but it sounds interesting, I'll have a look on it as soon as I have enough time. In the meanwhile, anyone who wants to try it and give us a feedback is welcome...

[gpvigano]

@yosun I had a look to the plugin you suggested and I noticed that it is based on assimp and other open source projects.
I'd like to buy it and see how it works, to reuse something in AsImpL, but I'm afraid that in this way I can violate a copyright...
Probably the only solution is to directly bind to assimp, but I guess this would be a huge work, or maybe starting from a porting to .NET, even if not up-to-date with the latest version of assimp.

[ChanpisethLim]

@gpvigano , Could you tell me all the OS that AsImpL support?

[gpvigano]

@Sethsaki I tested AsImpL on Windows Standalone, Universal Windows Platform, Android and @yosun provided PR #28 #29 #30 to make it work with iOS. I have no feedback about Linux, I think it should work (any feedback from GitHub's community?).

P.S. You have chosen this issue (Support for other file formats) to ask this question, so if your question was actually about 3D model formats the answer is: currently only OBJ. Otherwise, if you prefer (e.g., to get other feedback), you can create a new issue related to OS support.

[eldamir]

What do you think about DAE format? It is supposed to be pretty widely used, and it is just XML, so it shouldn't be too tricky to parse?

It would mean making a loaderDae similar to loaderObj and strapping it into the menu, and then it should be good, right?

[gpvigano]

COLLADA DAE could be a choice because SDK is open source (FBX has a restrictive license) and support model hierarchy and animations (OBJ has only groups and no animation).
Anyway it's not that easy...
Some years ago I wrote a DAE loader for an OpenGL-based application (using COLLADA-DOM), but the implementation was really hard (and at one point I started developing with Unity, so I gave up and I never used it for my projects).
Anyway I think a problem in that case could be the mapping from the external DAE parser and AsImpL data structures. The current data structures in AsImpL are not able to hold more data than what OBJ supports, so they must be extended.

[gpvigano]

A format that is catching on is glTF (also supported by Unreal Engine editor), available with a Unity package. I already successfully used it with AsImpL in my OpenVISDIVE project.