VRChat的なものの開発を進めた。とっととアプリのアイデンティティ部分である通信関係の処理に手を伸ばしたいのだが、普通にVulkanの設計に頭を悩ませている。
描画手順(いわゆるマテリアル)と描画先(レンダーターゲットと呼ぶことにしてみる)について
- マテリアルに依存するオブジェクト群
- レンダーターゲットに依存するオブジェクト群
- マテリアルとレンダーターゲットの双方に依存するオブジェクト群
が存在するのでどう管理したものかと思案中。
今のところ
- マテリアルを意味する抽象クラスを作り、マテリアルごとにそれの具象クラスを作る
- マテリアル具象クラスのインスタンスでマテリアルに依存するオブジェクト群を保持する
- マテリアル具象クラスのメソッドにレンダーターゲットを渡すことで両方に維持するオブジェクト群をまとめたオブジェクトを返すこととし、それをシステム管理クラスで保持する
といった設計を試行中。
マテリアルに依存するオブジェクトにデスクリプタセットとかも入れているが、実はその必要はなくてマテリアルのシェーダ側で受け取り方統一しようねということにしてしまえばよいのではという疑惑がある。今後とも設計を検討する。
モデルの読み込み関連にも手を付けたいところなので、メモリ関連の考察をちょっとしてみた。任意の人間が勝手なモデルを持ち込むというアプリの性質上、VRAMの管理はシビアになる。ざっくり多めに見積もって60000ポリゴンのモデルが一体居たとする。位置やUV座標などでおそらく一頂点当たり十数個のfloat値を持っていると考えると、大体3~5MBくらいのバッファが必要になる。しかしせいぜい3~5MBだ。最新のグラボなら数GBのVRAMがあるのでこの千倍は入る。問題はテクスチャの方で、2048×2048のテクスチャ一枚でおよそ16MBになる。モデル一体につき何枚も持っている場合もあるようだ。3枚で48MBとかになるので、線引きをするとしたらここいらな気がする。
せっかく全C++で作るのだから同時100人とかやってアピール材料にしたい。頂点・インデックスバッファと合わせて1モデル64MBくらいと見積もれば、この100倍でも今の一般的なGPUの8GBに収まる。通信速度や処理速度とかの問題は別途あるとして、メモリ容量的な見積もりはこんなところだろう。
なんにせよ今週はちょっとこれ以上このプロジェクトを進める余裕がなさそうなのでこのあたりでいったん中断にする。続きは来週以降。
昨日ジョギングしたあと足の付け根が痛んだのでジョギングはしばらく休むことにした。
Categories: 未分類