雑記 CEDEC+SAPPORO2019に参加してきたよ

あいさつ

どうも、はかせです。
今日10/5に札幌でCEDECが開催されました。
sapporo.cedec.jp

今回の記事はこのレポ記事になります。
私が聞いたセッションで出せるものを出していきます。

リアルタイムレイトレーシングの導入と最適化事例

DXRのセッションです。
sapporo.cedec.jp

内容はDXRとはなんぞやという話と
実際使ってみて行った最適化の話でした。

ぶっちゃけD3D12初めて数日の理解度では
完璧に内容を理解することは無理でした(当たり前ｗ)

なので私が理解できたレベルでまとめると
・ASと呼ばれるシーン情報的なものをDXRの前にビルドする必要がある
・解像度の影響をダイレクトに受ける
・DXRは通常のパイプラインとは別のパイプラインを用いる
・DXRのパイプラインと通常のパイプラインは完全に独立している
・DXRには専用シェーダーが存在している
・DXRではイベントドリブンライクに専用シェーダーを実行している
・Transformの扱いが違う
って感じです。

パイプラインが完全に独立しているため
既存のパイプラインの一部分、
例えばシャドウマッピングの部分を
DXRのパイプラインに置き換えるみたいなことが可能で
導入はD3D12が出来ているならばそこまで難しくはなさそうでした。
(私はできてないので難しそうでした)

ただDXR使うためのRT-Taxと呼ばれている
前後処理が必要でこいつの負荷が結構馬鹿にならないみたいです。
(テンポラル処理やデノイザとか)

また通常のパイプラインではTransformはジオメトリを
変換するために使用しますが、
DXRではレイを変換するために用いられるようです。

なので普段と同じノリで使うと
裏面になったり法線がおかしくなったり
してしまうみたいです。

そのためTransform行列を見て
必要に応じてDXRのフラグを変えて
対処したそうです。

スライドはcedilにて公開されています。
cedil.cesa.or.jp
(9/6に行われたもののため日付等が違いますが内容は同じものです)

『描画が出来る人』ってどうやって育てればいいんだろう？～描画エンジニア育成プロジェクトポストモーテム

これは描画エンジニアをどのように育成していったかのセッションでした。
sapporo.cedec.jp

少人数を2年という期間でじっくりと育て上げ、
自分で学びまた他の人に伝えることができる
骨太なエンジニア(伝道師)を育成することを目標にしていたそうです。

半年ごとにマイルストーンを置き、
基礎～応用までカバーしたとのこと。
(D3D11～DXRその他諸々)

そうした中で育成する側された側双方の
反省や気づきについて話をしていました。

基本は転んでも大丈夫なプロジェクトで
転びながら成長させるって感じだったみたいです。

また育成する側メンターも
育成するということ自体が初めてだったので
そういった育成ノウハウを貯めることもでき
次回次々回の育成プロジェクトに役立てたいとのこと。

スライドはcedilにて公開されています。
cedil.cesa.or.jp
(9/6に行われたものですが内容に違い見受けられませんでした)

DirectX12を教えてみて得られたこと～意外と得られるものが多かった～

私に以前LoadWICを教えてくれた方が実際に学校のカリキュラムに
DirectX12を組み込んでみたらどうなったかというセッションです。
sapporo.cedec.jp

セッション情報ではSNS公開等は禁止とされていますが、
実際セッション中に公開OKと言っていたため記事にします。

とりあえずめちゃめちゃ怒られたし
めちゃめちゃ大変だったそうです。

それに周りに聞ける人もおらず、
始めた当初は記事などはほぼなく、
あったとしても英語の記事ばっかで
読むのに大変苦労したとか。

ただそうやってがんばって習得した
おかげでハードウェアの理解が深まったそうです。
また教えている学生たちの内定先企業の
質が上がったそうです。
(おそらく誰もが知っている有名企業への内定が増えたのでしょう)

ただ今DXRやDXMLなどD3D12がベースとなっている技術が
どんどん出てきていて今後はD3D12をやっていくしかないだろうと
考えての行動だそうです。

実際先の描画エンジニアの育成のセッションでも
今後D3D12を避けては通れないという話がありました。

なので今後ゲーム業界にエンジンエンジニアや
技研職などで就職しようと思ったら
D3D12が必須になるかもしれないですね。

ただ私もやって言いましたが、
別に超絶難易度の黒魔術ってわけではなく
がんばって何周もすれば理解できるものにはなっています。
なので私も理解するためD3D12を周回しなくてはいけませんね。

コードの複雑度とソフトウエアメトリクスについて

コードの品質についてとその評価方法、
および役に立つツールの紹介のセッションでした。
sapporo.cedec.jp

セッション情報ではSNS公開等は禁止とされていますが、
実際セッション中に公開OKと言っていたため記事にします。

ソフトウェアの品質について話をした後で
コードの品質の話をしていました。

ソフトウェアの品質としては主に
設計、テスト、コードの三つの品質があるそうです。

設計の品質ってのはWhatとかHowとか
状態の遷移管理など設計の勉強を少しでもしたことがあれば
一度は見聞きしたことがある内容でした。

テストの品質ってのは網羅性とかって話ですね。
ただ全数テストは現実問題不可能だから
工程ごとにテストを行うなどしてその品質を担保するらしいです。

そしてコードの品質はサイクロマチック数という
ものを使用して話をしていました。

サイクロマチック数ってのは
コードの中にあるif文やループ文の数の総和+1
の値です。

この値を見てコードの危険度をなんとなく察知するんだそうです。
あくまで察知するだけであって
実際にバグがあるかどうかまでは分かりませんし、
サイクロマチック数が少ないコードが
必ずしも良いコードになるとも限らないそうです。

そしてサイクロマチック数を計算するソフトとして
「SourceMonitor」というソフトが紹介されていました。

このソフトは割と昔からあるソフトらしく
フリーで誰でも使えてブログとかの記事もいっぱいあります。

またこれ以外にもコードの品質を測定する
指標やツールはたくさんあるみたいなので
プロジェクトにあったものを使うのがよさそうです。

あとがき

今回はCEDEC+SAPPORO2019のレポ記事でした。
正直私自身の知識不足が目立ち
理解しきれなかったことが多かったです。
(主にDXR)

ただ勉強会って自分の実力を知る
いい機会だなと改めて思いました。

次回またどこかの勉強会に参加するまでに
知識をつけて今度はしっかり理解できるようになりたいものですね。

それでは今回はこの辺でノシ