Rework importer/exporter mechanism with a more modular approach

[Frooxius]

Is your feature request related to a problem? Please describe.

Right now importers/exporters (for models, images, videos and more) are mostly hardcoded and switch statements. This is making the code harder to work with, which includes adding support for more import/export formats and features.

The import/export functionality is also largely limited to what we implement officially, making it hard to extend. However this feature could in particular benefit from additional community importers and exporters for wide variety of formats, whether more popular or more niche.

Describe the solution you'd like

The goal is to restructure importer/exporter system into a more modular approach, where each importer/exporter is a more self contained unit with an interface.

This interface can be queried for types of formats it supports, with optional call to provide sample data (e.g. MIME or file header) to see if the importer/exporter is able to handle particular format.

Those importers and exporters can be dynamically registered with a central system for managing this functionality. When user tries to import or export data, the supported modules will be queried, to see which ones would be able to handle given file/data and user will be provided with a selection of compatible ones.

The interface will then provide a method to setup UI to configure the import/export options and handle the actual import/export process.

With this kind of system, we can separate out the importer/exporter code into separate plugins. Those could be more easily extended or modified by the community. Similarly community can write custom importers/exporters from scratch, adding support for additional file formats or writing very customized/specific ones for particular projects.

Describe alternatives you've considered

There is not much in terms of alternatives other than keeping the current system, which is hard to manage and extend.

Additional Context

Once we have separated out and rewritten out official importers/exporters, we can consider open-sourcing them, allowing for direct community contributions and using them as basis for implementing custom ones. However this is a bigger project down the line.

Similarly once a workshop is implemented, importers/exporters could be distributed and easily searchable.

[Banane9]

Would it be fair to assume, that it would be similar to how one can define custom converters for types when using e.g. Newtonsoft's Json.net?

[Frooxius]

I think somewhat yes. You'd probably define custom class/interface for the system to pick it up. Details aren't fully hashed out yet, but it will be some sort of interface that you need to implement. As long as you do that, you can pretty much do whatever in it.

[Banane9]

Sounds good, especially if adding them would not change the version like plugins do - there's a few mods that could be ported to that system then, probably.

[Frooxius]

There's some more changes related to that that I haven't made issue on. But yes, it would not change the version.

[EmergencyTemporalShift]

Could this be similar at all to the Android, "what do you want to use to open this file" dialog? With settable/resettable defaults?

[Banane9]

Could this be similar at all to the Android, "what do you want to use to open this file" dialog? With settable/resettable defaults?

I suspect it's unlikely you'd have multiple importers covering the same filetypes - but it's probably still something worth considering if multiple importers match

[Frooxius]

Yes, it would be in the similar vein to that. If you have multiple importers that can handle given file/data, you'd be able to pick which one you want to use to process it.

[epicEaston197]

Will we finally be able to export models with rig and mesh data for example blend shapes?

[Frooxius]

That's not part of this rework, but a separate feature. However you'd be able to make an exporter that does this or extend ours to do it (assuming we won't implement that feature before this).