Durian プロジェクト内での Sculptツールの開発状況

投稿日時 2009年11月17日 | カテゴリ： 技術・開発関連
元記事：Durian ≫ Blog Archive ≫ Sculpting Development

Durianブログに、Brecht氏による2週間の Sculpt ツール改良のフルタイム作業の成果が公開されています。画像はそれぞれ元記事からの引用です。

氏は2.5のUI中心の作業だったのが、3D関連の作業ができてうれしいと語っており、開発は Sculpt ブランチに分けて行われ、まだ安定はしないもののGraphicall.orgにテストビルドがアップロードされているそうです。
Nicholas Bishop氏とともに行ったスピードアップ作業では、まず二人で二カ月前に設定について議論を始め、境界ボリューム階層(BVH)を使用することを決め、その後Nicholas氏がそれを実装されたとのこと。これは Mesh をノードに分解し、木構造に再構築するもので、各ノードは約10000 Face を持ち、これは一般的な BVH のレイトレースや衝突判定探知での使用に比べると非常に荒い物とのこと。これは非常に少ないメモリオーバーヘッドと、木構造の構築を相対的に速くしたかったからだそうです。

この BVH は様々な最適化の中心となるもので、彼らは以下のように使用したとのこと。
[wiki]-Sculpt のストロークの衝突部分を探索に BVH へレイキャスト。
-変更されたノードのみ法線の再計算。
-ノード毎のもっとコンパクトな OpenGL Vertex Buffer の作成。
-ビュー錐体内のノードのみ再描画。
-スレッドにノードを分散してマルチスレッド計算。
-Undoバッファに変更されたノードのみ格納。
[/wiki]



Sculpt Mode 内のメモリ使用量の従来と今(200万ポリゴンの通常の Mesh)


BVH 導入により、Sculpt Mode のメモリ使用量が約半分に縮小されたそうで、他にも前掲のように、Undo バッファにもその恩恵があるとのこと。

Sculptのパフォーマンスも向上し、2.4xとの比較は難しいとしながらも、同じ状況でストロークに空白があいたりはしなくなったそうです。また、BVH のおかげで、高解像度モデルの一部だけの作業時には必要な頂点のみを計算する所為で非常に速度が改善されるそうです。
描画パフォーマンスは GPU が Vertex バッファに対応しているここと、格納する GPU のメモリにより大幅に速度が向上するとのこと。

スピードアップ作業の次に、氏は Multires の改良にとりかかっているそうで、最初の作業と比べると困難だが、だんだん見通しはついてきたとのこと。通常の Mesh に比べ、Multires にはメモリに優しいが、同じレベルにするには更に作業が必要だが、更なるメモリ効率が期待できるとのこと。また、高解像度ではサブサーフェス計算と、Apply、ディスプレイスメントの再計算の所為で、パフォーマンスに問題があるとのこと。



Sculpt Mode での800万ポリゴンの Multires Monkey。メモリ使用量に注意(このコードは未完成で、まだSVNでは使用できません)


他に彼らが取り組んでいる問題に、プロダクションパイプラインへの統合があります。ファイル読み込み時、Multires を持っているすべての Mesh を一度にメモリに読み込まれた場合、メモリに入りきらず、非常に遅くなるだろうと予測されます。その解決策として、ディスプレイスメントマップへの Bake が一般的です。Blender が Sculpt ツールとレンダリングツールを持つことで、このワークフローをユーザが余計な手間を踏まないよう、もっとスムーズにできるのではないか、と氏は考えているそうです。

彼らはその方法として、Multires ディスプレイスメントマップの .blendファイルもしくは外部ファイルからのオンデマンド読み込みを検討しているそうです。これは Sculpt Mode に入った時にのみ、ディスプレイスメントマップをメモリに読み込み、それ以外の時はメモリ上に持たないようにする方法ですが、これは Blender ではあまりいい慣例ではないため、別の実装方法を検討しているとのことです。

なにかとんでもないことになっている様子ですね。Sintelがどんな映像になるか想像もつきません。期待に胸がふくらみますね。


Blender.jpにて更に多くのニュース記事をよむことができます
https://blender.jp

このニュース記事が掲載されているURL：
https://blender.jp/modules/news/index.php?page=article&storyid=2671