BlenderからExportしたFBXファイルについて

今のところBlenderからExportしたFBXファイルをAssimpで読み込んで使っている。

マテリアルの値を適当に取得はしているが、使っているのはAI_MATKEY_TEXTURE_DIFFUSEのみ。

DirectX12の魔導書に書いてある通り、Diffuse、Specular、Toonのテクスチャはマテリアルにあろうが、無かろうが用意して、シェーダは常にそれらをサンプリングしている。

この形がいいのかよくわからないけど、よくよく調べてみるとあらゆる項目に対してテクスチャを用意できるみたいなので、項目を増やすとこの実装はまずい気がする。

そもそも適当に決めた読み込むパラメータの見直しと、読み込んだパラメータをシェーダに反映させるように作り直したい。

読み込むパラメータの見直し

現状読み込んでいるのは、テクスチャが以下。

AI_MATKEY_TEXTURE_DIFFUSE

AI_MATKEY_TEXTURE_SPECULAR

各種色、パラメータが以下。

AI_MATKEY_COLOR_AMBIENT

AI_MATKEY_COLOR_DIFFUSE

AI_MATKEY_COLOR_SPECULAR

パラメータにはこの他に下記が定義されてた。

AI_MATKEY_SHININESS_STRENGTH

AI_MATKEY_SHININESS

AI_MATKEY_COLOR_EMISSIVE

AI_MATKEY_COLOR_TRANSPARENT

AI_MATKEY_COLOR_REFLECTIVE

AI_MATKEY_OPACITY

AI_MATKEY_REFLECTIVITY

AI_MATKEY_REFRACTI

Blenderで定義を変えてExportして、どこと紐づくのかを調べてみた。

Blenderのマテリアル

AI_MATKEY_COLOR_DIFFUSE

Blenderのラベルは「ベースカラー」

Blender側は色指定で、その値がそのまま渡る。

テクスチャを設定した場合は、AI_MATKEY_TEXTURE_DIFFUSEにファイルが設定され、カラーは0.8がRGBに返る。

AI_MATKEY_COLOR_SPECULAR

Blenderのラベルは「スペキュラー」

Blender側はスカラー指定で、受け取りはカラー。

各要素はDIFFUSEのRGB×スペキュラー値×0.5になっていた。

スペキュラー値が0なら0、0.5なら1/4、1なら1/2、2ならDIFFUSEと同じ値が返る。

テクスチャを設定した場合は、AI_MATKEY_TEXTURE_SPECULARにファイルが設定され、カラーは0.2がRGBに返る。

AI_MATKEY_SHININESS_STRENGTH
AI_MATKEY_SHININESS

Blenderのラベルは「粗さ」

どうやら、AI_MATKEY_SHININESS_STRENGTHとAI_MATKEY_SHININESSは同じ値が設定されているようだ。

Blender側はスカラー指定で、受け取りもスカラー。

設定値とは別の値が返る。

粗さとShininessの関係

横軸がBlenderの粗さで、縦軸がAssimpのShininessの値。

基本的にはBlenderで0～1の範囲で設定して、Assimpでは100～0の値が受け取れるので、0.01を掛けて1～0に変換して使う。

AI_MATKEY_COLOR_EMISSIVE

Blenderのラベルは「放射」と「放射の強さ」

Blender側はカラーとスカラー指定で、受け取りはカラー。

単純に放射の色に、放射の強さを掛けた値が返る。

テクスチャを設定した場合は、AI_MATKEY_TEXTURE_EMISSIVEにファイルが設定され、カラーは未設定になる。

AI_MATKEY_OPACITY

Blenderのラベルは「アルファ」

Blender側はスカラー指定で、受け取りはスカラー。

ちなみにテクスチャを指定してもAI_MATKEY_TEXTURE_OPACITYには設定されていなかった。

AI_MATKEY_COLOR_AMBIENT

AI_MATKEY_COLOR_TRANSPARENT

AI_MATKEY_COLOR_REFLECTIVE

AI_MATKEY_REFLECTIVITY

AI_MATKEY_REFRACTI

これらの値は紐づけがわからず。

Ambientは値自体は取得できて、常に0のカラーが返る。

ほかは設定されていない。

使ってるBlenderのバージョンは3.2、Assimpのバージョンは4.1で、最新のAssimpのヘッダを見るとかなり項目が増えていた。

Blenderのラベルと同じもの（メタリック、シーン、クリアコートなど）も用意されている。

Assimpのバージョンを上げると取れる項目は増えるのだろうか？

PBR

HLSLの魔導書に物理ベースレンダリングについて書かれていて、それを取り入れたいと思っているんだけど、この本のサンプルを見ても結果が不自然。

仕方がないのでネットで探してみると、Unityのシェーダが見つかったのでそれを参考に作ってみた。

マテリアルについてなんとなくわかってきたので、Blenderでパラメータかテクスチャを設定する方法を用意するつもりだけど、シェーダに指定するテクスチャの数を抑えるため１テクスチャにマージして、metalic(R)、roughness(G)、emissive(B)、未定(A)のようにする。

パラメータを使う場合は下記。

metallic

　blender：スペキュラー

　assimp：AI_MATKEY_COLOR_SPECULARでRGBの最大値。

roughness

　blender：粗さ

　assimp：AI_MATKEY_COLOR_SHININESS。

emissive

　blender：放射と放射の強さ

　assimp：AI_MATKEY_COLOR_EMISSIVEでRGBの最大値。

「スペキュラー」も「放射」もBlender上、色を設定するパラメータだけど、テクスチャで指定する方との互換性でスカラー値にする。スペキュラーは計算上メタリック扱いで、放射はアルベドカラーをそのまま光らせる方針。

テクスチャのマージ

モノクロのテクスチャをそれぞれ用意して、metalic(R)、roughness(G)、emissive(B)、未定(A)に割り当てて出力する。

metallic

emissive

出力結果

Emissiveなし

Emissiveあり

右の列がMetallicが高いオブジェクトで、上段と下段はパラメータで全体に指定、中段はテクスチャで枠だけ指定。

中央の列がMetallicが低いオブジェクトで、上段と下段はベースカラーに赤を指定、中段はテクスチャを指定。

左の列はEmissiveが指定してあるオブジェクトで、上段と下段はパラメータで全体に指定、中段はテクスチャで前面のみ光るように指定。

Bloom

今回はBloomについて。

DirectX12の魔導書に続き、HLSLシェーダーの魔導書も購入した。

前書の方では結果に欠陥があって自分で解決しろというスタイルだったので試してもなかったが、今作ってるレンダリングエンジンの機能に加えるため作ってみることにした。

処理は２つに分かれていて、１つ目が高輝度部分抽出で、２つ目が高輝度部分のブラー処理。

最後に元の画像と、ぼかした画像を加算合成するという流れ。

高輝度部分抽出

まず、HDRレンダリングを行うためにDXGI_FORMAT_R32G32B32A32_FLOATの中間レンダーターゲットを用意する。

元になる画像をこの中間レンダーターゲットにコピーする際、

dot( color.rgb, float3( 0.2125f, 0.7154f, 0.0721f )) ;

この内積の結果が１以上の場合出力するとなっているが、真っ黒な絵しか出力されなかった。

ライトを強めにするとか書いてあるが、コピー部分にはライトが関係なさそうでよくわからない。

ネットで調べてみたところ、同じように出来上がった画像の高輝度部分を抽出する場合、

color.rgb = saturate( color.rgb - 0.9f ) * 10.0f ;

こんな感じになっていた。

実際にこんな方法で抽出した場所を光らせても、求めてるものと違うような気がするがとりあえずはこれでやってみることにする。

ブラー処理 

これは以前作った処理を呼び出せば良いと思ったんだけど、少し問題があった。

静止画の場合は問題なさそうだけど、画面が動くとぼかしの品質が悪くてぼやぼやする感じになった。

ブラーを掛ける前のリソースはミップマップテクスチャでないと品質的に耐えられなさそうなのでミップマップ化する処理を間に追加し、そのミップマップテクスチャでブラーをかけることにした。

最終的な処理の流れ

処理フロー図

１．元画像準備

ブルーム対象の画像。

高輝度のものだけを出力した画像が渡された場合は、次の処理をスキップできるようにした。

２．高輝度部分抽出

今回は色の各成分が0.9以上の箇所を抽出するようにしてみたが、実際には使えないと思ってる。

モデルのEmissiveが値を持っている箇所のみをレンダリングした画像を元画像として出力する仕組みを作ってみる予定。

３．高輝度画像ミップマップ化

ファイル指定のテクスチャをミップマップ付きで用意する仕組みはあったけど、動的なリソースに対してミップマップを作る仕組みがなかった。

なので任意のSRVを指定してミップマップテクスチャを作成する仕組みを用意した。

４．ブラー処理

ミップマップテクスチャを元にブラー処理をかける。

５．元画像とぼかし画像の加算合成

最後は元画像と、ブラー画像を加算合成する。

ブラー画像に対する重みパラメータと、合成後の掛け目のパラメータを用意した。

出力結果

通常レンダリング結果

このレンダリング結果に対してブルーム処理をかけても、高輝度部分が抽出できなかった。

鏡面反射

スペキュラの計算を付け加えて全体をテカテカにして、これに対してブルーム処理をかけてみる。

ブルーム結果

それっぽい結果になった。

ブルーム結果２

パラメータを変えて、ブラー画像を２倍にして、合成結果に0.5かけたもの。

HDRレンダリングってなんだ？

高輝度抽出画像は最初DXGI_FORMAT_R32G32B32A32_FLOATでやっていたが、いつものDXGI_FORMAT_R8G8B8A8_UNORMでも結果が変わらなかったので戻した。

シェーダの結果として1以上の明るさを設定できるんだろうけど、レンダーターゲットはDXGI_FORMAT_R8G8B8A8_UNORMのままなので、1以上は1扱いでそのまま出力されたのか？

レンダーターゲットもDXGI_FORMAT_R32G32B32A32_FLOATで作ればもっと眩しい感じになるのか？

そもそもそれっぽく見せるために、光源をぼかして範囲を広げて周りに光を漏れさせた絵を用意したけど、そんな事せずに光ってる部分の値を１０００とか１万とかにすると、ディスプレイ自体がめちゃくちゃ光ってそういうふうに見せてくれないのかな？

CS版軽量なぼかし処理

前々回で、リアルタイムにぼかす処理を作ってみたけど、実際には静止画にぼかしフィルタを掛けているだけ。

ぼかす対象は静止画だったので毎フレーム更新する必要はない。

前に作ったのはリアルタイム用として、今回は１回だけの静止画用をコンピュートシェーダ(CS)で作って見ようと思う。

リアルタイム用は２枚の中間レンダーターゲットを用意して処理していた。

静止画用は空のテクスチャ２枚を用意して、CSで書き込むことになる。

テクスチャに書き込むのにUnorderedAccessView(UAV)をテクスチャに紐づけて、Dispatchする際には、用意したテクスチャではなくUAVの方を指定する。

#define DefRS "RootFlags(DENY_VERTEX_SHADER_ROOT_ACCESS|DENY_HULL_SHADER_ROOT_ACCESS|DENY_DOMAIN_SHADER_ROOT_ACCESS|DENY_GEOMETRY_SHADER_ROOT_ACCESS|DENY_PIXEL_SHADER_ROOT_ACCESS),DescriptorTable( Sampler(s0),visibility=SHADER_VISIBILITY_ALL),DescriptorTable( SRV(t0, flags=DATA_STATIC_WHILE_SET_AT_EXECUTE),visibility=SHADER_VISIBILITY_ALL),DescriptorTable( UAV(u0, flags=DATA_VOLATILE),visibility=SHADER_VISIBILITY_ALL),RootConstants( num32BitConstants=2, b0,visibility=SHADER_VISIBILITY_ALL)"

SamplerState Sampler : register(s0) ;
Texture2D TexColor : register(t0) ;        // ぼかし対象画像
RWTexture2D<float4> UAV : register(u0) ;    // 結果画像
struct _Param { 
	float2	Scale ;	// 倍率
} ;
ConstantBuffer<_Param> Param : register(b0) ;

static const int BLUR_SAMPLE_COUNT = 8 ;
static const float2 BLUR_KERNEL[BLUR_SAMPLE_COUNT] = {
	float2(-1.0f, -1.0f),
	float2(-1.0f,  1.0f),
	float2( 1.0f, -1.0f),
	float2( 1.0f,  1.0f),
	float2(-0.5f,  0.0f),
	float2( 0.0f,  0.5f),
	float2( 0.5f,  0.0f),
	float2( 0.0f, -0.5f),
} ;
						
struct CSInput
{
	uint3 ID : SV_DispatchThreadID ;
} ;

[RootSignature(DefRS)] 
[numthreads( 8, 8, 1 )]
void CSMain( CSInput In )
{
	float2 uv = In.ID.xy + 0.5f ;
	float4 color = 0 ;
	for( int j = 0 ; j < BLUR_SAMPLE_COUNT ; j++ ) {
		color += TexColor.Sample( Sampler, ( uv + BLUR_KERNEL[j]) * Param.Scale ) ;
	}
	UAV[ In.ID.xy ] = float4( color.rgb / float( BLUR_SAMPLE_COUNT ), 1.0f ) ;

	return ;
}

シェーダの内容はほとんど変わらない。

ただ１つ重要なポイントがあって、リアルタイム用の時は意識してなかったんだけど渡すテクスチャにミップマップをつけておくこと。

1段階目で一気に縮小するので、その画像をたった8個のサンプリングでは品質が保てなく、実はかなりの部分をミップマップに助けてもらっていた。ミップマップは事前（読み込み時）に1回だけの処理なので、パフォーマンスには影響がない。

だけど、リアルタイムの方ではレンダリング結果にブラーを掛ける場合はミップマップの恩恵は得られない。品質の話はブラー強度を徐々に高めたりして前後を比較して見たときに気になるレベルなので、強度が一定であればミップマップなしでも許容範囲だと思う。

パフォーマンス 

リアルタイムの方は、ぼかし強度によって365～178usだった。

CS版はぼかし強度によって276～14usぐらい。（Dispatch部分のみ）

結構軽そうなので毎フレーム処理するようにしてみたら432～166us。

ぼかし強度が強い場合はリアルタイムでも使ったほうがいい結果になった。

ぼかし強度が弱い場合、そんなにサンプリングしなくても品質が落ちないので試しにBLUR_SAMPLE_COUNTを4にしたら309～163usだった。

ぼかし強度に合わせてサンプル数を調節してやれば、CS版のほうが高速っぽい。

ライブラリにまとめる際、リアルタイム版は結果が中間レンダーターゲット、描画に必要なもう1つの中間レンダーターゲットも常に保持しておく必要があるのに対し、CS版は結果がテクスチャで、描画に必要だったUAV２つと、もう１つのテクスチャは削除できる。