vMaterials のパラメータを変更する — MDL バリアントと「関数と記述」の話

Posted at 2026-07-04

Zennの投稿数の上限にひっかかる

Mental Rayの教育利用として、一日がかりで検証してきたところ、Zenn運営にストップをかけられてしまった。検証しながら進めていたにもかかわらず残念なところです。どうもAIによる乱造と見なされているようです。たぶんAIレビューで、改善点が出てこない記事はアラートしているのではないでしょうか。以下、NVIDIA vMaterialsの2000種類のマテリアルの使い方です。いろいろわかって面白いところです。ありがとうございます。

フリー版 mental ray standalone で MDL を動かすシリーズの第 3 弾

第 1 弾: 自作 MDL の呼び出しと _proto_mtl の発見
第 2 弾: vMaterials の呼び出し

vMaterials のマテリアルはそのまま呼べるようになりましたが、当然
「微妙に色を変えたい」「粗さを調整したい」という欲が出てきます。
大元の .mdl を書き換えるしかないのか?——答えは No で、MDL には
まさにこの用途のための言語機能、**マテリアルバリアント(variant)**があります。

本記事ではバリアントによるパラメータ変更の実践と、その過程で見えてきた
vMaterials の内部構造、そして mia_material_x との設計思想の違いをまとめます。

バリアント:大元を書き換えずにパラメータを変える

Windows 環境の場合、Documents\mdl 直下に自作ファイルを 1 つ作ります。

mdl 1.3;
import ::nvidia::vMaterials::Design::Plastic::Hard::*;

export material plastic_hard_sakura(*)
= ::nvidia::vMaterials::Design::Plastic::Hard::plastic_hard_salmon(
    base_color: color(0.99, 0.15, 0.15)
);

鍵は引数リストの (*) です。これがバリアント宣言の印で、
「基底マテリアルの公開パラメータをすべて引き継ぎ、指定したものだけ上書きする」
という意味になります。base_color 以外は元の値のまま生きます。

.mi 側はいつものパターンそのままです。

$include "my_variants.mdl"

instance "cube_inst" "cube_geo"
    material "mdl::my_variants::plastic_hard_sakura_proto_mtl"

実際にこの方法で色変更が反映されることを確認しました(mental ray standalone
3.14.5.4)。この方式の利点は 3 つあります。

vMaterials のファイルを一切触らない。カタログの更新で自分の変更が消えず、
NVIDIA の配布物を改変しない行儀の良さもある
色違い・質感違いを何十個作っても自作ファイル 1 つに集約できる
mdl 1.3; を基底モジュールに合わせておけばバージョン問題も起きない

実は vMaterials 自身がこの仕組みでできています。plastic_hard_salmon や
plastic_hard_light_blue といったカラーバリエーションは、共通の基底に
異なるデフォルト値を与えた変種の列です。同じことを自分の階層で
もう一段やっているだけ、とも言えます。

何が変更できるのか:公開パラメータと annotation

バリアントから上書きできるのは、基底マテリアルの export material の
シグネチャに公開されたパラメータだけです。plastic_hard_salmon の場合、
.mdl をテキストエディタで開けば引数リストにすべて書かれています。

パラメータ	型	デフォルト	範囲
`base_color`	color	(0.597, 0.078, 0.086)	—
`reflection_weight`	float	1.0	0〜1(hard_range)
`reflection_roughness`	float	0.05	0〜1(hard_range)
`ior`	uniform float	1.46	1〜4(soft_range)

パラメータ宣言に付いている [[ ... ]] は annotation(注釈)で、
DCC ツールが UI を自動生成するためのメタデータです。
読み方を覚えておくと .mdl がそのままリファレンスになります。

anno::display_name / description — UI 表示名と説明
anno::hard_range(0, 1) — 強制範囲(範囲外は不可)
anno::soft_range(1, 4) — UI スライダーの目安(超過可能)
anno::in_group("Appearance") — UI 上のグループ分け

4 つすべてを使ったバリアントの例:

export material plastic_hard_mirror_black(*)
= ::nvidia::vMaterials::Design::Plastic::Hard::plastic_hard_salmon(
    base_color: color(0.02, 0.02, 0.02),
    reflection_weight: 1.0,
    reflection_roughness: 0.0,   # 鏡面プラスチック
    ior: 1.6
);

reflection_roughness を 0.05 → 0.3 → 0.7 と振った 3 バリアントを
並べてレンダリングすれば、ハイライトのボケ方を比較する教材が 1 枚でできます。

salmon の正体:flex_material のラッパー

plastic_hard_salmon の定義本体を見ると、興味深い構造が現れます。

= nvidia::core_definitions::flex_material(
    base_color: base_color,
    diffuse_roughness: 0.300000012f,
    is_metal: false,
    reflectivity: reflection_weight,
    reflection_roughness: reflection_roughness,
    anisotropy: 0.f,
    transparency: 0.f,
    transmission_color: color(1.f, 1.f, 1.f),
    ior: ior,
    thin_walled: false,
    ...);

salmon の正体は、汎用マテリアル nvidia::core_definitions::flex_material
に値を固定した薄いラッパーでした。diffuse_roughness や transparency、
anisotropy は salmon の層で焼き込まれており、salmon 経由では触れません。

ここから見えるパラメータ自由度の 3 階層:

既製マテリアルをそのまま使う — _proto_mtl を参照するだけ(第 2 弾)
既製のバリアントを作る — 公開パラメータのみ上書き(本記事で検証済み)
core_definitions の汎用マテリアルから直接バリアントを組む —
flex_material の全パラメータ(透明度・金属・異方性反射まで)が
解放されるはず。実質的にマテリアルを「設計」できる階層(未検証・次の課題)

階層 3 が通れば、cube をガラスにも金属にもでき、以前検証した
コースティクス(フォトンマップ)と MDL を合流させる道も見えてきます。

mia_material_x は「関数」、MDL は「記述」

ここまで来ると、「vMaterials とは mia_material_x のプリセットを 2000 個
カタログ化したようなものか」という理解が浮かびます。体感としては
正しいのですが、両者の対比にこそ MDL の本質が見えます。

mia_material_x の実体は architectural.dll 内のコンパイル済み C++ コード、
つまり mental ray 専用のバイナリ関数です。プリセットを何個作っても、
それは mental ray の中でしか意味を持ちません。

MDL ファイルには手続き的なシェーディングコードが入っていません。
書かれているのは「この色で、この粗さで、BSDF はこう組み合わせる」という
宣言だけです。シェーディングの実行は、宣言を解釈する各レンダラーの
仕事になります。だから同じ Hard.mdl が Iray でも Omniverse でも
mental ray でも解釈できる。本シリーズの検証で、2019 年ビルドの
フリーレンダラーが現行の vMaterials カタログをそのまま読めたのは、
まさにこの設計のおかげです。

合成方法にも同じ思想の違いが現れています。mia_material_x は
「diffuse + reflection + refraction + translucency...」という固定スロットに
パラメータを流し込むモノリシックな設計で、できることの外周はスロット構成で
決まっています。MDL は df::diffuse_reflection_bsdf のような BSDF 部品を
式で合成する言語であり、理論上はスロットの外の材質も記述できます。

もっとも、flex_material の引数リスト(base_color, reflectivity,
transparency, ior, anisotropy...)は mia_material_x のパラメータ構成と
驚くほど似ています。物理ベースマテリアルの「使いやすい公開パラメータ」に
両者が収斂進化した結果でしょう。整理すると:

flex_material ≒ mia_material_x の世代的後継。
vMaterials ≒ その実測ベースのプリセット約 2000 種。
ただしレンダラー非依存の「記述」形式で。

教材的には、この対比自体が美味しい題材です。同じ cube に
mib_illum_phong(1990 年代・経験則の関数)→ mia_material_x
(2000 年代・物理ベースの関数)→ MDL / vMaterials(2010 年代・宣言的記述)
を当てて 3 枚並べれば、シェーディング技術 30 年の進化が 1 シーンで語れます。
そしてその全部が、フリー版 standalone と .mi 直書きで再現できます。

残る宿題

core_definitions 直叩き(階層 3): flex_material のバリアントを直接組む
テクスチャ依存の vMaterials: 画像テクスチャや測定データを参照する
モジュールがリソース解決込みで動くか
$mdl ... $end インラインブロック: バリアント定義を .mi に埋め込み、
シーンファイル 1 つで完結させる書き方の実射
.mi 側からの直接パラメータ注入: バリアントを介さない構文が存在するか
(同梱マニュアル doc\mentalraymanual の精読が近道か)

おわりに

「置くだけでは読まれない」から始まった探索が、隠しサフィックスの発見、
vMaterials カタログの開放を経て、MDL の言語機能でマテリアルを派生させる
段階まで来ました。バリアントの (*) 一つで、2000 種のカタログが
2000 個の出発点に変わります。次から次にやりたいことが見えてくるのは、
MDL が「完成品の詰め合わせ」ではなく「組み合わせ可能な記述の体系」
だからだと思います。

ありがとうございます。

参考リンク

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up