「シーンの最適化の例1」の編集履歴（バックアップ）一覧はこちら

「シーンの最適化の例1」(2020/05/16 (土) 15:31:28) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

サポート活動の過程で、ユーザーのシーンを頻繁に取得して、レンダリング時間やクオリティを改善し、アーティストの全体的な生産性を向上させる事が出来ます。一般的な最適化ガイドは非常に役立つ可能性がありますが、これらの手法と概念をサンプルユーザーシーンに具体的に適用する方法を確認する事も役立つと考えました。これが、私たちが調査するいくつかの異なる実世界のケースになることを期待する最初のものです。(著:Oshyan Greene)

今回のシーンは、[[コミュニティフォーラム>https://planetside.co.uk/forums/]]のユーザ&bold(){RichTwo氏}からの投稿です。このユーザは、Terragenの熟練したアーティストで、長い歴史と独特のスタイルを持ち、しばしば砂漠や不毛のエイリアンの世界を描いています。Richは、パストレース(Terragen 4.4の新機能)を実験しており、負担のない処理よりも長いレンダリング時間を経験していました。この有望な新機能で実験を放棄するのではなく、私たちは彼が最適化を支援することを提案し、劇的な肯定的な結果を得ました！レンダリング時間を開始時の5分の1に短縮した方法の詳細をお読み下さい(以下のすべての文章は、[[元のサポートスレッド>https://planetside.co.uk/forums/index.php/topic,26874.15.html]]の返信で直接Richに宛てられたものです)。

確かに平均よりも複雑で非常に大規模なノードネットワークから始まります。以下の画像では、広範なサブネットワークを持つ複数のノードもあります。合計で100以上のノード！これ自体が最適化の取り組みの主要なターゲットになる可能性がありますが、シェーダ構成に深く入り込む事なく何が出来るかを見てみましょう。

#image(richtwo-node-network-support-diary.jpg,width=530,height=315,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1900/richtwo-node-network-support-diary.jpg)

*大気の最適化
標準レンダラーとパストレースの両方に適用されるため、ここから始めます。そのため、シーンでパストレーシング(PT)を使用しなくても、これらの調整はやってみる価値があります。

ここでの標準レンダリングでも、レンダリング時間に与える大きな影響の1つは、雲層です。クオリティを2にしていますが実際にはメリットがありません。1のクオリティで問題ない事が分かり、&bold(){gao_jian11氏}が言ったように0.5でも上手くいくようにも思いますが、ノイズが少なくても、クオリティが1レベルのディティールを目に見えて失うかもしれません。このような薄い雲(深さ100メートル未満)については、一般的に比較的低いクオリティレベルで問題ありません。また、"Conservative Acceleration"を有効にしてもレンダリングのクオリティに悪影響が出ない事を発見し、時間を節約しました。高レベルの加速は、"Optimal(最適)"であっても、レンダリングによるチラつきゴミを引き起こす事があります。そのため、雲のクオリティを1に設定し、"Conservative Acceleration"を有効にしました。一般的に、これらは他のシーン、特に『Cloud layer v2』で目指す安全な値です。
|&image(Atmosphere_org.jpg)|&image(Atmosphere_cus.jpg)|
|CENTER:オリジナル|CENTER:改善提案|
もう1つお勧めするのは、標準レンダリングの場合でも"Defer Atmo/cloud"を有効にする事です。パストレースを有効にすると、"Defer All"が自動的に有効になり、これにより大気のレンダリングが「後回し」されます。"Defer Atmo/cloud"を使用すると、特に適応型アンチエイリアスが使用されている場合は、同等のレンダリング時間で高いクオリティの大気レンダリングが可能になります。また、パストレースの使用を検討している場合は、"Atmo / Defer All"レンダリングを最適化する事は理にかなっています。他の設定を変更せずに"Defer Atmo/cloud"を有効にすると、結果のクオリティが向上する可能性がありますが、レンダリング時間が長くなる可能性がある事に注意して下さい。クオリティとレンダリング時間のバランスを改善するには、最初のサンプリングレベルやピクセルノイズのしきい値などを調整し、ロバストアダプティブサンプラーを使用する事が考えられます。ただし、その上でこれらに変更を加え、それから今後に向けて継続的に使用する事が一般的に価値があります。

注意すべき興味深い点の1つは、これらの最適化は有益ですが、"Defer Atmo/cloud"または"Defer All"を有効にすると、ロバストアダプティブサンプラーが使用され、アンチエイリアスの適応性が向上します。つまり、雲のクオリティが高いとレンダリング時間への影響は比較的少なくなります。これはおそらく、ロバストアダプティブサンプリングシステムがサンプルを配置する場所をより適切に決定する事が出来るため、少ないサンプルで軽易にレンダリングされる雲のノイズのない部分での不要なレンダリング時間を回避できるためです。

*パストレース(、および"Defer All"）の最適化
Wikiに追加し始めた進行中の[[レンダリング最適化ガイド]]をご覧下さい。最初はす"Defer All"と"Path Tracing"に焦点を当てており、サンプルシーンを使用して、問題点となる推奨事項を抽出してテストしました。このドキュメントには、最終的に大気などに関する詳細情報が追記される予定ですが、パストレースと遅延についてはすべて書き出されています。

上記の情報を基にすると、特にパストレースのレンダリング時間を大幅に短縮する事が出来ます。ロバストアダプティブサンプリングを使用すると、特に"Defer All"とパストレースの両方に役立ちます。ただし、複雑で荒々しいディスプレースメントのためにシーン内でマイクロポリゴンのディティール(MPD)を減らす事は、マイナスの効果があるため、ここでは変更しません。MPDへの比較的小さな調整からのこの種の明らかなジオメトリの変更は、一般に問題となる可能性のある「折り畳まれた」または重複したディスプレースメントの指標であることが多いため、改善を検討する必要があるかもしれません(他の人が言及している地形シェーダの複雑さの問題については、以下で触れます)。ただし、シーンを現状維持でレンダリングする場合は、MPDを0.6のままにして下さい。

注意すべきもう一点は、上記ガイドで説明されているように、より高い適応性を使用すると、非常に細かい、ピンポイントの明るい、一方または両方の「ノイズのある」領域の強度が低下する傾向がある事です。これらの種類のピンポイントの明るい場所が実際に望ましいレンダリング状況は比較的少数です(多くのレンダラーの同類のレンダリングによるごみなどは実際には「ファイアフライ(ノイズ)」と呼ばれ、それらを除去するための多くの手法が存在します)。しかし、シーン内のプロシージャルの星シェーダ(『Basic Stars v1.1 by WASasquatch』)の場合、明るいポイントは"要望通り"であり、1/256および1/64の最初のサンプルでも大幅に最小化されます。これにはいくつかの解決策があります。
|&image(First_sample_org.jpg)|&image(First_sample_cus.jpg)|
|CENTER:オリジナル|CENTER:改善提案|

1つ目は、Adaptivity(適応性)を下げる事が出来ますが、特にパストレースの場合、レンダリングのスピードアップの一部が失われます。適応性の高いレベル(1/256～1/1024)は、シーンの速度を大幅に向上しなかったように思うため、この場合は"最も効果、効率の良いポイント"のように思われた1/64を使用しました。しかしながら、パストレースを使うシーンではしばしば1/256を使う事もあります。星は1/64でより見やすくなりますが、サンプル数の最大値と比較するとさらに少なくなります。1/16では、すべての星が見えるわけではありませんが、それでも見えなくはありません。これは、基になるプロシージャルの星シェーダを調整するか、違った形でシーンの1つの小さな特徴を保持するためだけに、重要なレンダリング最適化を無効にする必要がある時に、代替案を使用する事を示唆しています。2つ目は、プロシージャルの星シェーダ自体を調整して強度を高めたり、明るいポイントをわずかに大きくしたりすると、アダプティブサンプリングでの処理が容易になります。3つ目は、スターフィールドのイメージマップを使用する事で、この正確な外観を複製するのは難しいかもしれませんが、より適切に機能するはずであり、わずかながらより速くレンダリングする事も出来ます。

最終的に、パストレースを元の設定での約2.5時間(PC依存)から約30分に短縮しました。かなりの時間の節約です。ただし、最適化後、"Defer All"レンダリングは7分弱であったため、つまり、最適化後のパストレースはかなりのレンダリング時間をパーセンテージ単位で追加するがゆえに、差はそれほど劇的ではありませんでした。元の設定で"Defer All"にするのはパストレースで2.5時間だったのに対して1.5時間だったので、おそらく元の設定での効率の問題のために、興味深い変化です。パストレースが現在追加している時間は、"Defer All"に比べて時間の増加という点で、予期しているよりも多いと思います。

これは、元の設定である2.5時間のパストレース結果です。
#image(Rock-Study-Orig2_FIXED-TESTS_2h28m18s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1906/Rock-Study-Orig2_FIXED-TESTS_2h28m18s-v4.4.18.1.jpg)

そして、これは最適化されたバージョン、27分です。
#image(Rock-Study-Orig2_opt3_FIXED-TESTS_PT-1-64-05-thresh_27m14s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1907/Rock-Study-Orig2_opt3_FIXED-TESTS_PT-1-64-05-thresh_27m14s-v4.4.18.1.jpg)

もちろん、星の視認性が低下している事に注目して下さい。ただし、それ以外の場合、2つは非常に近く、最適化されたバージョンのレンダリング時間の1/5になります。

*パストレースと標準レンダリングの比較および"Defer All"
パストレースのレンダリング時間がこのように長くなっている場合(最適化後でも)、使用する価値があるかどうかを判断したいと思います。そのためには、「リンゴとリンゴ(同一条件での比較)」を比較するのが最善です。つまり、"Standard renderer"＋"Defer All"のレンダリングでGIを使用し、GISDを使用し、地形の"Enviro Light"設定がパストレースでは考慮されないという事実など、比較における他の制限を認識している事を意味します。

今回のシーンでは、適した比較を生ずる能力を制限したいくつかの問題がありました。1つ目は、"GI sample quality"が0であり、技術的にはなおもGIを計算しますが、精度の点で非常に低い値であるため、連続するレンダリング間で照明結果が劇的に異なる場合があります。まったく同じシーンを連続して2回レンダリングするだけでも、特に影の領域では、照明が著しく異なる場合があります。そこで、少なくとも2の値を使用します。これは、レンダリング時間に劇的な影響を与えません。理想的には、(実際に)直接比較するためにGIキャッシュファイルを使用する事により、パストレースレンダリングと非パストレースレンダリングが同じGIキャッシュを使用する事が保証されます。

2つ目は、GISDが無効になっている事です。GISDは概算ですが、簡単なものであり、見た目のリアリズムに追加され、特に影のある領域の照明のディティールとクオリティを劇的に高めます。パストレースが影のある領域にもたらすよりより大きなディティールに目を向けたい場合は、おそらくGISDも使用する必要があります。精度は劣りますが同様の利点があります。とはいえ、興味深いことに、特定のシーンではGISDが影にディテールをいくらか追加しましたが、実際にはそれらの領域とパストレースで少し異なって見える事になり、GISDが無効の非パストレースバージョンは、おそらくこの理由により簡単にパストレースに合うように調整する事が出来ます。GISDは非常に高速であるため、通常は有効のままにしておく価値があります。今回のように異なって見えるのは、極端なディスプレースメントと、ここでのジオメトリの断裂または積み重ねの可能性だと思います。

最後に、『Enviro light』の"Strength on surfaces"が、デフォルトの1ではなく0.85に設定されます。これは標準レンダラーでは問題ではありませんが、パストレースはそれを無視し、値=1(同等)を効果的に使用するため、 パストレースレンダリングで全体的に明るくなるのは、パストレースがより正確である事の直接的な結果ではなく、単にこの設定によって標準レンダリングがより明るくなるために偏らせているためです。従って、真に直接比較するために、『Enviro light』の"Strength on surfaces"を1に再設定する必要があります。

これらをすべて修正してみると、パストレースと標準レンダリングまたは"Defer All"レンダリングの照明の違いはそれほど劇的ではない事が分かりました。顕著な違いは、おそらくいくつかの単純な後処理で再現出来るように思われ、例えば、影の明るさやコントラストを高める場合、ほとんどの画像編集ソフトには、このような後処理を行うツールがあります。この理由から、個人的な見方では、パストレースの結果は、この場合のレンダリング時間を正当化するほど重要ではありません。特に、パストレースを高速化する最適化が行われている場合の星への影響を考えると、 もちろん、前述のように、プロシージャルの星シェーダの代わりにイメージマップを使用するか、プロシージャルの星シェーダの設定を調整する事で修正が可能に思われます。もちろん、最終的には、レンダリング時間に見合うだけのパストレース結果を好むかどうかはあなた次第です。

パストレースを無効にしてGISDを使用した、"Defer All"の結果です。
#image(Rock-Study-Orig2_opt3_FIXED-TESTS_non-PT-1-64_06m46s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1908/Rock-Study-Orig2_opt3_FIXED-TESTS_non-PT-1-64_06m46s-v4.4.18.1.jpg)

*複雑な地形シェーダの影響
雲のクオリティを下げてロバストアダプティブサンプラーを有効にすると、空は実際にかなり速くレンダリングされましたが、地形はなおもかなり低速でした。そこで、私は地形のディスプレイスメントネットワークの一部を無効にするレンダリングを数回行い、レンダリングにかかる時間を確認しました。興味深い事に、いくつかのジオメトリの不連続性を引き起こすいくつかの激しいディスプレースメントがありますが、大規模な地形のディスプレースメント、折り重なりなどは、ここでの地形レンダリング時間の最大の要因ではありません。実際には、"Basic Color Layers & Stones"グループ、特に"FinalStoneComplex_4"が主な原因です。


そのネットワーク内を見ると、多数の『Fake stones shaders』とディスプレイスメントを作成する『Power fractal shader』の非常に複雑な配置であり、そのほとんどすべてが小さなサイズです。このネットワークは、それが作成された状況ではうまく機能しているかもしれませんが、このシーンでは細部の多くが失われているように見えるのに対し、それでもレンダリング時間に大きな影響を与えています。テスト環境では、このグループの石を無効にするだけで、27分間のレンダリングが23分間になりました。絶対的な意味ではそれほど多くないように思えるかもしれませんが、全体のレンダリング時間におよそ15%が追加され、遅いマシン環境では絶対的な時間差が増大します。そして、おそらく3〜4層の偽造石と非変位のパワーフラクタル1〜2層がおそらく結果の大部分を複製すると推測します。
これは、これらの石を無効にした場合の外観です。
#image(DRock-Study-Orig2_opt4_FIXED-TESTS_PT-stones-only-disabled_23m10s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1909/DRock-Study-Orig2_opt4_FIXED-TESTS_PT-stones-only-disabled_23m10s-v4.4.18.1.jpg)

さらに、かなり複雑なシェーダネットワークが他にもいくつかありますが、最終画像への影響は、その複雑さを考えると、期待や予測したものよりも少ないようです。それらはレンダリング時間をそれほど増やしていないようですが、前述の重複したしたディスプレースメントジオメトリに寄与していると思います。これはさまざまな理由で問題になる可能性があります。これらの設定のいくつかは、おそらくドロップイン共有ネットワークまたはそれに基づくものであり、それは学習し、シーンをより簡単かつ迅速に複雑にする(視覚的な結果)ための素晴らしい方法だと思います。しかし、効率とこれらの複雑なネットワークが最終的な作業に実際にどれほど貢献するかとのバランスを取るべきだと思います。

相対的に言えば、これが複雑なネットワークであるとは思わない事を理解していますが、そうで事実かどうかにかかわらず、考慮すべきより重要な事は、シェーダ設定の複雑さが、よりはっきりと結果の複雑さまたは特異性に相当するかどうかです。希に、ほんのわずかな成果を上げるために多くのノードを使用する事で簡単に実現出来る場合がありますが、多くの場合、代償としてレンダリング時間が長くなります。このため、複雑さは本質的に悪くはありませんが、理想的には効率とのバランスを取る必要があります。

従って、これはノードの構築時に注意すべき事です。効率化を図り、可能な限り少ないノードで目標を達成しようとすることは有益です。これにより、レンダリングに費やす時間が短縮されるため、改善のための試行を繰り返す時間を得る事が出来るでしょう！

*より突っ込んだ最適化
&bold(){ハイトフィールドへの変換}
地形はかなり急勾配のように見えますが、顕著に突き出してはいません。それでも、基本的な主要な形状はおそらくハイトフィールドとして作成して保存出来ると思うので、これらのベースライン計算(谷や主要な岩の形状など)を一度だけ実行ます。その後、ディティールに付加的なディスプレースメントを適用しますが、連続するレンダリングで計算時間をいくらか節約する事が可能です。基本的な手法は、地形シェーダネットワークの出力を『Heightfield Generate』ノードの"Shader"入力端子に接続し、『Heightfield Generate』をスケーリングして配置し、地形の視野/影響を及ぼす領域をカバーし、十分なディティール(例えば、2000 x 2000または4000 x 4000)のために十分な"Number of points"を設定します。そして、地形を生成し、『Heightfield Generate』ノードを右クリックして「Save file as ...」を選択し、ハイトフィールド(.ter)として保存します。次に、『Heightfield Load』ノードを追加して、先ほど保存したハイトフィールドを読み込み、最終的に『Heightfield Generate』に供給したした地形生成パーツから分割させた後、シェーディングネットワークの残りの入力端子に接続します。この手法は一見少し難しいように聞こえますが、一度やってみるとても簡単です。常の手法ではありませんが、大規模な地形の計算に時間がかかる事が見えてきた場合は、これが上手くいくかもしれません。これにより、亀裂などのよりきめ細かな地形のディティールに集中させる事が出来るため、すべてのレンダリングが高速になります。ハイトフィールドの制限として、オーバーハングの地形が作成出来ない事や、有限のディティールなどの制限に留意して下さい。．．モノは試しにやってみましょう。

&bold(){第二惑星のディスプレースメント}
第二惑星内には、ディスプレースメントを追加するノードの集まりがあります。しかし、最終的なレンダリングの全体的な効果は、この距離から見る分だと惑星の表面をその集まり分だけ大きく下方に変異する程度と同等です。惑星の実際の"形状"は変化せず、文字通り、惑星の半径が縮んだ一方大気は同じままのように見えます。惑星は画像の中で大きなスペースを占有しませんが、必要以上にレンダリングを遅くしています。単にディスプレースメントのノードを無効(色を提供するノードは無効にしない)にした場合、その見た目の違いはごくわずかです。ただし、基本的に高高度の大気の効果を実行する場合は、『Atmosphere』の高さと"Ceiling/Floor(「Height control」タブ)"を調整する事で達成する事が出来るでしょう。または、分かりやすい簡単な方法で惑星を下方向に変異する方法を考え出す事が出来ます。

*その他の事

サポート活動の過程で、ユーザーのシーンを頻繁に取得して、レンダリング時間やクオリティを改善し、アーティストの全体的な生産性を向上させる事が出来ます。一般的な最適化ガイドは非常に役立つ可能性がありますが、これらの手法と概念をサンプルユーザーシーンに具体的に適用する方法を確認する事も役立つと考えました。これが、私たちが調査するいくつかの異なる実世界のケースになることを期待する最初のものです。(著:Oshyan Greene)

今回のシーンは、[[コミュニティフォーラム>https://planetside.co.uk/forums/]]のユーザ&bold(){RichTwo氏}からの投稿です。このユーザは、Terragenの熟練したアーティストで、長い歴史と独特のスタイルを持ち、しばしば砂漠や不毛のエイリアンの世界を描いています。Richは、パストレース(Terragen 4.4の新機能)を実験しており、負担のない処理よりも長いレンダリング時間を経験していました。この有望な新機能で実験を放棄するのではなく、私たちは彼が最適化を支援することを提案し、劇的な肯定的な結果を得ました！レンダリング時間を開始時の5分の1に短縮した方法の詳細をお読み下さい(以下のすべての文章は、[[元のサポートスレッド>https://planetside.co.uk/forums/index.php/topic,26874.15.html]]の返信で直接Richに宛てられたものです)。

確かに平均よりも複雑で非常に大規模なノードネットワークから始まります。以下の画像では、広範なサブネットワークを持つ複数のノードもあります。合計で100以上のノード！これ自体が最適化の取り組みの主要なターゲットになる可能性がありますが、シェーダ構成に深く入り込む事なく何が出来るかを見てみましょう。

#image(richtwo-node-network-support-diary.jpg,width=530,height=315,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1900/richtwo-node-network-support-diary.jpg)

*大気の最適化
標準レンダラーとパストレースの両方に適用されるため、ここから始めます。そのため、シーンでパストレーシング(PT)を使用しなくても、これらの調整はやってみる価値があります。

ここでの標準レンダリングでも、レンダリング時間に与える大きな影響の1つは、雲層です。クオリティを2にしていますが実際にはメリットがありません。1のクオリティで問題ない事が分かり、&bold(){gao_jian11氏}が言ったように0.5でも上手くいくようにも思いますが、ノイズが少なくても、クオリティが1レベルのディティールを目に見えて失うかもしれません。このような薄い雲(深さ100メートル未満)については、一般的に比較的低いクオリティレベルで問題ありません。また、"Conservative Acceleration"を有効にしてもレンダリングのクオリティに悪影響が出ない事を発見し、時間を節約しました。高レベルの加速は、"Optimal(最適)"であっても、レンダリングによるチラつきゴミを引き起こす事があります。そのため、雲のクオリティを1に設定し、"Conservative Acceleration"を有効にしました。一般的に、これらは他のシーン、特に『Cloud layer v2』で目指す安全な値です。
|&image(Atmosphere_org.jpg)|&image(Atmosphere_cus.jpg)|
|CENTER:オリジナル|CENTER:改善提案|
もう1つお勧めするのは、標準レンダリングの場合でも"Defer Atmo/cloud"を有効にする事です。パストレースを有効にすると、"Defer All"が自動的に有効になり、これにより大気のレンダリングが「後回し」されます。"Defer Atmo/cloud"を使用すると、特に適応型アンチエイリアスが使用されている場合は、同等のレンダリング時間で高いクオリティの大気レンダリングが可能になります。また、パストレースの使用を検討している場合は、"Atmo / Defer All"レンダリングを最適化する事は理にかなっています。他の設定を変更せずに"Defer Atmo/cloud"を有効にすると、結果のクオリティが向上する可能性がありますが、レンダリング時間が長くなる可能性がある事に注意して下さい。クオリティとレンダリング時間のバランスを改善するには、最初のサンプリングレベルやピクセルノイズのしきい値などを調整し、ロバストアダプティブサンプラーを使用する事が考えられます。ただし、その上でこれらに変更を加え、それから今後に向けて継続的に使用する事が一般的に価値があります。

注意すべき興味深い点の1つは、これらの最適化は有益ですが、"Defer Atmo/cloud"または"Defer All"を有効にすると、ロバストアダプティブサンプラーが使用され、アンチエイリアスの適応性が向上します。つまり、雲のクオリティが高いとレンダリング時間への影響は比較的少なくなります。これはおそらく、ロバストアダプティブサンプリングシステムがサンプルを配置する場所をより適切に決定する事が出来るため、少ないサンプルで軽易にレンダリングされる雲のノイズのない部分での不要なレンダリング時間を回避できるためです。

*パストレース(、および"Defer All"）の最適化
Wikiに追加し始めた進行中の[[レンダリング最適化ガイド]]をご覧下さい。最初はす"Defer All"と"Path Tracing"に焦点を当てており、サンプルシーンを使用して、問題点となる推奨事項を抽出してテストしました。このドキュメントには、最終的に大気などに関する詳細情報が追記される予定ですが、パストレースと遅延についてはすべて書き出されています。

上記の情報を基にすると、特にパストレースのレンダリング時間を大幅に短縮する事が出来ます。ロバストアダプティブサンプリングを使用すると、特に"Defer All"とパストレースの両方に役立ちます。ただし、複雑で荒々しいディスプレースメントのためにシーン内でマイクロポリゴンのディティール(MPD)を減らす事は、マイナスの効果があるため、ここでは変更しません。MPDへの比較的小さな調整からのこの種の明らかなジオメトリの変更は、一般に問題となる可能性のある「折り畳まれた」または重複したディスプレースメントの指標であることが多いため、改善を検討する必要があるかもしれません(他の人が言及している地形シェーダの複雑さの問題については、以下で触れます)。ただし、シーンを現状維持でレンダリングする場合は、MPDを0.6のままにして下さい。

注意すべきもう一点は、上記ガイドで説明されているように、より高い適応性を使用すると、非常に細かい、ピンポイントの明るい、一方または両方の「ノイズのある」領域の強度が低下する傾向がある事です。これらの種類のピンポイントの明るい場所が実際に望ましいレンダリング状況は比較的少数です(多くのレンダラーの同類のレンダリングによるごみなどは実際には「ファイアフライ(ノイズ)」と呼ばれ、それらを除去するための多くの手法が存在します)。しかし、シーン内のプロシージャルの星シェーダ(『Basic Stars v1.1 by WASasquatch』)の場合、明るいポイントは"要望通り"であり、1/256および1/64の最初のサンプルでも大幅に最小化されます。これにはいくつかの解決策があります。
|&image(First_sample_org.jpg)|&image(First_sample_cus.jpg)|
|CENTER:オリジナル|CENTER:改善提案|

1つ目は、Adaptivity(適応性)を下げる事が出来ますが、特にパストレースの場合、レンダリングのスピードアップの一部が失われます。適応性の高いレベル(1/256～1/1024)は、シーンの速度を大幅に向上しなかったように思うため、この場合は"最も効果、効率の良いポイント"のように思われた1/64を使用しました。しかしながら、パストレースを使うシーンではしばしば1/256を使う事もあります。星は1/64でより見やすくなりますが、サンプル数の最大値と比較するとさらに少なくなります。1/16では、すべての星が見えるわけではありませんが、それでも見えなくはありません。これは、基になるプロシージャルの星シェーダを調整するか、違った形でシーンの1つの小さな特徴を保持するためだけに、重要なレンダリング最適化を無効にする必要がある時に、代替案を使用する事を示唆しています。2つ目は、プロシージャルの星シェーダ自体を調整して強度を高めたり、明るいポイントをわずかに大きくしたりすると、アダプティブサンプリングでの処理が容易になります。3つ目は、スターフィールドのイメージマップを使用する事で、この正確な外観を複製するのは難しいかもしれませんが、より適切に機能するはずであり、わずかながらより速くレンダリングする事も出来ます。

最終的に、パストレースを元の設定での約2.5時間(PC依存)から約30分に短縮しました。かなりの時間の節約です。ただし、最適化後、"Defer All"レンダリングは7分弱であったため、つまり、最適化後のパストレースはかなりのレンダリング時間をパーセンテージ単位で追加するがゆえに、差はそれほど劇的ではありませんでした。元の設定で"Defer All"にするのはパストレースで2.5時間だったのに対して1.5時間だったので、おそらく元の設定での効率の問題のために、興味深い変化です。パストレースが現在追加している時間は、"Defer All"に比べて時間の増加という点で、予期しているよりも多いと思います。

これは、元の設定である2.5時間のパストレース結果です。
#image(Rock-Study-Orig2_FIXED-TESTS_2h28m18s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1906/Rock-Study-Orig2_FIXED-TESTS_2h28m18s-v4.4.18.1.jpg)

そして、これは最適化されたバージョン、27分です。
#image(Rock-Study-Orig2_opt3_FIXED-TESTS_PT-1-64-05-thresh_27m14s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1907/Rock-Study-Orig2_opt3_FIXED-TESTS_PT-1-64-05-thresh_27m14s-v4.4.18.1.jpg)

もちろん、星の視認性が低下している事に注目して下さい。ただし、それ以外の場合、2つは非常に近く、最適化されたバージョンのレンダリング時間の1/5になります。

*パストレースと標準レンダリングの比較および"Defer All"
パストレースのレンダリング時間がこのように長くなっている場合(最適化後でも)、使用する価値があるかどうかを判断したいと思います。そのためには、「リンゴとリンゴ(同一条件での比較)」を比較するのが最善です。つまり、"Standard renderer"＋"Defer All"のレンダリングでGIを使用し、GISDを使用し、地形の"Enviro Light"設定がパストレースでは考慮されないという事実など、比較における他の制限を認識している事を意味します。

今回のシーンでは、適した比較を生ずる能力を制限したいくつかの問題がありました。1つ目は、"GI sample quality"が0であり、技術的にはなおもGIを計算しますが、精度の点で非常に低い値であるため、連続するレンダリング間で照明結果が劇的に異なる場合があります。まったく同じシーンを連続して2回レンダリングするだけでも、特に影の領域では、照明が著しく異なる場合があります。そこで、少なくとも2の値を使用します。これは、レンダリング時間に劇的な影響を与えません。理想的には、(実際に)直接比較するためにGIキャッシュファイルを使用する事により、パストレースレンダリングと非パストレースレンダリングが同じGIキャッシュを使用する事が保証されます。

2つ目は、GISDが無効になっている事です。GISDは概算ですが、簡単なものであり、見た目のリアリズムに追加され、特に影のある領域の照明のディティールとクオリティを劇的に高めます。パストレースが影のある領域にもたらすよりより大きなディティールに目を向けたい場合は、おそらくGISDも使用する必要があります。精度は劣りますが同様の利点があります。とはいえ、興味深いことに、特定のシーンではGISDが影にディテールをいくらか追加しましたが、実際にはそれらの領域とパストレースで少し異なって見える事になり、GISDが無効の非パストレースバージョンは、おそらくこの理由により簡単にパストレースに合うように調整する事が出来ます。GISDは非常に高速であるため、通常は有効のままにしておく価値があります。今回のように異なって見えるのは、極端なディスプレースメントと、ここでのジオメトリの断裂または積み重ねの可能性だと思います。

最後に、『Enviro light』の"Strength on surfaces"が、デフォルトの1ではなく0.85に設定されます。これは標準レンダラーでは問題ではありませんが、パストレースはそれを無視し、値=1(同等)を効果的に使用するため、 パストレースレンダリングで全体的に明るくなるのは、パストレースがより正確である事の直接的な結果ではなく、単にこの設定によって標準レンダリングがより明るくなるために偏らせているためです。従って、真に直接比較するために、『Enviro light』の"Strength on surfaces"を1に再設定する必要があります。

これらをすべて修正してみると、パストレースと標準レンダリングまたは"Defer All"レンダリングの照明の違いはそれほど劇的ではない事が分かりました。顕著な違いは、おそらくいくつかの単純な後処理で再現出来るように思われ、例えば、影の明るさやコントラストを高める場合、ほとんどの画像編集ソフトには、このような後処理を行うツールがあります。この理由から、個人的な見方では、パストレースの結果は、この場合のレンダリング時間を正当化するほど重要ではありません。特に、パストレースを高速化する最適化が行われている場合の星への影響を考えると、 もちろん、前述のように、プロシージャルの星シェーダの代わりにイメージマップを使用するか、プロシージャルの星シェーダの設定を調整する事で修正が可能に思われます。もちろん、最終的には、レンダリング時間に見合うだけのパストレース結果を好むかどうかはあなた次第です。

パストレースを無効にしてGISDを使用した、"Defer All"の結果です。
#image(Rock-Study-Orig2_opt3_FIXED-TESTS_non-PT-1-64_06m46s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1908/Rock-Study-Orig2_opt3_FIXED-TESTS_non-PT-1-64_06m46s-v4.4.18.1.jpg)

*複雑な地形シェーダの影響
雲のクオリティを下げてロバストアダプティブサンプラーを有効にすると、空は実際にかなり速くレンダリングされましたが、地形はなおもかなり低速でした。そこで、私は地形のディスプレイスメントネットワークの一部を無効にするレンダリングを数回行い、レンダリングにかかる時間を確認しました。興味深い事に、いくつかのジオメトリの不連続性を引き起こすいくつかの激しいディスプレースメントがありますが、大規模な地形のディスプレースメント、折り重なりなどは、ここでの地形レンダリング時間の最大の要因ではありません。実際には、"Basic Color Layers & Stones"グループ、特に"FinalStoneComplex_4"が主な原因です。


そのネットワーク内を見ると、多数の『Fake stones shaders』とディスプレイスメントを作成する『Power fractal shader』の非常に複雑な配置であり、そのほとんどすべてが小さなサイズです。このネットワークは、それが作成された状況ではうまく機能しているかもしれませんが、このシーンでは細部の多くが失われているように見えるのに対し、それでもレンダリング時間に大きな影響を与えています。テスト環境では、このグループの石を無効にするだけで、27分間のレンダリングが23分間になりました。絶対的な意味ではそれほど多くないように思えるかもしれませんが、全体のレンダリング時間におよそ15%が追加され、遅いマシン環境では絶対的な時間差が増大します。そして、おそらく3〜4層の偽造石と非変位のパワーフラクタル1〜2層がおそらく結果の大部分を複製すると推測します。
これは、これらの石を無効にした場合の外観です。
#image(DRock-Study-Orig2_opt4_FIXED-TESTS_PT-stones-only-disabled_23m10s-v4.4.18.1.jpg,width=450,height=253,https://img.atwikiimg.com/www65.atwiki.jp/terragen/attach/238/1909/DRock-Study-Orig2_opt4_FIXED-TESTS_PT-stones-only-disabled_23m10s-v4.4.18.1.jpg)

さらに、かなり複雑なシェーダネットワークが他にもいくつかありますが、最終画像への影響は、その複雑さを考えると、期待や予測したものよりも少ないようです。それらはレンダリング時間をそれほど増やしていないようですが、前述の重複したしたディスプレースメントジオメトリに寄与していると思います。これはさまざまな理由で問題になる可能性があります。これらの設定のいくつかは、おそらくドロップイン共有ネットワークまたはそれに基づくものであり、それは学習し、シーンをより簡単かつ迅速に複雑にする(視覚的な結果)ための素晴らしい方法だと思います。しかし、効率とこれらの複雑なネットワークが最終的な作業に実際にどれほど貢献するかとのバランスを取るべきだと思います。

相対的に言えば、これが複雑なネットワークであるとは思わない事を理解していますが、そうで事実かどうかにかかわらず、考慮すべきより重要な事は、シェーダ設定の複雑さが、よりはっきりと結果の複雑さまたは特異性に相当するかどうかです。希に、ほんのわずかな成果を上げるために多くのノードを使用する事で簡単に実現出来る場合がありますが、多くの場合、代償としてレンダリング時間が長くなります。このため、複雑さは本質的に悪くはありませんが、理想的には効率とのバランスを取る必要があります。

従って、これはノードの構築時に注意すべき事です。効率化を図り、可能な限り少ないノードで目標を達成しようとすることは有益です。これにより、レンダリングに費やす時間が短縮されるため、改善のための試行を繰り返す時間を得る事が出来るでしょう！

*より突っ込んだ最適化
&bold(){ハイトフィールドへの変換}
地形はかなり急勾配のように見えますが、顕著に突き出してはいません。それでも、基本的な主要な形状はおそらくハイトフィールドとして作成して保存出来ると思うので、これらのベースライン計算(谷や主要な岩の形状など)を一度だけ実行ます。その後、ディティールに付加的なディスプレースメントを適用しますが、連続するレンダリングで計算時間をいくらか節約する事が可能です。基本的な手法は、地形シェーダネットワークの出力を『Heightfield Generate』ノードの"Shader"入力端子に接続し、『Heightfield Generate』をスケーリングして配置し、地形の視野/影響を及ぼす領域をカバーし、十分なディティール(例えば、2000 x 2000または4000 x 4000)のために十分な"Number of points"を設定します。そして、地形を生成し、『Heightfield Generate』ノードを右クリックして「Save file as ...」を選択し、ハイトフィールド(.ter)として保存します。次に、『Heightfield Load』ノードを追加して、先ほど保存したハイトフィールドを読み込み、最終的に『Heightfield Generate』に供給したした地形生成パーツから分割させた後、シェーディングネットワークの残りの入力端子に接続します。この手法は一見少し難しいように聞こえますが、一度やってみるとても簡単です。常の手法ではありませんが、大規模な地形の計算に時間がかかる事が見えてきた場合は、これが上手くいくかもしれません。これにより、亀裂などのよりきめ細かな地形のディティールに集中させる事が出来るため、すべてのレンダリングが高速になります。ハイトフィールドの制限として、オーバーハングの地形が作成出来ない事や、有限のディティールなどの制限に留意して下さい。．．モノは試しにやってみましょう。

&bold(){第二惑星のディスプレースメント}
第二惑星内には、ディスプレースメントを追加するノードの集まりがあります。しかし、最終的なレンダリングの全体的な効果は、この距離から見る分だと惑星の表面をその集まり分だけ大きく下方に変異する程度と同等です。惑星の実際の"形状"は変化せず、文字通り、惑星の半径が縮んだ一方大気は同じままのように見えます。惑星は画像の中で大きなスペースを占有しませんが、必要以上にレンダリングを遅くしています。単にディスプレースメントのノードを無効(色を提供するノードは無効にしない)にした場合、その見た目の違いはごくわずかです。ただし、基本的に高高度の大気の効果を実行する場合は、『Atmosphere』の高さと"Ceiling/Floor(「Height control」タブ)"を調整する事で達成する事が出来るでしょう。または、分かりやすい簡単な方法で惑星を下方向に変異する方法を考え出す事が出来ます。

*その他の事
他にもいくつかの細かい注意点があります。

シーン内で"Ray Trace Objects"が無効になっている事に気付きました。オブジェクトのディスプレースメントをレンダリングするためのオブジェクトごとのコントロールがある今、(オブジェクトをレイトレーシングせずに、標準のレンダーを使用して)"Ray Trace Objects"をグローバルに無効にする理由は、私の知る限りほとんどありません。大量のオブジェクトをディスプレースメントさせるだけで、それぞれのオブジェクトに対してわざわざ設定する手間をかけたくない場合を除きます。この設定はレンダリングされているオブジェクトがないため、ここでは問題になりませんが(惑星とバックグラウンドの球体は別として、処理が異なります)、常にこの設定を有効にしておくのは良い方針です。これが一般的に使用している設定に基づくレンダーノードである場合、忘れてしまった設定で最適でないレンダリング結果にならないようにするために、これは特に重要です。

また、(私が見る限りでは)ほとんど何も実行しないノード、または切断されたノードがたくさんある事も判りました。例えば、『Fractal warp shader 02_1』にはワープをさせるパラメータが一切接続されておらず、シェーダノードだけが接続されている(2つ目の惑星の中身)などです。これはシーンを開発する時によくある事なので(私にとっても！)、批判するわけではありませんが、トラブルシューティングや最適化が少し遅くなります(将来的のあなたのためにもっと言いたい事がたくさんあります)。そのため、私もこれには苦労していますが、あなたのプロジェクトで必要がなくなった時、不要になったものを片付けるための作業をお勧めします。レンダリング時間を短縮し、シーンで何が行われているかを正確に理解するのに役立ちます。