サポートチケットを作成する
フォローする

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

概要

他のほとんどのソフトウェアパッケージと同様に、Mariはパフォーマンスが低下することがあります。これは巨大なサイズのプロジェクトでグラフィックカードが過負荷になっていることに関連していることが多くありますが、ハードウェアを変更する前にユーザーが対処できるパフォーマンスの低下の理由や理由がいくつかあります。この記事はこれらのケースのいくつかをカバーし、トラブルシューティングの提案を提供します。


症状と解決策

  1. プロジェクトに複数のオブジェクトが含まれています
    Mariは1つのオブジェクトに対してのみ機能するように最適化されています。プロジェクトに複数のオブジェクトがあると(可視性に関係なく)、パフォーマンスが低下します。これらのペナルティは、シーン内のオブジェクトの量とともに増加します。

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

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

    次の記事に、パフォーマンスの最適化に関するその他の提案があります。Q100188:Mariプロジェクトを最適なパフォーマンスに最適化する

  3. 遅いビューポートナビゲーション
    これは多くの場合、GPUとシェーダの複雑さおよびモデルによって異なります。より複雑なシェーダは必然的にパフォーマンスの低下を招くでしょう。これはまた、実際のディスプレイスメントや影を表示することによっても大きく影響されます。

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

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

  4. MariはWindowsでよくフリーズします
    これはWindowsとあなたのGPUドライバに設定されたTDR時間(時間検出と回復)と関係があるかもしれません。 MariはGPUを頻繁に使用しているため、一部の計算は2秒(デフォルトのTDR制限)より長く続くことがあります。これは、Windowsが操作をキャンセルしてGPUをリセットし、フリーズすることを意味します。これを回避するために、レジストリのTDRタイムアウト値を増やすことができます。

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

    TDRレジストリキーの詳細については、次のマイクロソフトの記事を参照してください

  5. テクスチャのエクスポートが遅い
    これは、テクスチャのさまざまな要因(ビット深度と解像度)、レイヤーの数、およびフラット化されたテクスチャをエクスポートするかどうか、およびパッチの数によって異なります。

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

  6. ゆっくりとした時間と節約の時間

    画像マネージャが数百の参照画像でいっぱいになるのはよくある間違いです。これらの各画像はプロジェクト内に保存されているため、一緒に保存する必要があります。プロジェクトの保存および開始時間が予想外に遅い場合は、Image Managerが不必要にプロジェクトのサイズを大きくしている可能性があります。実際のモデルとテクスチャのサイズが小さい場合、これは大きなプロジェクトサイズを説明することもあります。

    ヒント: Image Managerですべての画像を削除すると、次に開いたときに手続き型ノードで使用されている画像が自動的に復元されます。

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

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

    Mariはアーカイブを保存するときに非常に多数の小さなファイルをキャッシュディレクトリに書き込みます。たとえば、古い鍛冶屋のボディの例のような1つのプロジェクトには、それぞれ10〜90 KBの75000ファイルがあります。私たちの内部テストから、EXT3やNTFSのようなファイルシステムが、小さなファイルを大量に処理することに関して最高のパフォーマンスを提供していることに気づきました。

    比較すると、XFSファイルシステムを使用した場合のパフォーマンスが同じであることに気付いたことはありません。また、これはEXT(EXT3、EXT4など)と比べて動作が遅いという報告があります。これが、Mariが現在XFSファイルシステムを使用しているときに警告を表示している理由です。


    まだ問題がありますか?

    この記事に記載されている手順を実行しても問題が解決しない場合は、サポートチケットを開いて、発生している問題とこれまでに実行したトラブルシューティングの手順をお知らせください。調査に必要な情報は、 Q100090:Mari問題の報告に要約されています
    サポートチケットを開く方法の詳細については、「 サポートポータル使用 」の記事を参照してください。

この記事は役に立ちましたか?
/

We're sorry to hear that!

Please tell us why.
8人中3人がこの記事が役に立ったと言っています

コメント