フォローする

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

概要

他のソフトウェアと同じように、Mariはパフォーマンスが低下することがあります。多くの場合、これはグラフィックスカードに膨大なサイズのプロジェクトがオーバーロードされていることに関連していますが、ハードウェアを変更する前にユーザーが対処できることがあります。この記事では、これらのケースのいくつかについて説明し、トラブルシューティングのヒントを提供します。 

現象と解決策

  1. プロジェクトに複数のオブジェクトが含まれている
    可視性に関係なく、プロジェクトに複数のオブジェクトがあると、パフォーマンスが低下します。これら低下の原因は、シーン内のオブジェクトの量とともに増加します。

    ヒント:オリジナルのモデリングパッケージからalembicまたはfbxファイルとしてエクスポートする前に、オブジェクトに異なるマテリアルを割り当てると、Mariはその情報を尊重してセレクションセットを作成します。

  2. プロジェクトでリソースが効率的に使用されていない
    多くのレイヤーを使用して作業している場合は、「完成したレイヤー」をキャッシュすることをお勧めします。
    解像度とビット深度を効率的に使用していることを確認してください。8ビットのテクスチャをペイントする場合は、8ビットのペイントバッファを使用できます。ただし、ペイントバッファとバーチャルテクスチャアトラスは、ペイントしているレイヤよりもビット深度を低く設定しないでください。

  3. ビューポートナビゲーションが遅い
    これは、GPUやシェーダとモデルの複雑さによって決まることがよくあります。より複雑なシェーダは必然的にパフォーマンスの低下を招きます。これはまた、ディスプレイスメントとシャドウを表示することによって大きく影響されます。

    ディスプレイスメントとシャドウを無効にすると、パフォーマンスが大幅に向上します。

    4kモニタで作業している場合、これはMariが従来のHDモニタよりも多くのピクセルをビューポートにレンダリングする必要があることを意味します。このため、ビューポートのレンダリング時間は、ピクセル数の少ないモニタを使用する場合ほど速くない場合があります。Viewportが複数のモニタにオーバーラップしている場合、GPUは2つのディスプレイを同時に提供する必要があるため、パフォーマンスもわずかに低下します。 

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

    注:レジストリを直接編集すると、システムが起動しなくなる可能性があり、オペレーティングシステムの再インストールが必要になることがあります。Foundryは、システムレジストリを変更することにより、システムに生じたいかなる損害に対しても責任を負いません。

    TDRレジストリキーの詳細については、次のMicrosoftの記事を参照してください。

  5. テクスチャの書き出しが遅い
    これは、テクスチャのさまざまな要因(ビット深度と解像度)、レイヤーの量、およびフラットにされたテクスチャを書き出す場合、パッチの量によって異なります。

    大量のUDIMを持つプロジェクトで作業している場合は、最後の反復以降に変更されたパッチのみをエクスポートすることをお勧めします。レイヤー/チャンネル/パッチが変更されているかどうかを確認するには、Mariセッションの開始時と終了時にハッシュを比較できます。ハッシュに違いがある場合、レイヤー、チャンネルまたはパッチは「ダーティ」であり、再エクスポートすることができます。

  6. プロジェクトの保存/終了が遅い

    Image Managerに多数の数量が埋め込まれているのはよくある間違いです。これらの画像はそれぞれプロジェクト内に保存されます。予期せずにプロジェクトの保存時間と開始時間が遅い場合は、Image Managerが不必要にプロジェクトのサイズを増やしている可能性があります。

    ヒント:イメージマネージャーのすべてのイメージを削除すると、次回のオープン時にプロシージャルノードで使用されるイメージが自動的に復元されます。

  7. 推奨されるファイルシステム

    Linux上のユーザーは、Mariがプロジェクトを読み書きする方法に適しているため、EXT3またはEXT4ファイルシステムを使用するとパフォーマンスが大幅に向上することがあります。

    Mariは、アーカイブを保存するときにキャッシュディレクトリに非常に多数の小さなファイルを書き込みます。example projectのold blacksmith body exampleプロジェクトでは、75,000ファイルがそれぞれ10〜90KBです。私たちの内部テストから、EXT3やNTFSのようなファイルシステムは、多数の小さなファイルを扱う際に最高のパフォーマンスを提供していることがわかりました。

    これと比較して、XFSファイルシステムを使用した場合と同じパフォーマンスに気付かず、EXT(EXT3、EXT4など)と比較してかなり遅いとユーザーが報告しています。このためMariは現在、XFSファイルシステムを使用しているときに警告を表示しています。

 

Foundryサポートサイト記事番号:Q100253

0 コメント

記事コメントは受け付けていません。