法線をベクトルタイプから浮動小数点タイプに圧縮し、それをPosition Textureのアルファチャンネルに格納します。 これは不可逆圧縮なので中品質な法線になります。 (接線空間の)サーフェス法線マップをリアルタイムアセットに適用する予定がないのであれば、Rotation Textureのサンプリングコストを回避することができるので、この方がメモリ効率が高い代替手段になります。 しかし、サーフェス法線マップを適用したいのであれば、これを無効にして代わりにRotation Textureを使用してください。 これを有効にすると、Position Textureのアルファチャンネルを介してカスタムアトリビュートをエクスポートすることもできなくなります。

どのリジッドボディピースの頂点も各ピースのピボットを基準にしてトランスフォームされます。 そのため、そのピボットエンコーディングの精度がアニメーション全体におけるピースの移動と回転の精度を決めます。

High: 頂点シェーダがパフォーマンスのボトルネックになっている場合、これを選択してください。これは2つの16ビットUVチャンネルを使用して、エンコードされていないピボットを格納します。全体的に最も負荷の軽いオプションです。

Very High: 推奨。2つの16ビットUVチャンネルを使用して、エンコードされたピボットを格納します。2つに分割されたエンコーディングフォーマットを配置し、その2つのフォーマットのうち各ピースに適した方のフォーマットを動的に取得して、その後者のメモリ使用量の半分だけで“最大”の精度に非常に近い精度を生成するので、より多くの頂点シェーダ命令が必要になります。

Maximum: 可能な限り最高の精度が絶対に必要な場合にのみこれを選択してください。これは2つの32ビットUVチャンネルを使用して、エンコードされていないピボットを格納します。Unreal Engineでは、Mesh Editorの Use Full Precision UVs を有効にしてください。無効にしなかった場合、実際の精度が“High”より若干低いです。Rigid-Body Dynamics(Rigid)モードではエクスポートするメッシュ上に4から6個のUVチャンネルが必要なので、 Use Full Precision UVs を有効にするとすべてのメモリ使用量が2倍になります。

入力ジオメトリに“w”角速度アトリビュートを用意できるのであれば、“Accurate Multi-RPF Slerp with Angular Velocity”を選択してください。 入力ジオメトリがRBDシミュレーションから取得されたものであれば、角速度を直接利用することができます。 単にそのアトリビュートがシミュレーション出力アトリビュートに含まれているかどうか、それがポイントに転送されているかどうかを確認すれば良いだけです。

Accurate Multi-RPF Slerp with Angular Velocity: これは、角速度で補助される球面線形補間(slerp:spherical linear interpolation)アルゴリズムを使用して、高速スピンするピースの回転をかなり正確に補間します。1整数フレームあたり360度よりもはるかに高速にスピン(1フレームあたり何回も回転)するピースを補間することが可能です。さらに、ピースが前フレームとまったく同じ向きに回転するような問題を起こしやすい状況を制御することもできるので、リアルタイム再生で時間を自由に遅らせることもできます。

Basic Short-Path Slerp without Angular Velocity: これは、入力に角速度を必要としない標準的な短経路の球面線形補間(slerp:spherical linear interpolation)アルゴリズムを使用します。このアルゴリズムによる正確な回転補間は、1整数フレームあたり180度未満でスピンするピースに限定されます。ピースがそれよりも高速にスピンする場合、その回転補間は正しくなくなります。

これは、Color TextureをエクスポートしてTexture Formatを“HDR”に設定する必要があります。 これは、加速度を再計算して、Color TextureのRGBチャンネルを介してその加速度をエクスポートします。 加速度を使用すれば、このシェーダは、フレーム間でただ位置を繋げて直線経路を構築するのではなく、その加速度を考慮したより現実的な方法でフレーム間で弧を描くような軌跡を再構築することができます。

ピースによるアニメーション内のどこかで到達した最大RPF(Revolutions Per Frame:1フレームあたりの回転量)が非常に大きすぎると、それが浮動小数点精度の制限が原因ですべてのピースの回転補間の精度に影響を与えてしまう可能性があります。 このパラメータを妥当な大きさに設定することで、極端に高速スピンする異常なピースがそのような問題を引き起こさないようにすることができます。

ピースが前フレームとまったく同じ向きに回転するような問題を起こしやすい状況を解決するのを補助します。 slerp関数は正確に360度の倍数の回転を定義しません。 それ故に、その解は、ピースが次のフレームの向きとあまり回転が変わらないような問題を引き起こします。 これは、偶数フレームに対して、このパラメータ値の50%～150%の範囲のランダムな角度で時間的に早く回転させ、 奇数フレームに対して、このパラメータ値の-50%から-150%の範囲のランダムな角度で時間的に遅く回転させます。 この値を低すぎないように設定してください。そうしないと、リアルタイムシェーダは数値誤差の影響を受けてしまいます。

問題を起こしやすいピースの回転を回避するために加えるランダムな角度の生成に寄与する(個々のピースに対してではない)グローバルランダムシード(Slerp Edge Case Offsetの説明を参照してください)。 このパラメータを変更する必要性が出てくるのはほとんどありません。 ノードがそうするようにエラーメッセージを出した場合にのみ変更します。

Dynamic Remeshing(Fluid)モードでは、テクスチャメモリの消費量を減らせるようにするために、出力ファイルを2つの別々のパスでレンダリングする必要があります。 このノードの設定を編集する際は、ここを“First Pass”のままにしてから Render All を押してください。 1つ目のパスが完了したら、これを“Second Pass”に変更してから再度 Render All を押してください(これら2つのパス間で設定を変更できないように、他のほとんどパラメータはセカンドパス中にロックされます)。 Preview Texture Size が有効になっている場合、このパラメータは、プレビューするパスのテクスチャサイズを決めます。

First Pass: これは、Geometry、Lookup Table Texture、そしてオプションでReal-Time Data JSONファイル/Unity Materialファイルをレンダーします。

Second Pass: これは、Lookup Table Textureよりもサイズが非常に小さいアニメーションテクスチャ(例えば、Position Texture、Rotation Texture、Color Textureなど)をレンダーします。

ポイントを結合したくないのであれば、これを無効にしてください。

結合の影響を受けるポイントグループ。ポイント同士が Fuse Distance で設定された距離閾値以内に収まっていれば、それらのポイントが結合されます。 “!group_name”や“* ^group_a_name ^group_b_name”の構文を使用することで特定のグループを除外することもできます。 このパラメータを空っぽにすると、すべてのポイントが影響を受けます。

入力ジオメトリ内のポイントをこの距離内にある他のポイントと結合します。 これは、リソースの無駄または場合によって問題を引き起こす微小な三角形を削除するのに役立ちます。

法線をベクトルタイプから浮動小数点タイプに圧縮し、それをPosition Textureのアルファチャンネルに格納します。 これは不可逆圧縮なので中品質な法線になります。 従来の(接線空間の)サーフェス法線マップをリアルタイムアセットに適用する予定がないのであれば、Rotation Textureのサンプリングコストを回避することができるので、この方がメモリ効率が高い代替手段になります。 しかし、従来の法線マップを適用したいのであれば、これを無効にして代わりにRotation Textureを使用してください。 これを有効にすると、Position Textureのアルファチャンネルを介してカスタムアトリビュートをエクスポートすることもできなくなります。

Position TextureのアルファチャンネルとColor Textureのアルファチャンネルを介して、アニメーションするUVアトリビュートをエクスポートします。 Dynamic Remeshing(Fluid)モードはUVマップに対応することができますが、トポロジーが動的に変化するので、その入力ジオメトリをフレーム毎にUV展開する必要があります。あなた自身で入力ジオメトリをUV展開するか(推奨)、または、 Input タブのAttribute Auto Generationで指定されたUV Generationのメソッドにおまかせすることもできます。

Color Textureの赤チャンネルと緑チャンネルを介して、アニメーションするUVアトリビュートをエクスポートします。 Dynamic Remeshing(Fluid)モードはUVマップに対応することができますが、トポロジーが動的に変化するので、その入力ジオメトリをフレーム毎にUV展開する必要があります。あなた自身で入力ジオメトリをUV展開するか(推奨)、または、 Input タブのAttribute Auto Generationで指定されたUV Generationのメソッドにおまかせすることもできます。

リアルタイムでパーティクルアトリビュートを補間できるようにするために、出力されるテクスチャ上のデータの配置方法を変更します。 これには、入力ジオメトリが“id”Pointアトリビュートを持っている必要があります。

パーティクルカードジオメトリの形状を設定します。形状が異なるとパフォーマンスの負荷も若干異なります。しかし、どの形状もUV空間内で同じ中心点を共有します。

UV空間とリアルタイムビュー空間で正方形パーティクルカードを向けます。

UV空間とリアルタイムビュー空間で三角形にパーティクルカードを向けます。

UV空間とリアルタイムビュー空間で六角形パーティクルカードを向けます。

デフォルトのシェイプオプションを独自の仕様に置換します。 カスタムシェイプジオメトリは必ずZX平面上で平坦にしてください。 複数のシェイプバリアントをまとめて結合して、その結合したジオメトリのパスをこのパラメータに設定することができます。 Multiple Shape Variants with Shape ID Attributeの説明を参照してください。

カスタムシェイプには、塗り潰されたポリゴン、または、空洞の閉じたカーブで定義された単純なアウトラインを指定することができます。 指定された空洞のアウトラインは自動的に塗り潰されます。 パフォーマンスを上げたいのであれば、Fuse SOPを使用して入力カスタムシェイプの定義に使用されているポイント数を減らすことを考慮してください。

(Custom ZX Shapesは1個のジオメトリパスしか受け取らないので)複数のシェイプバリアントをまとめて結合する時、各シェイプに固有のシェイプID値を割り当てていれば、それらのシェイプバリアントを個々に特定することができます。

異なるシェイプバリアントを区別するための整数Point/Primitiveアトリビュート。

シェイプバリアントの寄与度を決めるための浮動小数点Point/Primitiveアトリビュート。 パーティクルが各バリアントのどれかを採用する確率は、このバリアントのウェイトをすべてのバリアントの総ウェイトで割ったものになります。

複数のバリアント間の相対スケール差を維持します。 異なるシェイプが同じ境界矩形サイズになるようにスケールをかけたいのであれば、これを無効にしてください(幅と高さの比率は固定されます)。

パーティクルカードの法線があなたのリアルタイムエンジンで間違っている場合にのみ、これを有効にしてください。 法線が間違っていた場合、パーティクルカードが不可視のようになりますが、そのオブジェクトを選択するとアウトラインが表示されます。 ただし、これが起こる可能性はほとんどありません。

これを設定すると、入力ジオメトリを整数フレームにキャッシュ化してそれをディスクから読み込むことができます。 入力ジオメトリのキャッシュ化は、このノードのレンダリング時間を短くすることができるので(特に、入力ジオメトリが重いシミュレーションまたは再クックが遅いノードに依存している場合)、推奨されるワークフローです。

メモリ消費量を少なくしたいのであれば、通常ではLookup Table Formatには“Non-HDR”と“.png” / “.tga”を選択するだけで十分です。 Unreal Engineにおいて、Dynamic Remeshing(Fluid)モードのアニメーションに誤作動が発生した場合、まず最初にすべき事はUnreal Editorを再起動することです(これは、ファイルを新しく取り込んだ後に発生する誤作動の修復方法として知られています)。 誤作動が続くようでしたら、Mesh Editorの Use Full Precision UVs を有効にすることを検討してください。 セカンドパスのテクスチャサイズが巨大で、他のすべての解決方法でも誤作動を修正できなかった場合にのみ、これを“HDR”と“.exr” / “.tiff”に変更してください。

“HDR”はエクスポートするすべてのデータの精度が良くなるので、パフォーマンス負荷に余裕があるのであれば“HDR”を選択してください。 拡張子がEXRとTIFFのファイルのみがHDRに対応し、それ以外のすべての拡張子のファイルはHDRに対応することができません。 アニメーションが広大な領域にまたがる場合、そのデータ精度が上限に達して、非HDRフォーマットは目立った不具合を引き起こす可能性があります。 この場合、HDRフォーマットに切り替えるか、または、アニメーションをいくつかもっと小さなローカル部分に分割することを検討してください。 リアルタイムエンジンでは、テクスチャ圧縮の設定をこの設定に合わせてください(例外に関しては、Pad Texture Size to Powers of Twoの説明を参照してください)。

ターゲットのエンジンが16/32ビットHDRテクスチャに対応していない場合でも、2枚の8ビットテクスチャを使用して精度を上げることができます。 これを有効にすると、必ずその2枚のテクスチャを使用しなければなりません。 HDR Position Textureを使用すると、このノードは自動的にこのオプションにアクセスできなくなるものの、 Advanced タブでこの制限を上書きすることができます。

これを有効にすると、入力ジオメトリ上の“Cd2”ベクトルPointアトリビュートと“Alpha2”浮動小数点Pointアトリビュートがエクスポートされます。 これは2番目のセットのアニメーションカラーをエクスポートしたい時に役立ちます。 他にも、Color Textureに非カラーデータが使用されている場合にこれを使用することで実際のカラーをエクスポートすることができます。 Color Textureは多目的テクスチャとして設計されているのに対して、Spare Color Textureはどちらかというと純粋なカラーテクスチャ用として存在しています。 とはいえ、もちろん非カラーデータを“Cd2”と“Alpha2”に書き込んでも構いません。

頂点カラーをエクスポートするには、ポイント上ではなくて頂点上に“Cd_v”アトリビュートと“Alpha_v”アトリビュートを作成してください。 これは、アニメーションするポイント/ピース/パーティクルのカラー(テクスチャを介してエクスポートされ頂点カラーを変更しません)と明確に区別するためであり、頂点カラーは静的メッシュを介してエクスポートされます。 頂点カラーは、マスクなど他の用途で使用します。 Dynamic Remeshing(Fluid)モードでは、トポロジーが一致しないので静的頂点カラーの概念がありません。 Particle Sprites(Sprite)モードでは、静的頂点カラーはCustom ZX Shapesのジオメトリ上に存在する場合にのみエクスポートされます。

これを有効にすることを推奨します。 リアルタイムシェーダがデバッグモードでない時、その平面はレンダリングされず、ほぼ負荷が発生しません。 これを無効にすると、リアルタイムシェーダのデバッグが困難になります(現在のところ、この機能はUnreal Engineでのみ対応しています)。

Vertex Animation Textures ROP 3.0以前のバージョンでは、リアルタイムシェーダ内にパラメータ値のリストを設定する必要がありました。 今では、これらのデータは静的メッシュの境界に埋め込まれ、ランタイム時に自動的に引き出されます。 これを有効にすると、エクスポートされる静的メッシュ内に単純な平面が格納され、シェーダがデバッグモードの時にその埋め込まれたデータを表示することができます。

Position Textureのアルファチャンネルを介してエクスポートしたいカスタム浮動小数点アトリビュート。 このアトリビュートには、マイナス以外の値を入れることができ、非HDRテクスチャモードを使用した場合でも1.0を超えた値を含めることができます。 ただし、これに対応できるようにするために、マイナス値が禁止されています。

Color TextureのRGBチャンネルを介してエクスポートしたいカスタムベクトルアトリビュート。 このアトリビュートは、トランスフォームや変換や正規化の影響を受けません。 このアトリビュート値の範囲が0-1範囲外の場合は、Texture Formatを“HDR”に設定してください。 非HDRテクスチャを使用する必要があるのであれば、事前に入力ジオメトリ内のアトリビュートを正規化しておき、リアルタイムシェーダ内で手動でその正規化した値を戻すことになります。

Color Textureのアルファチャンネルを介してエクスポートしたいカスタム浮動小数点アトリビュート。 このアトリビュートは、トランスフォームや変換や正規化の影響を受けません。 このアトリビュート値の範囲が0-1範囲外の場合は、Texture Formatを“HDR”に設定してください。 非HDRテクスチャを使用する必要があるのであれば、事前に入力ジオメトリ内のアトリビュートを正規化しておき、リアルタイムシェーダ内で手動でその正規化した値を戻すことになります。

Lookup Table Textureのターゲット幅。 Dynamic Remeshing(Fluid)モードでは、Lookup Table Textureがアニメーションテクスチャの何倍もの大きさになる傾向があるので、 Target Texture Width をこの値の50%とか25%程度にすると良いでしょう。

Dynamic Remeshing(Fluid)モードでは、フレームあたりの三角形(非三角形の入力ポリゴンは、このノードによって三角形化されます)の最大数は、この値に660を乗算した数になります。この660は、アニメーションUVの列の数の上限である1980を3で割った数です。

Preview Texture Size を有効にすることで、この値を決めるのに役立ちます。あまりにも広すぎて短すぎる、または、狭すぎて長すぎるようなテクスチャを作成しないように試みてください。 Unreal Engineでは、テクスチャの幅または高さのどちらかが4096を超えている場合にアニメーションが誤作動するなら、Mesh Editorで Use Full Precision UVs を有効にすることを検討してください。

出力されるテクスチャのターゲット幅。 フレームあたりのデータポイント数がこの幅より少ない場合、出力されるテクスチャはデータポイント数をこの幅で使用します。

フレームあたりのポイントの最大数は、この値に1980を乗算した数になります。この1980は、アニメーションUVの列の数の上限です。

Preview Texture Size を有効にすることで、この値を決めるのに役立ちます。あまりにも広すぎて短すぎる、または、狭すぎて長すぎるようなテクスチャを作成しないように試みてください。 Unreal Engineでは、テクスチャの幅または高さのどちらかが4096を超えている場合にアニメーションが誤作動するなら、Mesh Editorで Use Full Precision UVs を有効にすることを検討してください。

これを有効にすると、出力されるテクスチャサイズをインタラクティブにプレビューすることができます。 これを有効にして一部の上流パラメータが更新される度に、このノードはエクスポートされるフレーム範囲のフレーム毎に入力ジオメトリを再チェックする必要があるので、幾分遅くなります。 しかし、これが有効になっていれば、Target Texture Widthを更新するとフィードバックが即座に得られます。 Dynamic Remeshing(Fluid)モードでは、これら2つのパスはそれぞれ異なるテクスチャサイズを持つので、表示されるプレビューサイズは Render Pass に依存します。

通常では、アニメーションテクスチャはデータテクスチャとしてストリーム化しないはずなので、サイズを2のべき乗に詰める必要はありません。 しかし、ターゲットエンジンまたはハードウェアが2のべき乗のサイズのテクスチャしか受け取らないのであれば、これを有効にしてください。 Unreal Engineでは、アルファチャンネルにデータを含んだ2のべき乗サイズのテクスチャで問題を起こす場合があります。その場合、そのようなテクスチャをたとえ非HDRフォーマットでエクスポートしても、HDR圧縮の設定を使用することを検討してください。

“uv”頂点アトリビュートがオプションアトリビュートとしてリストされていますが、そのアトリビュートは言うまでもなく必須です。 このノードは、入力ジオメトリ上にUVが見つからなければ、UVを単純に自動計算します。 UVが見つかった場合でも、このノードに自動でUVを再計算させるオプションがありますが、それだとあまり透明性の高いワークフローとはいえないです。 入力ジオメトリを準備する時はLabs Auto UV SOPを使用することを検討してください。

UV Unwrap: 高速。UVレイアウト内は、ばらばらなUV島が多く、回転されたUV島が少ないです。

UV Autoseam and Flatten: 遅いですが、一般的に品質は良いです。UVレイアウト内は、ばらばらなUV島が少なく、回転されたUV島が多いです。

“N”頂点アトリビュートがオプションアトリビュートとしてリストされていますが、そのアトリビュートは言うまでもなく必須です。 このノードは、入力ジオメトリ上に法線が見つからなければ、法線を単純に自動計算します。 法線が見つかった場合でも、このノードに自動で法線を再計算させるオプションがありますが、それだとあまり透明性の高いワークフローとはいえないです。

Vertex Angle: これは内部のNormal SOPのCusp Angleを60、Weighting Methodを“By Vertex Angle”に設定して頂点に対して実行します。

Face Area: これは内部のNormal SOPのCusp Angleを60、Weighting Methodを“By Face Area”に設定して頂点に対して実行します。

“Recompute Tangents using MikkT Method”を指定してこのノードが自動的に“tangentu”接線アトリビュートを再計算できるようにすることを推奨します。

“tangentv”従接線アトリビュートは整合性が合うように常に再計算されます。 従接線の計算方法は Target Engine に依存します。

Right-Hand Rule: 法線と接線の外積から従接線が計算されます。

Left-Hand Rule: 接線と法線の外積から従接線が計算されます。

ファイルのエクスポート先となるディレクトリ。

このアートアセットの全体的な名前。エクスポートされるすべてのファイルの名前は、この文字列で始まります。

静的メッシュのファイル名と拡張子の間に接尾辞を追加します。 Vertex Animation Textures ROP 3.0以降、デフォルトのワークフローでは、フレーム数とFPSを含んだリアルタイムデータファイルをエクスポートする必要がありません。 フレーム数は埋め込まれていて、リアルタイムシェーダによって自動的に引き出されます。 FPSはあまり頻繁に変更するべきではないので、FPSは毎回エクスポートするよりも単純にFPSを覚えておくほうが簡単であると想定されています。 しかし、フレーム数やFPSをどこかに記録したいのであれば、ジオメトリファイル名にその数を追加するという方法があります。 Unreal Engineで利用可能な別の方法は、デバッグモードに入ってフレーム数を確認することです(Include Hidden Debug Plane in Geometryの説明を参照してください)。

レンダリングしてエクスポートしたい一連のファイルを以下から選択します。 Vertex Animation Textures ROP 3.0以降、Normal Textureが廃止され、Rotation Textureに代わりました。これは法線と接線の両方を表現します。 Position Texture 2とSpare Color Textureは、直接ここでは有効化/無効化されません。 これらのテクスチャは Settings タブ内のパラメータに依存します。 ただし、Position Texture 1なしでPosition Texture 2をエクスポートすることもできないし、Color TextureなしでSpare Color Textureをエクスポートすることもできません。

静的メッシュファイルのエクスポートパス。

Position Textureのエクスポートパス。

Position Texture 2のエクスポートパス。

Rotation Textureのエクスポートパス。

Color Textureのエクスポートパス。

Spare Color Textureのエクスポートパス。

Lookup Table Textureのテクスポートパス。

Unity Materialのエクスポートパス。

Real-Time Data JSONファイルのエクスポートパス。

デフォルトでは、出力ファイルはタイプ毎にサブディレクトリにグループ化されます。 これを無効にすることで、同じフォルダ内にすべての出力ファイルが保存されます。

このノードをデバッグまたは変更する時にのみ役立ちます。 これを有効にすると、入力ジオメトリ、ノードパラメータ、内部ネットワークに何か更新があると、その変更が加えられた場所に応じて部分的または全体的に再クックが発動されます。

このノードをデバッグまたは変更する時にのみ役立ちます。 Render All ボタンを押すと、このノードは自動的にLive Updateを有効にして内部ネットワークの完全再クックを有効にします。 このパラメータを使用すれば、レンダリングが完了した後にこのノードが自動的にLive Updateを無効にするのを防ぐことができます。 これはレンダリング後もデバッグを継続できるので便利です。

通常では2枚のHDR Position Texturesを使用するのはリソースの浪費になるので、Texture Formatが“HDR”に設定されている時はSplit Position into Two Texturesへのアクセスは制限されます。このパラメータを使用することで、その制限を上書きすることができます。

Vertex Animation Textures 3.0以降、デフォルトのワークフローでは、何もリアルタイムデータファイルをエクスポートする必要がありません。 以前のバージョンでデータファイルに書き込まれていたパラメータの長いリストは、今では静的メッシュの境界に埋め込まれ、ランタイム時に自動的に引き出されます。 とはいえ、最低でも以下の2つの状況ではレガシーパラメータをまだ扱いたい場合があります:

1. リアルタイムインスタンシングに対応する必要がある場合です。インスタンスのトランスフォームがこの埋め込まれたデータによって間違いを引き起こす可能性があります。

2. エンジン内でオブジェクトの境界スケールを変更する必要がある場合です。この境界スケールによって、この埋め込まれたデータが間違いを引き起こす可能性があります。ただし、以前のバージョンとは違って、今ではその境界はアニメーションの可視領域全体を含むようになった(つまり、カメラを動かしてもメッシュが誤って間引きされることはありません)ので、その境界スケールを変更する理由はほとんどないはずです。とはいえ、アクター/コンポーネント/オブジェクトのスケールを変更しても結果的には安全です。

頂点アニメーションメッシュのリアルタイムインスタンシングに対応するには、これを有効にしてください。 現在のところ、このパラメータは Target Engine が “Unreal Engine”に設定されている場合にのみ違いがあります。 Unreal Engineでは、インスタンスメッシュのローカル空間接線に直接アクセスすることができないので、 Mode が“Rigid-Body Dynamics(Rigid)”に設定されている場合、接線は“uv5”と“uv6”の頂点アトリビュートから引き出す必要があります。

出力テクスチャに最初のフレームデータのみが含まれるようにそれらのテクスチャをクロップします(これを有効にすると、 Pad Texture Size to Powers of Two が無視されます)。 これは、リアルタイムシェーダにおいて現在のアニメーションの進捗に関係なく小さいテクスチャを使用して特定の最初のフレームデータを照会したい時に役立ちます。 Dynamic Remeshing(Fluid)モードでは、Lookup Table Texture以外のテクスチャは最初のフレームデータの簡単な抽出方法によって生成することができないので、Lookup Table Textureのみがクロップされます。

Crop Textures to First Frame Only が有効な時にのみ適用可能です。 Position Textureのアルファチャンネル内のpscalePointアトリビュートまたは独自の浮動小数点アトリビュートは、デフォルトでは、追加情報のパック化を可能とする特別な方法でエンコードされます。 これを有効にすることで、その特別なエンコードを無効にして、このチャンネル内にRaw入力浮動小数点データを格納することができます。 この方法であれば、カスタムセットアップを使用してリアルタイムシェーダ内のPosition Textureのアルファチャンネルにアクセスする時に、そのデータの復元方法を知る必要がありません(圧縮された法線は浮動小数点データではないので、このパラメータは圧縮された法線には何の効果もありません)。

複数のLODを含んだ単一FBXとそのすべてのLODと互換性のある単一テクスチャセットをエクスポートします。 すべての非ゼロLODは、(以下の要件1で説明しているとおり)単にポイントマッピングを介してLOD0のテクスチャを共有しているだけなので、LODを追加してもテクスチャメモリ消費量は増えません。

入力ジオメトリは、以下の要件を必ず満たしてください:

1. すべてのLODsには、“lod0_ptnum”整数Pointアトリビュートがなければなりません。このアトリビュートには、LOD0以降のLODがそのLOD0とエクスポートされたポイントデータを共有できるようにするために、すべての非ゼロLOD内のすべてのポイントをLOD0内のポイントサブセットにマッピングします。Rigid-Body Dynamics(Rigid)モードでは、このアトリビュートをパックポイント上に追加してください。

2. 各LODでは、すべてのポイントを必ず“lod#”ポイントグループ(“#”は0から始まるLOD番号)に割り当ててください。Rigid-Body Dynamics(Rigid)モードでは、このグループにはポイントの代わりにパックポイントを割り当ててください。

3. すべてのLODsは既に頂点上に目的のUVsと法線がなければなりません。このノードは、すべてのLODに対して見つからないUVsと法線を整合性を持たせて確実に自動生成することができません。そのため、自動生成を試みません。

エクスポートするLODの数。最低でもこの数のLODが入力ジオメトリ内に存在していなければなりません。

Pre-Render Scriptを実行する前にすべてのシミュレーションOPsを強制的にリセットします。 これによってシミュレーションはゼロから開始されて、異なるパラメータによって既にクックされた一部のシミュレーションが破棄されるので、これがシミュレーションを出力するのに最も安全な方法です。 ただし、既にクックされたシミュレーションを破棄するのは特に流体といった比較的遅いソルバでは負荷がかかる場合があります。

このスクリプトは、レンダリング前に実行されます。

このスクリプトは、すべてのレンダリング後に実行されます。

オプションのタグを付けて出力ファイルパスをプリントします。

COPs内の画像データは常にリニアです。リニアでない画像フォーマット(例えば、sRGB)に書き出す時、これはその画像のルックが維持されるようにカラースペースを変換します。 カラースペースが指定されていない8ビットフォーマットはsRGBと想定されます。

画像のバイト形式。ビット深度が大きいほど色の解像度が良くなる反面、メモリ使用量が増えます。

8 Bit Integer: 最小ビット深度。場合によってはマッハバンドが生じます。動画に適しています。

16 Bit Integer: 中間ビット深度。マッハバンドが生じにくいですが、ブラックポイントとホワイトポイントを超えた値はクリップされます。

32 Bit Integer: 通常ではカラー値に使用しません。32ビット整数値はオブジェクトID、数、他の広い範囲の整数値を格納する際に使用します。

16 Bit Floating Point: 高いビット深度。マッハバンドが生じにくく、ブラックポイントとホワイトポイントを超えた値はクリップされません。32 Bit Floating Pointよりもメモリ使用量は少ないです。とはいえ、この形式での処理時間は、それがネイティブのCPUデータ形式でない場合には若干遅くなります。この形式は-65504から+65504の範囲の値に対応しています。

32 Bit Floating Point: 高いビット深度。マッハバンドが生じにくく、ブラックポイントとホワイトポイントを超えた値はクリップされません。8ビットの4倍のメモリを消費します。それがこの形式の主な欠点です。

整数形式(8, 16, 32ビット)では、ブラックポイントまたはホワイトポイントにしたいRaw値を指定することができます。 ホワイトポイントは必ずブラックポイントよりも大きい値でなければなりません。各形式でのブラックポイントとホワイトポイントの最小値と最大値は以下のとおりです:

8ビット : 0 - 255

16ビット : 0 - 65535

32ビット : 0 - 2,147,483,647

浮動小数点形式では、常にブラックポイントが0、ホワイトポイントが1です。

異なるデータフォーマットで別々にチャンネルをレンダリングします。

Takeを使って作業している場合は、任意でこれを有効にすることができます。

カスタムエンジンの座標系に合うようにこれを設定します。 まず最初に、エンジンの座標系を決める必要があります。 時計回りの規則に従うと、座標系の3つの正方向の軸すべてがあなたの方に向いている状態から見て、Up軸から順に時計回りに軸を数えて座標系を決めます。 右手系または左手系の規則に従うと、まずその手をグーにして、親指と人差し指を伸ばし、中指を手のひらに対して垂直に保ちます。その人差し指を+X、その中指を+Y、その親指を+Zと決めます。

実世界の1メートルに相当するターゲットエンジンのユニット数。これは、エクスポート時の変換スケールを決める際に使用されます。

選択したエンジンのシェーダリソースを表示します。

このボタンを押すと、Unreal Engine用SideFX Labsコンテンツプラグインのディレクトリが開きます。 必要なUnreal Engineのバージョンに該当するフォルダの中に入って、そのフォルダ直下に配置されているガイドテキストに従ってください。

このボタンを押すと、Unity用SideFX Labs Vertex Animation Texturesパッケージの“URP_VAT3”ディレクトリが開きます。

ジオメトリの境界に埋め込まれているデータを表示します。 このリストを使用することで、リアルタイムシェーダ内で復元されるデータが正しいかどうかを検証することができます。 このリストは、ターゲットエンジン内のデータ表示順で並んでいます。 現在のところ、Unreal Engineのみが埋め込みデータのデバッグに対応しています。