NDMF Sequence choice for tools impacted by SkinMesh Optimization

[Spokeek]

I'm opening this discussion regarding a issue i had with a tool from Haï here hai-vr/prefabulous-avatar#8

There seem to be a blur onto what we should use as an NDMF sequence step for tools that are based on the skinmesh.

In that case we have a tool that is "recalculate normals".

It is a "transforming tool", so it is placed in the transforming step, but this tool is impacted by the "Optimization" step tool from https://github.com/lilxyzw/lilNDMFMeshSimplifier that runs after in the sequence.

You can see in the linked issue that that makes the behavior of their tool act weird.

From what Haï says, the package was actually in the transform step but was moved to be compatible with "VRCFury's Blendshape Optimizer".

Maybe there is a need for a new step or something to be defined so we can make those kind of tools work together.

Tell me what you think of that.

[bdunderscore]

This is a bit of a tricky issue. Here we have an example of a pass which wants to run after optimizers, but to use information (blendshape labels) that optimizers typically delete as an input.

As background, VRCFury runs between Transforming and Optimizing; this is so that VRCF can be generally compatible with optimization tools such as AAO and TTT (and lil mesh simplifier as well!). Running it before Transforming would generally break MA's menu installer, which relies on menu assets remaining unchanged (and would break anything that relies on unused blendshapes as inputs!); running it after optimizing would break VRCF when those optimizers are present, so we're a bit stuck.

While I can theoretically provide a mesh manipulation API in NDMF that could be used to apply labels to vertices and make these kinds of mesh manipulation tools play better together, VRCFury is probably not going to onboard onto that, so they'd be lost at the VRCF stage (or if you're running d4rk's optimizer they'd be lost there as well). We also lose track of duplicated mesh/asset identity when VRCF replaces them, since VRCF isn't invoking the ObjectRegistry API in NDMF either.

Some not-so-great solutions that come to mind:

• Hash vertex positions (breaks if any vertices move, or if multiple vertices share a coordinate)
• Rely on vertex order (breaks if vertices are deleted or Mesh.OptimizeReorderVertexBuffer is invoked)
• Encode vertex identity in an unused UV or vertex color channel (likely to be deleted by certain optimizers; still requires tracking mesh identity so we can delete the UV channel later and avoid changing shader behavior)

@lilxyzw @SenkyDragon @hai-vr any thoughts?

[bdunderscore]

More thoughts: We can attach additional information to a mesh renderer by adding a label component to the game object. This could solve the problem of maintaining mesh identity while releasing control to VRCF. However, we still need to identify vertices across arbitrary mesh optimizations...

Identifying unchanged vertices will be relatively easy, but if two share a coordinate, then we're dealing with some kind of weird graph pseudo-isomorphism problem?

[bdunderscore]

Another option: Applying fake bone weights that are deleted (and converted back into mesh labels) later in processing...?

[bdunderscore]

@anatawa12 may be interested in any mesh API stuff too 😅

[Spokeek]

I'm opening this discussion as i believed it was interesting to push upstream, but i would be quite unable to provide any insights on how to resolve that issue. So i'll just be there watching. 🫥

[bdunderscore]

This is actually very relevant to some new features I was planning to implement in MA, so I'm glad you did! 😅

[anatawa12]

It is a "transforming tool", so it is placed in the transforming step, but this tool is impacted by the "Optimization" step tool from https://github.com/lilxyzw/lilNDMFMeshSimplifier that runs after in the sequence.

I could not understand this sentence well.
How the "recalculate normals" will be impacted by lilNDMFMeshSimplifier, that will run after the tool?

[bdunderscore]

Recalculate normals needs to run after mesh simplification for a smooth result, I guess? But if it runs late, it loses blendshape name to vertex mappings for unused blendshapes...

[hai-vr]

Hello,

It's currently unclear whether the visual artifact that triggered the creation of the issue at hai-vr/prefabulous-avatar#8 has anything to with execution order, it could have been just an XY problem where changing the execution order is a solution that might have hidden another problem.

Recalculate Normals adds delta normal data to blendshapes, in an environment where almost no avatar model has blendshape normals by default (exported models almost always have blendshapes with delta normals and delta tangents filled with Vector3.zero).

I currently do not have a personal understanding of lilNDMFMeshSimplifier mechanisms to know whether that project was designed to cope with models that do have blendshapes with non-zero delta normals and tangents in them, and I have not tried to reproduce that issue as of yet, so currently I cannot make a firm assessment of what's going on.

[Spokeek]

Maybe i was not clear enough in my statement, apologies for that.

As bd said, my assumption was that the issue i encountered was due to an ordering issue between the tools. But that was a mostly a starting point for this discussion, that is on how could be handled NDMF tools that are being impacted by mesh manipulation.

As written in the post Hai shared again, their tool already had to be moved between the "Transforming" and "Optimizing" step because of the unclear direction we have for tools of such kind and the impacts to other tools.
And this is why i created this discussion, so the topic can be raised, not to resolve my issue (even if it would be nice of course).

Edit: i have limited knowledge onto how most tools internally work and manipulate the mesh data, so i cannot help diagnose deep issues within the tools. I mentioned my issue as it felt to be a typical case of that problematic.