Export Mesh Sequence Cache modifier

[fire]

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

I have an blend file which is using the Mesh Sequence Cache modifier and I want it as a gltf.

Describe the solution you'd like

The solution is an ability to convert Mesh Sequence Cache modifier to shape keys, we assume same vertex counts. If the vertex count is different we have to split the blend shape into a different mesh.

Each animation frame is the mesh existing or collapsed to zero volume or a blend shape weight.

Describe alternatives you've considered
I don't have any other way of implementing this. Alembic is not an option.

Additional context

https://sketchfab.com/3d-models/alembic-cloth-d2303eebe3724b7080071e1f02d66692

Sketchfab has a way of doing this.

cloth_sim.zip Contains blend, abc and gltf.

See also #717

[alexfreyre]

for the cloth modifiers
there is an option to "save as shape key" so it apply a shape key and the modifier remains on its place, a bit of hand work and it can be exported as a .gltf
but this apply only to a cloth simulation inside blender not an alembic file

would be useful to have that feature for alembic files "MeshSequenceCache"

or the ideal would be to add support for convert alembic mesh cache directly as an animation with blend shapes frame by frame in a gltf file

[fire]

Once there is a MeshCache animation, you can convert it to blend shapes. Requirement requires same vertex count.

https://gist.github.com/fire/495fb6a35168500df53c002695a1f5fe

[donmccurdy]

I think I've done this workflow in the past by exporting to MDD, re-importing as shape key sequence, and then exporting to glTF. An automatic workflow would be nice... I would say this would require that "Apply Modifiers" be enabled, but that option prevents exporting shape keys. :/

If the shapes do not have the same vertex count, technically you could export each as a distinct mesh and animate through them (e.g. setting scale at 1 or 0). I've written a script to create an animation sequence like that offline but I'm not sure it's a good idea to put that sort of animation into the Blender exporter, it is pretty inefficient. So maybe we just require the same vertex count as suggested above.

[fire]

For the different every frame case, I think it's also possible to avoid scaling to zero and use a blend shape that collapses the mesh to a point so that the blend weight means zero volume.

[donmccurdy]

An engine may be able to optimize by not rendering a mesh with scale=0, but I don't think it would be able to detect that a blend shape collapses the vertices of that mesh — so I think your draw calls would probably be higher in that case.

[fire]

What does your framework do for each case? I wanted to pick a random framework.

[donmccurdy]

For an animation with N meshes for N keyframes, I would expect any framework to have N draw calls if the mechanism hiding a mesh is collapsed morph targets. Detecting the net effect of some morph targets, and dynamically hiding a mesh when every vertex is collapsed, would be expensive, I've never heard of a framework doing that.

If the scale uniform is zero for a particular frame, though, it seems reasonable to expect a framework to hide that mesh. Or in any case it would be inexpensive to detect it in userland code and hide the mesh manually. In that case you only have 1 draw call per frame, regardless of how many meshes / keyframes there are.

[fire]

That makes sense to scale to 0 then. What can I do to make this part of this addon?

[donmccurdy]

Does applying a Mesh Sequence Modifier ordinarily create an animated Shape Key sequence? If so, I don't think there would be any objections to fixing support for the shape keys when the "Apply Modifiers" option is enabled. That would handle the case where the vertex counts are the same.

If you need to also support the case where vertex counts are not the same, I am unsure what Mesh Sequence Modifier normally does when applied, or whether it is reasonable for this addon to use the "flipboard" scaling technique automatically. Perhaps a series of morph targets could also be used here, deforming unused triangles to 0,0,0. Either sounds a bit complicated to implement, and I'd be curious to hear from other maintainers whether we want to support that.