NaNimation is causing wrong materials

[jerryzmtz]

I have encountered two issues that does not exist before optimizer 3.5.0

Environment: VRCSDK 3.5.1 d4rkAvatarOptimizer 3.5.0 VRCFury 1.795.0 NDMF 1.3.6 poiyomi 8.1.167 liltoon 1.7.2

To reproduce

1. NaNimation is causing some the meshes to be pure black when I use poiyomi and liltoon at the same time. I have made animations to change the min brightness of poiyomi and liltoon materials, but it should be no way to make liltoon materials to be pure black like this. I don't know how to specify the exact issue. This issue will not occur if only I cancel NaNimation. Without NaNimation:

2. FaceTracking seems to break after optimizations. This does not happen if I test avatars in play mode (NDMF+VRCFury executed) or baked avatars (NDMF bake avatar+VRCFury build test avatars) without d4rkoptimizer. Without optimizations:

TrashBin.zip VF_Sotai_Chiffon_max_11bits_Clone_Clone.zip

[d4rkc0d3r]

Ok, for face tracking I have an idea what causes it. Seems like it is animating Animator parameters in there and the way I check if bindings are animatable doesn't find that so it deletes all of that. Should be easy to fix...

For the other issue I would like some additional info from you:

1. What material/shader are the socks?
2. What material/shader is in the first slot of the same mesh as the socks after merging.
3. Screenshot of the list of materials in the merged mesh that include the socks.
4. Screenshot of the merge preview around the socks mesh/material after baking NDMF/VRCFury but before optimizer runs.

[d4rkc0d3r]

Try 3.5.1 to see if it fixes the face tracking.

[jerryzmtz]

Additonal points:

1. I could bake NDMF dependently but could not separate VF bake and d44k optimizations. When I bake VF, d4rk is triggered. It seems that sometimes d4rk could be triggered respectively, sometimes not, I could not understand the rule. When I open the issue, I could separate VF and d4rk, but I could not do it now.

2. Only when I enter play mode, will the socks become pure black. So probably the lightness is animated. But I have never animated liltoon to be black. I do animate the lowest lightness of liltoon and the multiplier of the lightness of poiyomi.

3. The material of the socks is liltoon.

4. The first slot of the same mesh where socks belong to is poiyomi.

5. Screenshot of the list of materials in the merged mesh that include the socks.

6. Screenshot of the merge preview around the socks mesh/material after baking NDMF/VRCFury but before optimizer runs.

[jerryzmtz]

Try 3.5.1 to see if it fixes the face tracking.

FaceTracking is all right in Unity. Thx

[d4rkc0d3r]

1. I could bake NDMF dependently but could not separate VF bake and d44k optimizations. When I bake VF, d4rk is triggered. It seems that sometimes d4rk could be triggered respectively, sometimes not, I could not understand the rule. When I open the issue, I could separate VF and d4rk, but I could not do it now.

Simply uncheck the Optimize on Upload checkbox on the optimizer and I think fury will not run my optimizer when building the test avatar.

2. Only when I enter play mode, will the socks become pure black. So probably the lightness is animated. But I have never animated liltoon to be black. I do animate the lowest lightness of liltoon and the multiplier of the lightness of poiyomi.

Yes, once again I suspect some weirdness of WD ON material property animations. Here the problem seems to be that the first material of the merged mesh is poi while the socks get merged in later and are lilToon. If the poi material doesn't have the property you animate for the socks, then its default value will be 0 instead of what is set on the socks initially. But I need to investigate that a bit further to verify that.

Thanks for all the info so far!

[jerryzmtz]

1. I could bake NDMF dependently but could not separate VF bake and d44k optimizations. When I bake VF, d4rk is triggered. It seems that sometimes d4rk could be triggered respectively, sometimes not, I could not understand the rule. When I open the issue, I could separate VF and d4rk, but I could not do it now.

Simply uncheck the Optimize on Upload checkbox on the optimizer and I think fury will not run my optimizer when building the test avatar.

2. Only when I enter play mode, will the socks become pure black. So probably the lightness is animated. But I have never animated liltoon to be black. I do animate the lowest lightness of liltoon and the multiplier of the lightness of poiyomi.

Yes, once again I suspect some weirdness of WD ON material property animations. Here the problem seems to be that the first material of the merged mesh is poi while the socks get merged in later and are lilToon. If the poi material doesn't have the property you animate for the socks, then its default value will be 0 instead of what is set on the socks initially. But I need to investigate that a bit further to verify that.

Thanks for all the info so far!

Thx for your instructions. And here probably is a related issue:

1. Emission of face (the green material) is animated to none after optimizations in play mode. The optimized copy in editor or NDMF/VF baked copy of the original avatar looks good.

The face has two materials:

1. Poi transparent material without emission session (Red). Appears as the first material in combined mesh.
2. Poi opaque material with emission session(Green)

I tried to fix this by enabling the red material's emission sessions, but it does not help. I also have tried to enable the emission session of the Shoes' material (VRCFury Material for shoes_lime Poiyomi Toon Outline), which also appears to be the first material of the combined mesh , it did not help either.

This avatar also mixes liltoon shader and poiyomi shaders, and have the "pure black" issues at first. The "rose" is once pure black. But the "pure black" issues are gone after I changing some of the liltoon shaders to poiyomi shaders (shoes material?). It is weird that only parts of the liltoon shaders will get pure black when the issues occur... And it could be fixed by turning some of the materials into poiyomi. If I could unify all the materials, this issue does not happen, but I need to use Liltoon two pass transparent, so I have to deal with this...

TrashBin.zip 20240302-134848.zip

[jerryzmtz]

I doubt this is a new issue since v3.5.0: Reduced generated shader complexity handling material property animations. As I am keeping met issues with material property animations applied for poiyomi like _RimEnviroIntensity, _EmissionStrength. which is not a problem in the previous version. And this is probably triggered when the merged mesh has poiyomi shaders and other shaders together