馃摏 Export/Import Type Tagged .morphtarget
GLTF
#1196
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minimal, unstructured scaffolding to import/export type-tagged GLTFs. Since this is more involved than is ideal, export is just supported for
.morphtarget
(so that it is distinct from a.mesh
export.)You can, however, use file naming to avoid having to select the import format for GLTFs.
BUT
Rather than try to surgically fix things here and there, I think the best option is to:
Get rid of the separate Mesh, WithRig and Multimesh exports and just treat everything as cases of Multimesh in a single code path (which is what import does on the return trip.) This also needs a better UI, but should work transparently anyway. -> Doing this in 鈾伙笍 Experimental Unified Mesh Exporter聽#1197
Try to separate import/export data handling from the filesystem ops, either by returning data streams from the exporters, or by passing in a fs context that cannot be changed downstream.
Then maybe doing something more.