ADD ability to Export from code and not only Menu Entries

[MatthieuKiskonen]

Is your feature request related to a problem? Please describe.
Ability to Export a gameobject from code and not only from MenuEntries

Describe the solution you'd like

MenuEntries.cs should be made public and public Export function should be added. This can probably replace existing Export method as the path is optional parameter so non breaking.

public static void Export(bool binary, string name, GameObject[] gameObjects, string path = "")
        {
            var extension = binary ? k_GltfBinaryExtension : k_GltfExtension;
            path = EditorUtility.SaveFilePanel(
                "glTF Export Path",
                SaveFolderPath,
                $"{name}.{extension}",
                extension
            );
            if (!string.IsNullOrEmpty(path))
            {
                SaveFolderPath = Directory.GetParent(path)?.FullName;
                var settings = GetDefaultSettings(binary);
                var goSettings = new GameObjectExportSettings { OnlyActiveInHierarchy = false };
                var export = new GameObjectExport(settings, gameObjectExportSettings: goSettings, logger: new ConsoleLogger());
                export.AddScene(gameObjects, name);
                var success = AsyncHelpers.RunSync(() => export.SaveToFileAndDispose(path));

#if GLTF_VALIDATOR
                if (success)
                {
                    var report = Validator.Validate(path);
                    report.Log();
                }
#endif
            }
        }

[atteneder]

Hi,

In general, exporting via script has been available for some time now (see documentation), so the title and feature description is too vague. Can you state more precisely what the actual use-case and benefit is?

Looking at your snippet (which btw I added a proper code block, so it's formatted nicely) I see it's about Editor export and you'd like to re-use the "save to" dialog (which remembers the last destination) as well as some boilerplate to run the async export method, but you'd like to provide your own set of GameObjects, right?

I'm just wondering whether

1. This is really in high demand an worth adding/maintaining.
2. In the long-term there's a better vision when it comes to export dialoges (e.g. offering more settings)

Thanks

[MatthieuKiskonen]

Good morning,

The use case if fairly simple:
We create complex environments using glbs with blend shapes and multiple sub objects.
After which we want to output a combined cleaned up version, Skinned meshes are baked, unused variants are deleted and the result is exported as single glb.

The maintenance on this feature is nil, it uses existing code and only requires 3 changes:

1. Make menu entries a public class
2. Make export a public method
3. Add optional path to be provided to skip dialogue.

This has no effect on the export dialogue as it would still go through the same code.

Thanks,

[atteneder]

Thanks for clarifying,

In your example code the dialog is opened regardless whether a path is provided which, according to your third point, is not the intention. That explains things.

MenuEntries currently breaks the S for single responsibility in SOLID already, so I definitely won't make it or any of its members public. The Export method would need to be extracted into a dedicated static class (name suggestion GltfExport or GltfUtils).

The maintenance on this feature is nil.

I couldn't disagree more. Every line of code needs to be maintained, tested (ideally automatically and periodically) and more importantly every public API symbol cannot break during a major release cycle! It may be reasonable to argue the cost is negligible in this case though.

That being said, would you like to champion this work and draft a pull request here?