gpvigano / AsImpL

Asynchronous Importer and run-time Loader for Unity
MIT License
212 stars 37 forks source link

Support for other file formats #16

Open gpvigano opened 6 years ago

gpvigano commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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

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

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

@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 commented 4 years ago

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

gpvigano commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.