Yamyam: 1版をインポートしました

2018-06-28T21:09:46Z

1版をインポートしました

wiki>Blendmild: translated

2014-08-04T15:27:39Z

translated

新規ページ

{{Page/Header||}}

{{review|copy=X}}

=Optimizing Render Performance=
（レンダリング効率の最適化）

「待つ身は長い」は古いことわざですが、レンダリングに時間がかかりすぎたり、さらには途中でクラッシュしたりするのがなぜなのか、疑問に思ったことがあるかもしれません。レンダリングの高速化のために、あるいは複雑なレンダリングをやり遂げるために、できることはたくさんあります。それに「かしこいレンダリング」を行えば、平凡な PC で非常に複雑なシーンをレンダリングできます。以下はレンダリングの高速化のために、果てはシーン描画中のクラッシュ回避のために、すべきことすべきでないことの「トップ10」リストです。選択肢の中には描画品質を下げるものもありますが、試しレンダリング用途であれば気にならないでしょう。

「Malloc returns nil」というメッセージが出たら、メモリアロケータが Blender 用に物理メモリを追加取得しようとして手ぶらで帰ってきたということです。つまり、シーンのレンダリングに使うメモリが足りず、Blender が処理を続行できません。レンダリングを行うには、このページにあるタスクをひとつ以上行う必要があるでしょう。
== Hardware Improvements ==
（ハードウェアの更新）

# PC（マザーボードや OS）の上限まで RAM を増やす。まもなく Blender は 8GG（ギガギガ）までの物理メモリ（64ビットアドレス空間）を使えるようになりますが、大半の PC は 4G の RAM だけを扱えます
# CPU をマルチコア/マルチプロセッサに更新
# OpenGL ビデオドライバの更新
# もっと速いメモリバスを入手
# マザーボードの上限まで高速なメモリを入手。667MHz のメモリは 800MHz のものより 30% 低速です
# 家にある使える PC をすべて使って render farm を始める準備をする。もしくは BURP のような render farm を使います

== Operating System Configuration ==
（OS の設定）

# OS で Blender の処理優先度を上げる
# OS がメモリスワッピングに使用するスワップファイルの容量を増やす。仮想メモリのページファイルサイズとも呼ばれます。物理メモリサイズまで増やします
# 64ビット OS に更新（いまお使いでなければ）
# ウィルス検知、BOINC、Real、さらには Quicktime などの「活動中でない」もの（更新を調べるのにランダムで起動するため）なども含めた、バックグラウンド処理を終了させるか停止させます。バックグラウンド処理は RAM も使います
# ネットワーク接続を無効にして、ランダムな ping や更新用データの通信を止めます
# インターネットラジオを聴くのをやめてウェブブラウザを閉じる。特にマルチメディアサイト（音声/動画/ゲーム）は閉じます
# Word などの、実行中の他のアプリケーションをすべて閉じる
# すべての常駐プログラム（システムトレイにアイコンがあるもの）とウィジェット、バックグラウンド処理、ウィルス検知プログラムを終了させる

== Blender Settings==
（Blender の設定）

# ユーザー設定の、システム＆OpenGLタブで最大メモリキャッシュ（Memory Cache Limit）を増やす
# [http://www.graphicall.org 最適化された Blender ビルド] に更新する。SSE2 をサポートする先進的なチップをお使いなら特に、最適化されたビルドを使います。レンダリング時間が ''30% 高速化'' します
# 平行投影（Orthographic）カメラに切り替え、シーンにある「部品」を別々の画像としてレンダリングし、GIMP で貼り合わせる。現実のカメラでパノラマ写真を作る古い方法として、１枚目を撮ったら右に向きを変えて別の写真を撮り、さらにもう一枚を撮るというやり方で、非常に幅広の（浜辺の日没の）風景を３枚ほどの写真に撮影する方法があります。写真を現像したら重ね合わせて、幅広の横長画像を作ります。Blender でも同じことをしましょう。１場面をレンダリングしてファイルに出力したら、シーンの別の場所にカメラを合わせてその場面をレンダリングします。撮影ごとの領域が狭くなるので、カメラの捉えるポリゴン/面の数も少なくなります。あとで貼り合わせられるように、重ね合わせの撮影に使うカメラをいつ動かすか、間違えないようにしてください。GIMP を使いたくない場合は、Blender のコンポジティングノードで Translate（移動）ノードを使って組み合わせることができます
# レンダリングウィンドウを（Blender 内部ウィンドウにレンダリングするなら Blender も）最小化。毎フレーム劇的に高速になるという ATI ユーザーの報告があり、これはフレームが増えるほど意味があります
# 「Big Render」スクリプトを使って画像を細切れにレンダリングし、それを貼り合わせる
# カスタマイズされたビルドを作る。たとえば、convertblender.c にある check_non_flat_quads への呼び出しをコメントアウトします。20-40% の顕著な違いが出ることがあります

== Scene and Specific Objects ==
（シーンと特定のオブジェクト）

# 光源をなくす。または、レンダリングしないレイヤーに移動するかレイヤーに限定します
# 光源の影をいくつかオフにして、１つか２つのメインの太陽光源だけが影を作るようにする。少数の「影のみ」光源は、全光源が影を持つ場合よりも高速にレンダリングできます
# ray-traced Shadows ではなく buffer Shadows を使う
# 動かない面に、Full Render ベイクを使って影を焼き付け。できたテクスチャを同じメッシュに使って、このマテリアルに対する影を無効にします
# メッシュを単純化する（ポリゴンを減らす）。カメラに入る頂点が多いほど、レンダリングに時間がかかります
# 重複を取り除く（Remove Doubles）。または Decimator メッシュ編集機能を使う
# Subsurf や Multires モディファイアを外す
# メッシュの裏側を削除（見えないジオメトリを取り除く）
# 一度に少しのオブジェクトだけをレンダリングする。常に変更されることのない、常に背景にあるオブジェクトや舞台装置をプロジェクト開始時にレンダリングします
# 建物を別のレイヤーに置き、レンダーレイヤーを通してレンダリングしないようにする。あとで合成して戻します
# 上の二つのアイデアを達成しやすくするためカメラを固定する
# 範囲光源（Area lights）の使用を避ける
# マテリアルの陰影処理を外す
# AO とテクスチャをベイクして、マテリアルから陰影処理を外す
# スポットライトのクリップ距離を減らす
# カメラのクリップ距離を減らす
# world AO を切る
# Material SSS を切る
# 使用する画像テクスチャを小さくする。256x256 の画像は 2k 画像が使うメモリの 1% しか使いませんが、最終レンダリングの画質が劣化しないことはよくあります
# Subsurf を減らす。レベルを上げるたびに面数は前のレベルの４倍になります
# Multires を減らす
# 建物などの背景オブジェクトの matte render を行ない、シーン内にはオブジェクトそのものの代わりに、その画像を載せたビルボード（billboard）を置きます。これで頂点や面の数が減ります
# オブジェクトからリンクしたインスタンスがたくさんあるときは、インスタンス化されている DupliFace を使います。100あっても、Blender が保持するジオメトリは１つだけです（インスタンスそのものが少しメモリを使います）

== Render Settings ==
（レンダリングの設定）

* [[Doc:JA/2.6/Manual/Render/Output|Output（出力）パネル]]
*# {{Literal|Edge}} レンダリングの無効化
*# {{Literal|Save Buffers（バッファ保存）}}
*# ポップアップではなく [[Doc:JA/2.6/Reference/Windows/UV-Image|Image Editor]] ウィンドウにレンダリングします。[[Doc:JA/2.6/Manual/Render/Display|Render Window]]
*# マルチコア CPU での複数 {{Literal|スレッド}} の使用（複数の {{Literal|部品}} を使います）
* [[Doc:JA/2.6/Manual/Render/Post Process/Layers|Render Layers（レンダーレイヤー）パネル]] [[Doc:2.6/Manual/Render/Post Process/Layers|（eng）]]
*# 目的のレイヤーだけをレンダリング
*# すべての光源を単純なスポット１つにしてレンダリング（{{Literal|Light:}} 欄にスポットの名前を入力）
*# １つのマテリアルで上書きしてレンダリング（Mat: 欄に名前を入力）
*# {{Literal|Z}} などの必要でないレンダーパスの無効化。もしくは {{Literal|Diffuse}} などの目的のパスだけをレンダリング
* [[Doc:JA/2.6/Manual/Render/Options|Render（レンダー）パネル]]
*# {{Literal|Shadows}} を切る
*# {{Literal|Environment Mapping}} を切る
*# {{Literal|Panoramic Rendering}} を切る
*# {{Literal|Raytracing}} を切る
*# SSS Subsurface Scattering を切る
*# oversampling/aliasing {{Literal|OSA}} を切るか下げる
*# {{Literal|Motion Blur}} を切るか下げる
*# 部分別にレンダリングする。これで非力な PC でも巨大な画像をレンダリングできます。マルチコア PC では同様に各部分にスレッドを割り当てます
*# octree resolution を増やす
*# 最終的な解像度の縮小サイズでレンダリング（25%など）
*# {{Literal|Fields}} レンダリングを切る
*# {{Literal|Border}} レンダリングで全体画像の一部をレンダリング
* [[Doc:JA/2.6/Manual/Render/Animations|Anim（アニメーション）パネル]]
*# アニメーションのフレーム数を減らす（そして、同じ長さのアニメーションで低いフレームレートを使う）。たとえば３秒のアニメーションで、75枚のフレームを毎秒25フレームでレンダリングする代わりに、30枚のフレームを毎秒10フレームでレンダリングします
* [[Doc:JA/2.6/Manual/Render/Bake|Bake（ベイク）パネル]]
*# Full Render をベイクする。マテリアルをもとにオブジェクトに着色する UVテクスチャを作って、陰影なしでマテリアルの代わりに使います
*# Ambient Occlusion だけをベイク
*# オブジェクト用のテクスチャをベイク
*# Normals（法線）や Displacement（ディスプレイスメント）のベイクはレンダリング時間を高速化せず、別の目的に使われます
* [[Doc:JA/2.6/Manual/Render/Output|Format（ファイル形式）パネル]]
*# 低解像度でレンダリング。絵が小さいほどレンダリング時間は少なくなります
*# 高速な CODEC か CODEC 設定を選ぶ
*# 白黒でレンダリング（{{Literal|BW}} ボタン）
*# FFMPEG を使っていれば、{{Literal|Multiplex audio}} を有効にしない
*# FFMPEG を使っていれば、{{Literal|Autosplit Output}}（出力を自動分割する）（{{Literal|Video}} パネルボタン）
*# 色だけが必要なら RGB だけをレンダリング。A チャネル（{{Literal|RGBA}} ボタン）はメモリ使用量を増やしますが、動画ファイルの保存時には使われません

== Multi-Pass Compositing ==
（マルチパスのコンポジティング）

レンダリングの長期化問題に取り組むのに使えるもう一つの戦術は、「ポストプロダクション」の章で解説されている ''コンポジティング'' を積極的に利用できるように、作業工程を根底から組み立てることです。この方法では、各場面を、別々にレンダリングできる構成要素にまで分解し、別々にレンダリングされた要素を統合して、完成した動画を作り上げます。以下はその例です:
* カメラが動かないのであれば、背景も動きません。必要なのはひとつのフレームだけです（同じことはフレーム内にある動かないものすべてに当てはまります）。こうした要素は ''一度'' 生成されれば、必要とされる数のフレームをまたいで、必要な回数だけ再利用できます
* 影とハイライトは、照明の当てられたオブジェクトや影で覆われたオブジェクトと別々に取得できます。intensity（強度）、色、効き目の強さのようなものはあとで、再レンダリングせずに調整できます
* 影を作らない光源を使うことから始めてください（影の計算は大きく時間を削ぎます）。次に「影のみ」の光源を使って（影を作りますが光を差しません）、実際に必要に思えた箇所 ''だけ'' 影を作ります（ほとんどの場合実際に問題になるのはシーン内に存在する影のいくつかだけで、残りは単に気づかれません）
* オブジェクトを別々に扱うことで、扱いにくいライティング条件を避けることができ、別々にレンダリングされたクリップを統合して、結果を微調整できます。

これは非常に一般的な考え方です。たとえば現代的な楽曲収録では常に「マルチトラック」方式を使います。曲のパートをそれぞれ別に隔離した状態で録音し、その後「ミックス」します。「最終ミックス」がさらなる処理工程である''マスタリング''を経て、完成した製品が生まれます（実際に、現代的な音声処理ソフトウェアは Blender のノードベースのコンポジターと直接比較できるものです）。

この方法には圧倒的な長所があります:
* 選ぶことができます。何かが「少しおかしい」とき、必ずしも一からやり直す必要はありません。
* 実際、締め切りを破るのは「ある場面の'ちょっとしたこと'が間違っている」ために、普通は完成しているはずのものを（そっくりそのまま）''再''レンダリングすることです。これを避けるためにコンポジティングは役立ちます。というのは（理想的には）間違いの見つかった特定箇所だけを再実行しなければならないからです（もしくは、間違った部分を「不要データマスク（garbage matte）」を使って除外して、直したものをその場所に差し込むことがおそらくできます。誰も気づかないでしょう！）。
* 「わかったよ、こいつは''ほぼ'' 僕が欲しかったものだ。でも今度はこれを ''足して'' あれを''削り'' たいかな」となるかもしれません。コンポジティングベースのやり方でちょうどそういったことができます。さらには ''非破壊で'' できます。言い換えれば、「追加分」（あるいは「マスク」）を別チャネルの情報として生成することで、全体の「ミックス」内でその影響を微調整できるようになり、あるいは気分が変わってそれを完全に取り除くことさえも、元に戻せない変更をすることなく行えるということです。
* 概ね、この段階ではそれまでに「R、G、B、アルファ ''（透明度）'' と Z深度情報でできたラスタ画像」を操作することで ''２'' 次元的に働くので、一貫して高速です。
* 分離された各レンダリングタスクは単純化されているため、コンピュータはずっと少ないリソースを使って実行できます。
* タスクは複数のコンピュータで分担することができます。処分できずに押入れに居座っているニ世代前のマシンのような、非力な PC でさえも参加できます。
* 「結局のところ、シーンが ''説得力を持つ'' ために、''物理的に正確'' である必要はありません」。コンポジティングベースのやり方はこれを最大限に利用します。本当に目立った違いを生むような、シーンのはっきりした特徴（aspect）に焦点を絞ることができます。重要性の低い特徴（aspect）を（「技術的には正しい」が）意識して選び除外することで、少なからぬ時間を節約することができますし、おそらくそれは気づかれないでしょう。

もちろん、このやり方はそれ自身の代償なしには存在しません。所持しているマテリアルとその場所、更新の必要性、それにきっちり同じものを作る方法、といったことを正確に追い続けるための、扱いやすいアセット管理システムを考案しなければなりません。綿密に編成されたファイルコレクションにあるオブジェクト、ノード、マテリアル、テクスチャ、シーンを参照するためには、Blender の「ライブラリリンク」機能を理解して使う必要があります。完成した撮影の構成がどうあるべきか、またタスクの内訳はどうあるべきか、''あらかじめ'' 明確な見解を持たねばなりません。几帳面に記録を行い、記録を管理しなければなりません。しかししっかりとした製品を完成させるために、これはときに、''唯一'' ではなくとも最良の方法になります。

← 古い版	2018年6月28日 (木) 21:09時点における版
(相違点なし)

Doc:JA/2.6/Manual/Render/Performance - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Blendmild: translated

Yamyam: 1版をインポートしました