MARI パフォーマンス問題のトラブルシューティング

他のソフトウェアパッケージと同様、Mariは時々パフォーマンスが低下してしまうことがあります。大抵の場合はプロジェクトの莫大なサイズによってグラフィックスカードがオーバーロードする問題に関連しますが、ユーザーが実際にハードウェアを交換する前に考慮できる他の問題や理由も考えられます。

 


問題と解決策

  1. プロジェクトの中に複数のオブジェクトが含まれる

Mariは単一オブジェクトだけで作業するために最適化されています。(表示/非表示に関係なく)プロジェクトの中に複数のオブジェクトが存在すると、パフォーマンス ペナルティの原因になることがあります。シーンの中のオブジェクトの数によって、これらのペナルティ(負荷)は増加します。

TIP: 元のモデリングパッケージからAlembicまたはFBXファイルをエクスポートする前に異なるマテリアルをオブジェクトに割り当てると、Mariはその情報を考慮してSelection Setの作成に使用します。

 

  1. プロジェクトが効率的にリソースを活用していない

多くのレイヤーを使って作業している場合、「最終的なレイヤー」をキャッシュ化することをお勧めします。レイヤーのキャッシュ化は、レイヤーを右クリック > Cachingオプションから行えます。

解像度やビット深度は効率良く使用していることをご確認ください。もしも8ビットテクスチャをペイントしている場合は、8bitのペイントバッファをご使用いただけます。尚、ペイントバッファとVirtual Texture Atlasは、ペイントしているレイヤーのビット深度よりも高く設定されていることを常にご確認ください。

パフォーマンスの最適化についてはこちらの記事もご覧ください。

 

  1. ビューポート操作が遅くなる

この問題は大抵、GPUやモデルのシェーダーの複雑さに依存します。より複雑なシェーダーは必然的にパフォーマンスの低下を招きます。また、この問題は実際のディスプレイスメントやシャドウを表示することで大きな影響を受けます。

ディスプレイスメントやシャドウを無効化することで、パフォーマンスは大きく改善します。

4kモニタで作業している場合、Mariのビューポートは従来のHDモニタよりも多くのピクセルでレンダリングしなければなりません。これが原因で、ビューポートのレンダリング時間は、より少ないピクセルのモニタを使用している時よりも遅くなります。ビューポートが複数のモニタで重複する場合も、GPUは2つのディスプレイを同時に処理しなければならないため、パフォーマンスはわずかに低下します。

 

  1. WindowsでMariが頻繁にフリーズする

この問題はWindowsに設定されたTDR (Time Detection and Recovery)の時間とGPUドライバに関連する可能性があります。MariはGPUを激しく使用するため、いくつかの計算は2秒(デフォルトTDR制限)以上かかることがあります。これは、Windowsが操作をキャンセルしてGPUをリセットすることを示すため、フリーズの原因となります。回避するには、レジストリでTDRのタイムアウト値を上げてみてください。

重要: レジストリはWindowsの構成情報が格納されている非常に重要なデータベースです。レジストリの編集内容に問題があると、システムが起動しなくなる等、OSの再インストールを余儀なくされるような事態が発生する恐れがあります。弊社およびFoundry社ではレジストリの編集による如何なる問題に対しても保証をいたしかねます。レジストリの編集はお客様の責任で行っていただけますようお願い致します。
レジストリを編集する前には、バックアップを行っていただくことを推奨します。
TDRレジストリキーの詳細については、Microsoft社の記事(英語)をご覧ください。

 

  1. テクスチャのエクスポートが遅い

この問題はテクスチャ(ビット深度や解像度)の様々な要素に依存します。レイヤーの量、テクスチャをフラット化しているかどうか、そしてパッチの量などが考えられます。

大量のUDIMを持つプロジェクトで作業する場合、前回のエクスポートから変更を加えたパッチだけをエクスポートすることをお勧めします。レイヤー/チャンネル/パッチが変更したかどうかを確認するには、Mariセッションの開始時と終了時のハッシュを比較してみてください。ハッシュに違いがみられる場合は、レイヤー、チャンネル、またはパッチが「dirty」であることを示し、再エクスポートすることが可能です。

 

  1. ファイルを開く時間と保存する時間が遅い

Image Managerが数百個の参照画像で埋まることは良くあるミスです。各画像はプロジェクトの中に格納されるため、結果としてプロジェクトと一緒に保存されます。プロジェクトの保存または開く時間が予想以上に遅くなる場合は、Image Managerが不要にプロジェクトサイズを増やしている可能性があります。また、実際のモデルやテクスチャが小さいサイズを使っているにも関わらず、プロジェクトサイズが大きい場合にもこれが原因である可能性があります。

 

  1. 推奨ファイルシステム

Linuxユーザーにとって、EXT3またはEXT4ファイルシステムを使用することは、Mariがプロジェクトを読み込んだり書き込んだりする方法に自然に適しているため、大幅なパフォーマンスの改善が得られます。

Mariはアーカイブの保存時に大量の小さなファイルをキャッシュディレクトリに書き込みます。例えば、古い鍛冶屋(Blacksmith)のExampleプロジェクトでは、10-90 kBのファイルが75000個ありました。Foundry社内での検証では、EXT3またはNTFSのようなファイルシステムが、大量の小さなファイルを処理する際に最高のパフォーマンスを見せました。

比較すると、XFSファイルシステムでは同様のパフォーマンスは見られず、これはEXT (EXT3、EXT4、その他)と比べてやや遅いという報告をユーザーからも受けています。この理由により、現在のMariはXFSファイルシステム使用時に警告を表示しています。

 

以上の方法でも問題が解決しない場合は、弊社サポートまでお問い合わせください。
ご使用のシステム環境、問題の詳細、これまで行われた手順を合わせてご連絡いただけますと助かります。

 


関連リンク