2023年2月26日日曜日

FrustumCullingと別カメラの視点

技術関連のページを調べていると、Unityの記事が多い。
Unityのエディタ上で視錐台と各種オブジェクトが表示されている画面と、視錐台の視点(実際の見た目)の画面を同時に見ていたりする。

次は視錐台カリングにチャレンジしてみようと思ったが、まず上記のような別視点で確認できるようにして、本当に裏で消えているのか確認できるようにしたい。


別カメラ画面


まず通常の描画を行い、それをレンダーターゲットではなく中間レンダーターゲットに出力する。
次に、サブカメラを追加してそのカメラ視点の描画を同じシーンに対して行う。こっちの描画はレンダーターゲットに直接行い、通常の描画で作った中間レンダーターゲットを最後に描画する。影の処理は通常処理で済んでいるので、2回目ではスキップできるようにしている。
これはあっさりと出来た。

メインカメラとサブカメラの画像


視錐台の描画


次に視錐台の描画をやってみる。
カスケードシャドウをやったとき、ライトカメラからの視錐台を作っていたのでそれを応用してみる。各頂点はメインカメラからの情報で作って、VertexBufferに書き込む。FarZは30ぐらいにしておく。プリミティブはD3D_PRIMITIVE_TOPOLOGY_LINELISTで描画する。

これもそれっぽく表示されたけどなんか実際のカメラの回転とずれている。
視錐台のWorldマトリクスをどうすればいいのか2日ぐらいハマった。
いろいろ試行錯誤した結果、Viewの逆行列でいいということにたどり着いた。

視錐台描画


視錐台カリング


視錐台カリングで検索するといくつか見つかる。
点であれば、View×ProjectionでXMVector4Transformを呼び出して、あとは-wからwの範囲に、x,y,zが含まれていれば表示対象ということはわかった。
AABBでのやり方も出てくるが、スマートではない。
視錐台と球の判定がやりたい。

マイクロソフトのサンプルにMeshShaderでGPU側でFrustumCullingをやっているものを見つけた。これを参考にすれば出来るかもしれない。
実装した結果それっぽくはなるが、視錐台を横から対象のオブジェクトみて視錐台の左右の壁にぶつけたとき、かなり早めにカリングされてしまう状況になった。

面の作成

	auto oPV = oCam.oCamera.GetViewMatrix() * oCam.oCamera.GetProjectionMatrix() ;
	tDMatrix vp = DirectX::XMMatrixTranspose( oPV ) ;
	tDVector oPlanes[] = {
		DirectX::XMPlaneNormalize( DirectX::XMVectorAdd( vp.r[3], vp.r[0])),		// Left
		DirectX::XMPlaneNormalize( DirectX::XMVectorSubtract( vp.r[3], vp.r[0])),	// Right
		DirectX::XMPlaneNormalize( DirectX::XMVectorAdd( vp.r[3], vp.r[1])),		// Bottom
		DirectX::XMPlaneNormalize( DirectX::XMVectorSubtract( vp.r[3], vp.r[1])),	// Top
//		DirectX::XMPlaneNormalize( vp.r[2]),										// Near
//		DirectX::XMPlaneNormalize( DirectX::XMVectorSubtract( vp.r[3], vp.r[2])),	// Far
	} ;

これも2日ぐらいハマった。
各メッシュの中心と半径でチェックを行う際、World×View×ProjectionのマトリクスでXMVector4Transformを呼び出して、半径はスケール調整して後は面ごとに内積した結果を-半径以下になったら範囲外という判定をする。判定の面はNearとFarは除外した。

判定部分

	auto oV = DirectX::XMVector4Transform( oCenter, oTrans ) ;
	auto r = oM.nRadius * DirectX::XMVectorGetX( oScale ) ;

    for( auto & oP : oPlanes ) {
		auto d = DirectX::XMVectorGetX( DirectX::XMPlaneDotCoord( oP, oV )) ;
        if( d < -r ) {
			o.bCulling = true ;
			break ;
        }
    }

内積の関数をXMVector3Dot、XMVector4Dotを使っていたが、XMPlaneDotCoordの存在を知り変更。若干良くなるがまだ判定がおかしい。
最終的はoTransがWorld×View×Projectionではなく、Worldだけにしたらうまく行った。

視錐台カリング


今回はメッシュのグループ単位でカリングを行ったが、マテリアルが変わる単位でもカリングができそう。ただそれをやるとDrawコールを分ける必要が出てきてむしろ遅くならないかが心配。
いろいろ調べてみると、全部GPU側で判断させてドローコールもGPU側でしてしまうのが速いっぽい。MeshShaderに手をだす日も近いか・・・

 


2023年2月18日土曜日

DrawInstanced

前回StructuredBufferを作ったが、これを利用して今回は複数インスタンスを同時に描画してみる。


同一Bone(CacheVertexBuffer)


今までWorldMatrixは32BitConstBufferで渡していたが、StructuredBufferで複数渡せるようになったので複数インスタンス対応させてみる。

#define DefRS "RootFlags(ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | DENY_HULL_SHADER_ROOT_ACCESS | DENY_DOMAIN_SHADER_ROOT_ACCESS | DENY_GEOMETRY_SHADER_ROOT_ACCESS | DENY_PIXEL_SHADER_ROOT_ACCESS),DescriptorTable( SRV(t0, flags=DATA_STATIC_WHILE_SET_AT_EXECUTE),visibility=SHADER_VISIBILITY_VERTEX),RootConstants( num32BitConstants=16, b0,visibility=SHADER_VISIBILITY_VERTEX)"

StructuredBuffer<float4x4> World : register(t0) ;

struct _Cam
{ 
	float4x4	TransPV ;	// offset:   0	Size: 64
} ;
ConstantBuffer<_Cam> Cam : register(b0) ;

struct VSInput
{
	float3 Pos : POSITION ;
	float3 Normal : NORMAL ;
	float2 UV : TEXCOORD ;
	uint IID : SV_InstanceID ;
} ;
struct VSOutput
{
	float4 Pos : SV_POSITION ;
} ;

[RootSignature(DefRS)]
VSOutput VSMain( VSInput In )
{
	VSOutput Out ;
	Out.Pos = mul( Cam.TransPV, mul( World[ In.IID ], float4( In.Pos, 1 ))) ;
	return Out ;
}

VertexShaderに「uint IID : SV_InstanceID」の引数を追加し、WorldMatrixを「StructuredBuffer<float4x4>」で定義する。
WorldMatrixの参照は「World[ In.IID ]」でインスタンス別に参照位置を変える。
Bone情報はこのShader以前のパスでキャッシュしてあり、固定のMeshと同じShaderで描画できるようになっている。



すべてのキャラクタが同じ動きをしてしまうので、兵士の行進とか特殊な状況でしか使えなさそう。


個別Bone


今度は個別のアニメーションにも対応できるように、Bone自体をインスタンス分保持して描画してみる。


#define DefRS "RootFlags(ALLOW_INPUT_ASSEMBLER_INPUT_LAYOUT | DENY_HULL_SHADER_ROOT_ACCESS | DENY_DOMAIN_SHADER_ROOT_ACCESS | DENY_GEOMETRY_SHADER_ROOT_ACCESS | DENY_PIXEL_SHADER_ROOT_ACCESS),RootConstants( num32BitConstants=1, b0,visibility=SHADER_VISIBILITY_VERTEX),DescriptorTable( SRV(t0, flags=DATA_STATIC_WHILE_SET_AT_EXECUTE),visibility=SHADER_VISIBILITY_ALL),DescriptorTable( SRV(t1, flags=DATA_STATIC_WHILE_SET_AT_EXECUTE),visibility=SHADER_VISIBILITY_VERTEX),RootConstants( num32BitConstants=16, b1,visibility=SHADER_VISIBILITY_VERTEX)"

struct _Mesh
{ 
	uint	BoneCount ;
} ;

ConstantBuffer<_Mesh> Mesh : register(b0) ;

StructuredBuffer<float4x4> Bone : register(t0) ;

StructuredBuffer<float4x4> World : register(t1) ;

struct _Cam
{ 
	float4x4	TransPV ;	// offset:   0	Size: 64
} ;
ConstantBuffer<_Cam> Cam : register(b1) ;

struct VSInput
{
	float3 Pos : POSITION ;
	float3 Normal : NORMAL ;
	float2 UV : TEXCOORD ;
	uint4 BoneID : BONE ;
	float4 Weight : WEIGHT ;
	uint IID : SV_InstanceID ;
} ;
struct VSOutput
{
	float4 Pos : SV_POSITION ;
} ;

[RootSignature(DefRS)]
VSOutput VSMain( VSInput In )
{
	VSOutput Out ;
	uint ofs = Mesh.BoneCount * In.IID ;
	float4x4 BoneTrans
		= Bone[ In.BoneID[0] + ofs ] * In.Weight[0]
		+ Bone[ In.BoneID[1] + ofs ] * In.Weight[1]
		+ Bone[ In.BoneID[2] + ofs ] * In.Weight[2]
		+ Bone[ In.BoneID[3] + ofs ] * In.Weight[3]
	;
	Out.Pos = mul( Cam.TransPV, mul( World[ In.IID ], mul( BoneTrans, float4( In.Pos, 1.0f )))) ;
	return Out ;
}

「StructuredBuffer<float4x4> Bone」と「uint BoneCount」をConstBufferで追加。
Boneを参照する際、「BoneCount * InIID」でインスタンス別に参照位置を変える。


 1回のDrawIndexedInstancedだけど、複数インスタンスでそれぞれ違う動きが出来るようになった。


キャッシュされたVertexBufferで1体、個別Boneで1体描画したときの時間は約174usで、それぞれ20体ずつの描画は約196usと殆ど変わらない速度で描画出来るっぽい。

1体ずつの描画

20体ずつの描画


2023年2月12日日曜日

StructuredBufferとCopyQueue


StructuredBuffer


メッシュのボーン行列をシェーダにわたす定義は、定数バッファで固定の配列にしていた。

struct _Bone {
	float4x4 Bones[255] ;
} ;
ConstantBuffer<_Bone> Bone : register(b1) ;

実際に渡す個数はボーンの数分だけで、利用するインデックスも渡した分だけを指すようになっているので問題ない。
ただ、この固定の書き方が気持ち悪いのと、読み込んだメッシュのボーンが固定値を超える場合に調整が必要になるのでなんとかしたい。

構造化バッファ(StructuredBuffer)の場合、可変の配列定義が許されているのでリソースのタイプに追加することにした。
前にテクスチャのミップマップを作る際、GPU側(ComputeShader)で更新するリソースを用意したけど、今度はCPU側から更新するタイプのSRVリソースとなる。

D3D12_HEAP_TYPE_UPLOADとD3D12_HEAP_TYPE_DEFAULTの2リソースを用意して、Uploadの方はMapしっぱなしで更新時にmemcpyしつつ、CopyBufferRegionでDefaltの方に反映する。

このコピーを行うコマンドリストは、汎用的に使えるように用意したDIRECT版のコマンドリストを使っていて、ステータス遷移(D3D12_RESOURCE_STATE_COPY_DEST)、CopyBufferRegionを追加する。

StructuredBuffer<float4x4> Bone : register(t1) ;

シェーダの定義はこんな感じになって、Bone[Index]という風に使える。

疑問点が1つあって、定数バッファはフレームのバッファ数分用意する必要がある。
マイクロソフトのサンプルでは、ダブルバッファの場合必要サイズの2倍データ領域を用意して、毎フレーム交互に書き込み、参照していく。
構造化バッファの場合、今のところ1つで済んでいる。
中間レンダーバッファの時も思ったけど、SRVをベースにしていると1つで済むのか?
ただし、UAV経由で更新する場合は領域が2つ必要だった。
更新時UploadとDefaultの2つが絡んでいるから、これが2つ分扱いになっているのか?
謎。


CopyQueue


ボーンのバッファは毎フレーム更新を行うことになるけど、そのデータのコピーについて今まで使ってなかった専用のコピーキューを用意してやってみようと思う。

D3D12_COMMAND_LIST_TYPE_COPYでCreateCommandQueueを作成する。
コマンドリスト、アロケータも同様にD3D12_COMMAND_LIST_TYPE_COPYで作成して、利用してみるとエラーになった。

D3D12 ERROR: ID3D12CommandList::ResourceBarrier: D3D12_RESOURCE_STATES has invalid flags for copy command list. [ RESOURCE_MANIPULATION ERROR #537: RESOURCE_BARRIER_INVALID_COMMAND_LIST_TYPE]

コピーで作ったリストにはコピーコマンドしか入れることができず、リソースの状態遷移はできないのか?
いろいろ調べてみるとコピーコマンドリストが理解できるステータスなら許容されるみたいだ。Beforeステータスには現在のステータスを設定していたが、これをD3D12_RESOURCE_STATE_COMMONにしてしまえばコピーコマンドのリストでも状態遷移ができた。真面目に今の状態をセットしていたのに、適当な値でいいなんて・・・。それまでは別のDIRECTコマンドのリストで遷移させていたがプログラムが多少スッキリした。


改善前

改善後

処理時間を計測してみた結果、改善前は11usぐらいで改善後は14us秒ぐらい掛かっている。



改善前のComputeコマンド

改善前は状態遷移で5us、コピーに1us、Dispatch前の状態遷移に0us、Dispatchに4us掛かっている。


改善後のCopyコマンド

改善後のComputeコマンド

改善後は、状態遷移に2us、コピーに1us、Dispatch前の状態遷移に7us、Dispatchに4us掛かっている。

これは失敗か?
更に改良を加えて、表示するメッシュを10に増やして測ってみた。
加えた改造は、状態遷移に時間が掛かっているように見えたので処理前にまとめて状態遷移をさせてしまうようにした。
今までは、対象メッシュが使うリソースを状態遷移させてシェーダ実行、次のメッシュが使うリソースを状態遷移させてシェーダ実行、というように状態遷移とシェーダ実行を交互に行っていた。それを描画対象のメッシュすべてのリソースを状態遷移させてから、シェーダ実行するようにした結果がこれ。

改善前

改善後

改善前は45usで、改善後は18us程度。
改善前は描画対象のメッシュが増えると処理も線形に延びていってしまう感じだが、改善後は1メッシュが14usで10メッシュでも18usなので、ほとんど増えていない。

改善前のComputeコマンド

改善前は並列に処理することが出来ず、何かする度に待ち時間が発生してしまっている感じになっている。


改善後のCopyコマンド

改善後のComputeコマンド

改善後はほとんど並列に処理できている。

ResourceBarrierは至るところにまとめてやれという風に書かれていたので、シェーダで使う単位ではまとめて遷移させるようにしていたけど、メッシュを横断してまとめてやった結果、かなり改善されてびっくり。1つだけの場合は逆に処理時間延びてまずいと思ったけど、数が増えるほど効果が出そう。


2023年2月1日水曜日

Cascade Shadow 2

以前カスケードシャドウを作ったけど、ベースはマイクロソフトのサンプルを元に自分のライブラリに移植した。
サンプルにはオブションがいくつもあり、その中から自分が使う部分のみを残して移植した。それでも結構なコード量で、半分以上は理解ができていない状態だった。

HLSLの魔導書にもカスケードシャドウについて書かれていて必要最小限の実装になっている。
今回はこれを改造して、自分のライブラリに移植する。


分割エリアを定義


最低限の実装なので魔導書では固定値で定義していた。

カメラに設定されているNearZ(1.0f)とFarZ(10000.0f)を取り出して、中間の分割位置をパラメータで指定する実装になっている。

このままでは色んな場面に対応できないので配置するメッシュからNearZとFarZを計算して、分割位置はパーセント指定するように修正した。

まず視線(カメラからフォーカス)ベクトルを準備する。
メッシュロード時に中心と半径はメッシュデータに保持しておくようにしてあるので、それを利用して、カメラからメッシュの中心までのベクトルと視線ベクトルの内積を計算。
結果に半径を足したものがMaxFarZを超えるなら更新、半径を引いたものがMinNearZよりも小さければ更新する。
最後にカメラのNearZよりも小さければNearZは補正する。


分割エリアを描画するためのライトビュープロジェクション行列の計算


この部分がカスケードシャドウのいちばん重要な部分だと思うが、難しくてよくわからない。
・ライトカメラのプロジェクション行列(XMMatrixOrthographicLH)とビュー行列(XMMatrixLookAtLH)からライトビュープロジェクション行列を求める。
・分割した領域の視錐台の8頂点を求める。
・頂点をライトビュープロジェクション空間に変換
・各頂点の最大、最小値を求めてクロップ行列を求める。
・クロップ行列にライトビュープロジェクション行列を乗算。
・出来上がった行列をシェーダに渡す。

仕組みとしてはこの行列でシェーダ内の頂点を変換して、XYが-1~1の範囲内に収まっていれば、その分割区間内ということが判断できるらしい。


分割区間別の深度バッファを用意


魔導書では一番近い場所の深度バッファから、遠くに行くに連れ縦横半分のサイズの深度バッファを複数枚を用意していた。
これを1枚の横長に分割数分拡張した深度バッファで処理することにする。

深度バッファ

こうすれば最終的なシェーダにわたすリソースは分割数が変わっても1つ分固定になる。


影描画


魔導書のシェーダはフォワードレンダリングで、頂点シェーダで4領域分の頂点計算をして、ピクセルシェーダに渡していた。
これは気持ち頂点計算が無駄な気がした(描画対象の領域が手前だとしても奥の分まですべて頂点計算をしてしまう)のと、この方法をディファードレンダリングではできないので、ピクセルシェーダ側に頂点計算を持っていった。
その後ディファードレンダリングで実装し直してみたら、今回はあっさりうまく行った。

影なし

影あり

カスケードデバッグ


問題点


つなぎ目のアーティファクト


デバッグ表示

つなぎ目にアーティファクト

たまに一番手前と次の影の境目に点線が表示される。
深度バッファギリギリまで参照していることが原因なので、一定範囲を超えたら一段階広い深度バッファを参照するように修正した。


謎の黒点


謎の黒い点

ディファードレンダリングで描画するように修正したら、黒い点が表示されるようになった。
原因はBRDFの計算の中にあるフレネル項の部分で、pow(1-cos, 5)という部分のcosの値が1を超えている場合、値がnanになり色が黒になっていた。
cosをmin( 1, cos )にしてpowの引数がマイナスにならないように修正した。


今後の課題


・ソフトシャドウ
・つなぎ目のぼかし

魔導書のカスケードシャドウのシェーダはすごくシンプル。
先にマイクロソフトのサンプルで実装経験があったので、今回はいろいろ改造することができるようになった。
また別の機会に改良することにする。