You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is an example showing the issue. This affects VRM models with no _ShadeTex set in a MToon material:
Left = both main & shade texture are set.
Middle = only main texture, with bug fix.
Right = only main texture, current state.
There was a line commented out in mtoon*.shader. Uncommenting this line seems to fix the issue:
shade =min(shade, lit); ///// Mimic look of non-PBR min() clamp we commented out below.
I'm not sure why this line was left commented. I wrote it as a workaround to avoid taking min() of the final lighting output (to avoid the clamped lighting problems we commonly see in VRChat and LDR platforms)
The reason we haven't encountered this before is this only causes problems on models with Lit texture assigned but Shade texture unassigned. The Unity shader inspector for MToon automatically assigns shade texture. Blender export, however, does not... which is really a bug with the VRM addon for Blender.
Also, with this change, materials will look more bland when shade texture is unassigned, because the min() happens after multiplication with shade color, rather than before.... but I tested in Unity and see the same behavior there so I think it's correct:
It might also be worth filing a bug against VRM-Addon-for-Blender, since these generated materials will have very bland shading which the author probably did not intend.
The text was updated successfully, but these errors were encountered:
This issue was really a problem with the asset creation flow, and not an issue with the importer.
As far as creation workflow, I think this has been addressed upstream in the Blender tooling (And UniVRM already made this easy to get right), so I'm not sure if we have any issue to solve related to import. Assets in the wild do not have this problem, just the ones I created by hand using an unusual workflow.
Note that since Godot has VRM export, the same issue is possible there. We also should probably add a workflow for conversion between Standard and MToon shader (and back).
When we do this, then it would be an appropriate point in such workflow to duplicate the Lit texture to the Shade texture slot.
Here is an example showing the issue. This affects VRM models with no _ShadeTex set in a MToon material:
Left = both main & shade texture are set.
Middle = only main texture, with bug fix.
Right = only main texture, current state.
There was a line commented out in mtoon*.shader. Uncommenting this line seems to fix the issue:
I'm not sure why this line was left commented. I wrote it as a workaround to avoid taking min() of the final lighting output (to avoid the clamped lighting problems we commonly see in VRChat and LDR platforms)
The reason we haven't encountered this before is this only causes problems on models with Lit texture assigned but Shade texture unassigned. The Unity shader inspector for MToon automatically assigns shade texture. Blender export, however, does not... which is really a bug with the VRM addon for Blender.
Also, with this change, materials will look more bland when shade texture is unassigned, because the
min()
happens after multiplication with shade color, rather than before.... but I tested in Unity and see the same behavior there so I think it's correct:It might also be worth filing a bug against VRM-Addon-for-Blender, since these generated materials will have very bland shading which the author probably did not intend.
The text was updated successfully, but these errors were encountered: