Bug report: Shade Texture should always be assigned on export.

[lyuma]

Describe the bug / バグについて In UniVRM, Shade Texture is always set to the same as Main Texture by default. (unless manually overridden)

However, In Blender, Shade Texture will be exported null unless manually assigned. This causes bad lighting.

To Reproduce / バグの再現方法 Steps to reproduce the behavior:

1. Switch material to MToon
2. Assign texture in MainTexture slot
3. Export VRM
4. Open in Unity or another application and change lighting.

Expected behavior / 期待する動作 I expect all materials with a Main Texture to also have a Shade Texture assigned.

Due to how MToon shader works, a material with Shade Texture null will not show shading correctly. Therefore, it would produce better results to assign a Shade Texture on export, either customized or matching the Main Texture.

Screenshots / スクリーンショット

Left/左: Blender export. Shade Texture set to null | Right/右: Materials edited in Unity to have same Main and Shade texture

Lighting is less visible on the left side, even though all other material settings are the same.

MToon node graph:

Desktop (please complete the following information) / PC環境情報

• OS: Windows
• Blender: 2.93.6
• Addon Version: 2.1.15

Additional context / なにか他に書いておきたいことはこちらへ Add any other context about the problem here.

I maintain Godot-vrm, which has a bug when Shade texture is unassigned. (I just filed https://github.com/V-Sekai/godot-vrm/issues/36 ) Because this case can never happen in Unity exports, I did not notice it until now.

[saturday06]

Hi!

In UniVRM, Shade Texture is always set to the same as Main Texture by default. (unless manually overridden)

Latest UniVRM 0.97.0 doesn't do that and in this situation Shade Texture becomes null. Here is my workflow. Please check if anything is wrong.

1. Open Unity 2021.2.11 and install UniVRM 0.97.0

2. Import this https://github.com/saturday06/3d-model-test-resources/raw/1fe870c69c8eed03fb9910e5fa83b3fd4d5bdb7e/vrm/in/sphere.vrm model, Add it to current scene

3. Select "Sphere", Change material to VRM/MToon

4. Click "▶"

5. Download image: and import it as a texture and assign it to the main texture (Lit Color, Alpha)

6. Export it as a VRM, change it's file name extension to ".glb". Open it with Visual Studio Code + glTF Tools, See extensions.VRM.materialProperties[0].textureProperties

We can see that "_MainTex" exists but "_ShadeTexture" does not.

[saturday06]

May, there is a bug that the VRM Add-on ignores _ShadeTexture when importing under certain conditions....?

[iCyP]

https://github.com/vrm-c/UniVRM/commit/3d2e1ce39537522881ac4e38785ca07bec3ea775 // google translate sorry. I think the above spec change is related to this issue.　Also, I haven't tracked this change. I couldn't reproduce it with a simple model. ~~However, in the copyright protected model, I have confirmed that uniVRM assigns lit texture by ignoring the shade texture setting.~~ this is wrong, WIP...

上記の仕様変更は、この問題に関係していると思います。また、この変更を私は追跡していません。 単純なモデルでは再現できませんでした。 ~~しかし、著作権保護されたモデルにおいて、uniVRMはshade textureの設定を有無種類を無視してlit textureを割り当てる場合を私は確認しています。~~ 見間違えかも。調査中...

ADD Top link comments in JP means fix of affected by bugfix of GI with VRM0.0 to 1.0. GI fix caused problem that model it don't have shade texture has broken shading as correct. So, VRM1.0 will migration it by attach lit texture to shade texture, if don't have it.

I think below is GI fix PR. https://github.com/vrm-c/UniVRM/commit/8266498e2ebbe2cf06c28d2611fcaa2ef3607851 Then, unity( and UniVRM1.0) behavier of this issue is for VRM1.0, not VRM0.0. And currenty, this Blender Addon is export VRM0.0.

[saturday06]

// deepl translation! Oh, I see...thanks for the info! I'm going to stick with that policy for VRM 1.0 exports, which I plan to implement in the future. I am wondering what to do about VRM 0.0.

そうきましたかぁぁ、情報ありがとうございます！、将来実装予定のVRM 1.0エクスポートはその方針でいくとして、VRM 0.0はどうするか悩ましいですねぇ。。。

[iCyP]

I think, IO can export same file as possible from imported. So, I won't attach shade texture if shade texture is null when export 0.0. Otherwise, it may look different before and after IO, and user will be confused.
And follow migration role for 0.0 to 1.0.　I think like this, if I'm owner. But owner is you @ saturday06 , I commend to you.

自分ならIOは同じものであるべきだと思うので、0.0では対応しません。見た目がIO前後で変わる(可能性がある)事こそ混乱すると思います。 1.0出力の際にほかのマイグレーションと同様に変えます。 が、今の主はあなたなのでお任せします。 issue主さんのuniVRMがなぜマイグレーションを含む動きができて0.0で書き出せるか1.0系で出せて読める環境があるのかが分からないので分からないですけど...(ねむい

@lyuma Your UniVRM behavior looks like include migration of VRM 0.0 to 1.0. For consideration, Please tell us. Where is your uniVRM come from and version and VRM version(0.0 or 1.0beta)?

[saturday06]

Implementet for VRM 1.0: https://github.com/saturday06/VRM_Addon_for_Blender/blob/2_6_0/io_scene_vrm/exporter/gltf2_addon_vrm_exporter.py#L1009-L1013