Yafaray v3.2.0

v3.2.0-ALPHA21, まだ開発者によるテストが続きます。

[Blender-Exporter の仕様変更]

*   Blenderで「Physics」タブを表示
    単純にBlenderUIからPhysicsコントロールを読み込みます。
	ダイナミックペイントのようないくつかの機能はYafaRayで動作しないと思われます。
	しかしまだ我々はYafaRayによってレンダリング可能なブレンダーメッシュ操作である他のすべての機能を隠すべきではありません
*   AA user interface: ピクセル幅が1の時にフィルタタイプが機能しなかったのを修正。

*   Texture	mapping: MirrorX,MirrorY が  Repeat = 1 の時にも反映されるようになった。

*   どのプラットフォームでも、"yafaray-plugins"が統合できるようプラグインフォルダを変更した。

[コアコードの変更]

*   重 要: Path/Photon OneDirectLight - 光をより均一にサンプリングしようとします。

    http://www.yafaray.org/node/803での報告で2つ以上の光源が存在する場合、経路追跡およびフォトンマッピングアルゴリズムにデータの乱れ(アーティファクト)が存在する。
そこで、入力データを変更し(ほぼスレッドごとに1つずつ異なる相関番号を持つ)各サンプルに対してほぼ純粋に相関のある番号付けを使用することに決めました。
これは、ノイズを改善するようであり、使用する光の数によらず同様の結果から均一な光のサンプリングをもたらします。
これは非常に重要な変更です。 現在シーンのレンダリングに少しノイズがかっていると思っていますが、シーン内に複数のライトがある場合は、はるかに正確なライティングがなされています。

いずれにせよ、我々はこれに注意を払う必要があり、細部の調整や、元に戻したり、別の解決策を模索する必要があります。 
現時点でそれをこのままにして、何が起こるか様子を見るつもりです...


*   重 要:


すべてのインテグレータ、SPPM、パスルーレット:非ランダム性反復パターンの修正
http://www.yafaray.org/node/792で説明されているように、私は双方向インテグレータでのランダム性の欠如を発見しました。
それはrandom_t pnrgオブジェクトの不十分なランダム値のシード番号が原因で引き起こされることがわかりました。
 
しかし、問題が表面化しない場合でもSPPMインテグレータにも同じ問題があるため、影響を受けるとも考えられます。
従ってSPPMを含むすべてのインテグレータのpnrgシード処理にランダム性を追加しました。
私はこれがロシアルーレットランダムネスの改善につながることを願っています。

この変更は悪影響をもたらさず、私の意見では有益であるはずですが、それが確実か知るのは困難です。
新しく問題が起きていないか、この点に注意する必要があります。

*   Path Tracing: パラメータmin_bouncesによって設定される、高速レンダリングのためのロシアンルーレット

    * このパラメータが 0 なら ロシアンルーレットが有効になるでしょう。
    * ここにdepth(max bounce)と同じ値を設定した場合、ロシアンルーレットが無効になるでしょう。
    * 0〜 max bounce の間の値に設定すると、ロシアンルーレットは、設定されたバウンス回数の後にのみ適用されるため、暗い領域でもまともなサンプリングが得られ、ノイズの少ない優れた高速化を図ることができます。
   このパラメータが低いほど、速度が速く、ノイズが多くなります。

    Path Tracing integrator: 新たなロシアンルーレットパラメータを追加してパストレースを高速化

*   重要: 大きな変更として、テクスチャの補間がイメージハンドラに変更されました。 現在、すべてのイメージバッファは内部的に線形で、デフォルトで最適化されています。

   http://yafaray.org/node/787で検出された問題を解決するために、私はYafaRayがテクセルの色空間をデコードした後にテクスチャ補間を行っていることを知りました。 これは、標準的な双線形/双三次線と三線形またはEWAミップマップを使用するときに、出力される色に大きな違いを生じさせていました。

	テクスチャを補間する正しい方法は、テクセルが読み込まれるたびにテクセルが補間に使用される前に、色空間をリニア色空間にデコードすることです。 こうして補間はリニア色空間で正確に計算されます。


以降ユーザーは、バンプマップ、ノーマルマップなど、すべてのテクスチャに対して正しい色空間を適用する責任があります。
たとえば、非RGB /ステンシル/バンプ/ノーマルマップなどの場合、テクスチャは通常リニア色空間にあり
、ユーザはテクスチャのプロパティで "linearRGB"を選択しますが、ユーザーが(誤って)デフォルトのsRGBを保持している場合、
YafaRayはsRGB-> LinearRGB変換を(間違って)適用して、不正な値にします。しかし、私はYafaRayの補間が元の色空間への "逆"色変換となる後に色を得るときに、
"float" テクスチャ、バンプマップ、法線マップなどのために "failsafe"を追加しました。
このように、バンプマップ、法線マップなどのユーザーの色空間の選択ミスがあっても、元の色空間に変換されるため、画像に重大な問題は発生しません。
しかし、この場合レンダリングは遅くなり、間違った色空間で補間が行われるために潜在的なデータの乱れが現れることがあります。
最適な結果を得るには、すべてのテクスチャの色空間を正しく選択する必要があります。

*   テクスチャはデフォルトで「最適化」されます。 最適化されたテクスチャがメモリ使用量を大幅に改善し、速度低下を引き起こさないことが明らかになったと思います(RAMアクセスが減るために処理が少し速くなるかもしれません)。
*   アンビエントオクルージョンサンプリングによって生成されていた、未初期化値の修正

*   重要: テクスチャミップマップ/レイ微分の初歩的なサポート。イメージハンドラに「大幅な」変更あり。
     * すべてのイメージハンドラを変更してアクセスを標準化し、より柔軟になりました。
     * 新たにグレイスケール内部バッファ(オプション)を追加。
     * すべての補間処理と GetColor のコードを再編成しました。
     * イメージハンドラにミップマップ機能を追加。
     * レイ微分に基づいたトライリニア-ミップマップ補間を追加。
     * レイ微分に基づいたEWAミップマップ補間を追加。 
     * 大幅に変更されたIBL blur機能。以前あった専用の "IBL blur" 処理の代わりに手動で計算されたミップマップレベルでミップマップを使用します。

    これらの変更点すべては「重要」であり、新しいバグを引き起こす可能性があります...我々は厳しく見守らなければなりません。

すべての補間と GetColor コードを再編成しました。

*   複数レイヤーを持つEXR画像の保存処理を修正。

*   Angular camera: デフォルトのクリッピングが正しくないため、間違ったレンダリングが行われていたのを修正しました。
    http://yafaray.org/node/779 に記載されているように、Angula Cameraレンダリングに問題がありました。 多くの場合、周囲のオブジェクトの代わりに背景が表示されました。
     私は、カメラのデフォルトのクリッピングプレーン計算で、クリッピングが無い時に問題が発生することに気がつきました。 デフォルトでは、far clipping distanceは-1.fに設定されています。これは通常、レイがカメラの後ろに飛ぶことはないため、クリッピングせずにレイを飛ばすことを可能にします。
     しかし、Angular cameraの場合、広角を使用すると実際にはレイがカメラの後ろに入ってしまうことがあります。 そのような場合、レイがカメラ位置の後ろの1.f単位の距離で間違ってクリップされていました。
     そこでAngular cameraのクリッピング後方面までの距離の初期値に、大きな負の値を設定しておきました。この改善によって(カメラの前後の)すべてのレイがクリッピングされずに動作することを願います。

*   イメージテクスチャ補間の修正
     http://www.yafaray.org/node/783 に記載されている問題を解決するための修正が提案されました。
     この修正によってテクスチャの上端と左端に発生していた奇妙な縞模様の問題が解決されます。 
   
  また、この変更で次の2つの場合において、テクスチャのエッジ補間を想定した特別なコードが実装されています。:
    * テクスチャが単独(クリップ)であり、引き伸ばされていたり市松模様になっている。この場合エッジ自身に対して補間されます。
    * テクスチャ内容が繰り返されている。この場合、エッジの補間方法はMirrorX/MirrorYパラメータによって異なります。 これらのパラメータに応じて、反対側のエッジ(通常)または同一のエッジ(ミラー化された場合)に対してエッジ補間されます。

*   Texture mapping:  Repeat = 1 のときでも、MirrorX と MirrorY が有効になりました。

*   複数のプラットフォームとシナリオのビルド手順の追加

*   QtのサポートはYafaRay v3のために再導入され、アップデートされました。しかしまだ初歩的な段階であり、多くの機能がQtインターフェースで利用できません。

*   CMake/Swig: Rubyバインディングを有効にした際にBlenderがクラッシュするのを避けるため、Rubyインターフェースを変更。 

*   CMake: ビルドシステムの「重要な」変更/更新があります。Gitによるバージョン管理の統合 パスの標準化。 スタンドアロンビルドの再導入、およびライブラリのランタイム検索の改善
    いくつかの変更点がCMakeビルドシステムに導入されました。:
    * バージョン管理をGitと統合して、現時点のGitタグに基づいたビルドを自動バージョン管理する。
    * 異なるOSのインストールパスの標準化。 純粋なコアリリースとしてbin/libシステムフォルダへ、あるいはBlenderアドオンとしてインストールされていても、今回よりプラグインは常に "yafaray-plugins"というフォルダにインストールされます。
    * Blenderのアドオンとしてコアがビルドされるたびに、毎回Blender-Exporter gitの削除+ダウンロードを自動的に行わないようにしました。今までは再ビルドとテストが非常に遅く面倒で、またCMakeビルドプロセスで "rm -rf"を使用することは、危険で可搬性のないプロセスでした。今回から開発者はgitを使って手動でBlender-Exporterをダウンロード*しなければいけません*。そしてUserConfig.txt ファイル内に、Blender-Exporter までのパスを設定*しておかなければいけません*。初めての方には少々手間ですが、その後のリビルドやテストをすることを思えばずっと便利だと思います。

    * デフォルトのライブラリと別のライブラリを探索するためのCMakeオプションを追加しました。
    * (たぶん時代遅れで古いため?)うまく動作しない findOpenCV CMakeモジュールを削除。そのモジュールがなくても一般的にOpenCVファイルを見つけるのは簡単に思えます。 しかしいくつかの場合で、OpenCVライブラリへのパスを手動で設定する必要が出てくるかもしれません。
    * MacOSX環境の利便性のために、UserConfig.txtファイル内にフレームワークを選択できるようオプションを追加しました。
    *yafaray-xml: プラグインパスの自動検出を向上。しかし、まだいくつかの場合で"-pp" オプションが必要になるかもしれません。

*   いくつかの状況で、余分なレンダーパスが多く生成されるバグを修正しました。

*   SPPM(確率論的プログレッシブフォトンマッピング) におおいてフォトン数がほぼ4300万個に達した時に 突然輝度が変化するのを修正。
    http://www.yafaray.org/node/772で報告されているように、SPPMにおいて約4,300万個のフォトンが蓄積されると、シーンの明るさが非常に急激に変化していました。



<arolf_infoseek_jp> Tsukubado