material の emissiveFactor が HDR Range の値を扱えるように拡張する定義の提案

[Santarh]

前説

VRM の Material 定義は glTF 2.0 の Material 定義に依存しています。
したがって以下の material.emissiveFactor の制約にも依存しています。

https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#materialemissivefactor

ここでいう制約とは次の文、つまり要素のとりうる値を [0, 1] に制約するというものです。

Each element in the array must be greater than or equal to 0 and less than or equal to 1.

実際に、この制約を満たすための UniVRM 実装は以下の PullRequest で行われています。

vrm-c/UniVRM#102

ここまでが、前提の話です。

問題の提起

実際的なユースケースにおいては emissiveFactor の要素の取りうる値は 1 を超える場合が多いと思われます。
したがって glTF 2.0 の [0, 1] への制約はかなりの表現力制限となってしまいます。
実際に glTF 2.0 の specification に対する issue としても、以下で議論されています。

KhronosGroup/glTF#1083

しかしこの議論の争点にあるように 1 を超える値を扱うには「それが何のパラメータであるかの単位」を明確に定義しなければならず、波及するポイントが多岐にわたります。
この懸念については私も同意するので glTF 2.0 への導入はいまのところ不可能だと考えられます。

ただしそういった懸念を考えてもなお、 VRM というスコープにおいては emissiveFactor が 1 以上の値を取ることは必須であると考えます。
なぜなら VRM は Toon つまり単位が明確ではない NPR 表現を定義にすでに含有しているからです。
また、実際に現在作られている VRM の作成例にも emissiveFactor が 1 以上の値になっているマテリアルのアバターは多いと思います。

したがって、以下のような定義を提案します。

提案

material に対する拡張 VRMC_materials_hdr_emissiveFactor

内包するプロパティ

Name	Type	Description	Required
emissiveFactor	number[3]	The HDR emissive factor of the material.	Yes

VRMC_materials_hdr_emissiveFactor が存在するときに期待する動作

• 対象 material の material.emissiveFactor を上書きする形で解釈・インポートする

[0b5vr]

以下のコメントでは、追加のプロパティを number で定義し、既存の emissiveFactor との乗算を行う提案が成されているようですね。
今回、これとは別に独立した number[3] のパラメータでオーバーライドする形での提案を行った理由が聞きたいです。

KhronosGroup/glTF#1083 (comment)

個人的には、提案のようにオーバーライドするのが仕様としては扱いやすそうと思っていますが、
一方で number 一個で仕様を定義しておくと、本拡張に対応していない環境に対しても少なくとも色味は維持されることが保証できて良いかもなと思いました。

[Santarh]

オーバーライドする形の提案を行ったのは、仕様の明快さ、そして Exposure などの累乗計算での浮動小数点数の計算誤差を嫌ったためです。
ただし 64bit 浮動小数点数で計算するなどすれば特に気にするほどでもないかなとは思います。

また HDR Color を emissiveFactor に変換する際の色味の保持は、VRM Exporter 時の責務であり、オーバライドするか否かに対しては関係ないと考えます。
しかしたしかに emissiveFactor にどう丸めるかというのは、仕様にはできないまでも、指針として明示する必要はたしかにありそうです。

現状の UniVRM の Exporter 実装は RGB コンポーネントの最大値で割るという実装になっていて、色味が保持できそうですね。
vrm-c/UniVRM#102

[Santarh]

@fms-cat こちらの Issue ですが、既存の VRM 0.x MToon を表現するのに必須の拡張となっています。
現在の VRM 1.0 MToon の定義としては material.emissiveFactor を参照するからです。

したがって、議論を Future から戻していただけると嬉しいです。

[0b5vr]

技術委員会で議論を行いました。
以下の理由で、VRMCで独自にemissiveFactor拡張を設ける方針とします。

• HDR values for emissiveFactor?  KhronosGroup/glTF#1083 の決着がまだついていない
• アバター表現に強めのemissiveが不可欠である
• 本拡張なしにVRM0系のMToonをマイグレーションするのが困難である

また、拡張はMToonだけでなく他のマテリアルにも適用することができるものとする方針です。

[ousttrue]

Unity の画面ですが Emission の Intensity を記録するのとよいのでは？

[ousttrue]

これは UI で値としては残らないらしい。仕様作ります。

[ousttrue]

選択肢として

• hdr の emissiveFactor をそのまま格納する float[3]
• emissiveFactor に対する乗数値を格納する float

がありました。相談して後者を取らせていただきました。

@fms-cat

• 実装方法(float[3] or float)
• 拡張名
• 変数名

等の確認をよろしくお願いします。

[0b5vr]

要旨は #280 で達成されました。クローズします。