CG 日記

Tips

Discrete Particles for Modo の使用方法

アイテムを重ならないように散布できるプラグイン「Discrete Particles」のメモです。使用バージョンは1.0です。
一部の設定を変更しないと機能が意図したように動作しなかったので、調べたこと残しておきます。

 

Discrete Particlesとは

Discrete Particlesは高速なパッキングアルゴリズムを使用して、メッシュの表面、またはメッシュのボリューム内にパーティクルを生成するプラグインです。
Replicatorを使用してアイテムを複製するときに、アイテム通しが重ならないようにパーティクルを生成できます。

modo標準の機能で例えると、Surface Particle Generatorの機能強化版です。

 

例えば下の画像は、ブーリアンとモーフィングを適用したメッシュにパーティクルを発生させる例です。

 

Surface Particle Generatorを使用すると、オブジェクト通しが重なります。またブーリアンでメッシュのトポロジーが変わる場合、パーティクルがランダムに生成されます。

 

Discrete Particlesはオブジェクトが重ならないようにパーティクルを生成します。また、テクスチャの投影のような仕組みになってるので、トポロジーが変わってもパーティクルの生成が安定しています。

また、Packing ModeにAABBを使用すると、デフォーマでサイズを変更してもオブジェクトが重ならないようにパーティクルが生成されます。

 

Chaosを使用するとパーティクルサイズをよりランダムにできますが、 パーティクル生成がランダムに変化してしまいます。

WhiteNoiseを使用するとパーティクルサイズをよりランダムにしながら、アニメーションしても大丈夫なようです。

 

 

使用方法

アイテム構成

Discrete Particlesをインストールするとアイテムが4つ追加されます。基本的に「Surface Distribution」「Volume Distribution」を追加して使用します。

  • Ray Domain
  • Ray Projection
  • Surface Distribution
  • Volume Distribution

 

Surface Distributionはメッシュの表面にパーティクルを散布するアイテムです。
Volume Distributionはメッシュのボリューム内にパーティクルを散布するアイテムです。

Ray DomainとRay Projectionはテクスチャロケータと同じ役割で、散布に使用するレイのプロジェクションタイプを指定するアイテムです。
Surface DistributionやVolume Distributionを追加すると、Ray DomainやRay Projectionは自動的に追加されます。

 

パーティクル生成

Surface DistributionやVolume Distributionを使用する場合は、アイテムの「Surface(Mesh)」「Volume(Mesh)」に散布用のメッシュを接続します。

 

サンプル見ずに使ってみたところ、一部の設定を変更しないと機能が意図したように動作しませんでした。疑問に思った設定をまとめておきます。

  • 「Sample Mode」 は「RayCast & Pack」に変更します。デフォルトだと「Preview」になっていてサーフェースやボリュームに散布されません。
  • 「Weight Map」を使用する場合は「WeightMap Blend」を1.0に変更します。デフォルトの0のままだと何も変化がありません。
  • Discrete Particlesでは「原型となるアイテム(プロトタイプ)」は1mを基準に動作します。1mより大きいとメッシュに重なりが発生します。

 

 

プロパティ

Discrete Particlesはドキュメントがないようなので、プロパティのツールチップを翻訳してみました。

 

Surface Distribution

Point Sampling

Sample Mode

4種類のサンプルモード

  • Preview : 投影ギズモ上のパーティクルを、MinSizeをパーティクルサイズとしてサンプリングします。
  • Raycast : MinSizeをパーティクルサイズとして、メッシュサーフェス上のパーティクルをサンプルし、レイキャスします。
  • Preview & Pack : MinSizeからMaxSizeまでのパーティクルサイズを使用して、プロジェクションギズモ上でパーティクルのサンプルとパックを行います。
  • Raycast & Pack : MinSizeからMaxSizeまでのパーティクルサイズを使用して、メッシュサーフェス上のパーティクルをサンプル、レイキャスト、パックします。
Backface Culling

バックフェイス ポリゴンのサンプリングが有効な場合は無視します。

Distribution

パーティクル分布の一様性

  • BlueNoise R2(一様)
  • Blue-Noise Hammersley (半統一)
  • WhiteNoise PSRand (ランダム)
Packing Mode

AABB = 軸方向に整列したバウンディングボックス (Axis Aligned Bounding Box)
AABBオプションを使用すると、プロトタイプをSurface DistributionとReplicatorノードに同じ順序でリンクする必要があります。

Point Count

頂点数。

Multiplier

Point Count * Multiplier はパーティクルの総数に相当します。
平面プロジェクションでMultiplierを1.0とした場合、ボックスプロジェクションではボックスの各面で同じパーティクル密度を得るために6.0に設定する必要があります。

Point Size

GLで描画するパーティクルの大きさ。

Point color

パーティクル色です。

 

Particle Settings

Prototype Domain

1.0mの原型基準領域を表示し、原型のサイジングの参考にできます。

Prototype Scale

パッキングアルゴリズムは、プロトタイプのサイズが1m以下であることを想定しています。プロトタイプのサイズをエレメントレベルで設定するか、このスケーリング値でスケールを調整してください。

Weight Map

ウェイトマップ。

MaxSize

パーティクルがサーフェースでサンプリングできる最大サイズ。

MinSize

パーティクルがサーフェースでサンプリングできる最小サイズ。

WeightMap Blend

ウェイトマップに基づいてパッキングパーティクルサイズを制御します。
値0.0はオフ。1.0は最大ブレンドに相当します。

Chaos

サンプリング中に各パーティクルが得るサイズのばらつきを制御します。
0.0ではパッキングアルゴリズムはデフォルトで各パーティクルのサイズを最大化しようとします。

Packing Distance

パーティクルサイズに比例して、パーティクルとパッキングボーダーの間に距離を追加します。
MaxSizeを大きくすることで縮小するパーティクル径を補うことができます。

Shrink Spacing

パーティクルを縮小し、パーティクルのパッキング境界線に間隔を作ります。

Post Sizing

ポストエフェクトとして、グラデーションに応じたサイジングを適用します。
グラデーションの左側が小さいパーティクル、右側が大きいパーティクルです。

Normal Alignment

サーフェース法線に対するパーティクルの向きのアライメント。値0.0はオフで、デフォルトはY-Up。

Surface Offset

サーフェス法線に基づいてパーティクルをオフセットします。

Display Packing

GLパッキングモードの描画。

PackMode color

パッキングモードの色です。

 

Performance Statistics

Enable

3Dビューポートのパフォーマンス統計情報を表示します。

Vertical Offset

垂直オフセット。

 

Volume Distribution

多くのプロパティがSurface Distributionと共通なので、Volume Distributionにあるプロパティだけ書いておきます。

 

Particle Settings

Packing Distance

パーティクル径に比例した充填距離。MaxSizeを大きくすることで縮小するパーティクル径を補うことができます。

Volume Constraint Mode

Shrinkモードは内包するメッシュと交差するパーティクルを縮小します。
Removeモードは内包するメッシュと交差しているパーティクルを削除します。

Volume Constraint

値を大きくすると内包するメッシュと交差するパーティクルを収縮させます。
1.0の値は交差が発生しないことを完全に保証するものではありません。

Normal Alignment

パーティクルの向きを最も近いポリゴン法線に揃えます。
0.0 を指定するとパーティクルは Y-Up 方向に整列します。

 

サンプルファイル

Discrete Particlesには11個のサンプルファイルが入ってます。
コメントノードにプロパティの解説やチュートリアルが書かれてるので、テキストを翻訳してみました。

 

1_Introduction.lxo

Discrete Particles は、Surface Distribution と Volume Distribution というパーティクルシステムを実装しています。これらは、DEX/Discrete Particlesセクションのアイテム追加ポップアップで見つかります。

これは、Discrete Particles システムを正しく動作させるために必要な基本的/最小限のノードの設定です。
以下のいずれかのノードのリンクを切断すると、パーティクルシステムは状態の評価を停止します。
Volume Distributionの設定は、Ray Projection 項目の代わりに Ray Domain 項目を使用する以外は同じです。

ただし、Ray Projectionアイテムの代わりに Ray Domainを使用します。Ray ProjectionとRay Domainを使用するため、シーンにDistributionアイテムを追加する必要があります。
Ray Projection と Ray Domain アイテムは自動的に追加されます。
先に進む前に「ロケータの表示」が有効になっていることを確認してください。

チュートリアル
  1. Ray Projectionアイテムをクリックし、Projectionドロップダウンリストから様々なプロジェクションタイプを試します。
  2. Planar projectionに戻します。
  3. Surface Distributionの項目をクリックし、そのプロパティフォームとチャンネルのツールチップを見ます。
  4. 半径 0.5m の球体を Prototype meshに追加し、アイテムリストで可視性をオフに設定します。
  5. シーン内の紫色の破線領域は、プロトタイプのサイズ制限を定義する 1m 単位の立方体です。
  6. この領域の外側にあるすべてのポリゴンは、重なりが発生する可能性があります。場合によってはプロトタイプをドメインより大きくしても良い場合があります。例えば平面上に高層ビルを詰め込むような場合です。
  7. Surface Distributionをクリックし、プロパティフォームで異なるSample Modesを試します。
  8. ツールチップを読んで、4つの異なるSample Modesが何をするのか理解してください。
  9. サンプルモードを Preview に戻します。
  10. Distributionのドロップダウンで3つの異なるDistributionを試します。そのツールチップを読んでください。
  11. サンプルモードを「Raycast & Pack」に設定します。
  12. Ray Projectionアイテム(ギズモ)を選択し、移動/回転/スケール変換を試します。
    次に、Surface Distributionシステムの様々な設定で遊んでみてください。
    Packing Modes については、別のチュートリアルで説明します。AABB モードを使用するには、最初にプロトタイプメッシュをSurface DistributionアイテムのAABBプロトタイプスロットに接続する必要があります。
    (AABBはAxis Aligned Bounding Boxの頭文字を取ったものです)。
  13. アイテムリストのSurface Tutoralフォルダの可視性をオフに設定します。
  14.  Volume Distribution を使って、同様のノード設定を行います。Volume Tutorial フォルダにアイテムを配置します。

チュートリアル終了

 

 

2_Surface_Packing_Modes.lxo

 

3_SurfaceDistribution_Falloff_example.lxo

この例ではBlend Falloff を使って、アニメーションするプロシージャルテクスチャをフォールオフフィールドに「変換」しています。
リニアフォールオフはテクスチャフォールオフとブレンドされます。
Ray Projectionはボックスプロジェクションモードに設定され、Surface Distribution パッキングモードはCircularに設定されています。

アニメーションをリアルタイムで見るには、タイムラインをスクラブしてください。

  • Distribution は完全にランダムな結果を生成するWhiteNoise PSRandに設定されています。
  • BlueNoise R2 は最も均一な結果を生成します。
  • BlueNoise Hammersley は「半」アンフォーム分布で、R2に比べてあまり均一な結果を生成しません。

 

 

4_SQUARE_vs_CUBE_Packing.lxo

スクエアvsキュービックパッキング

手順

  1. ノードグラフを調べます。
  2. SkyScraperプロトタイプメッシュの可視性をオンに設定します。
  3. SkyScrapersの下部が紫色のプロトタイプドメインの中央にどのように配置されているかを観察します。
    また、その上に拡張されます。パッキングはドメイン内のポリゴンのみを考慮します。
  4. SkyScraperプロトタイプメッシュの可視性をオフに設定します。
  5. タイムスライダーをフレーム70にドラッグします。
  6. SkyScraperの底面が平面ポリゴン上に完全に配置されていることを確認します。
  7. Surface Distributionを選択し、Packing modeをCubicに設定します。
    パックされたパーティクルのgl-drawing以外の違いは見られないはずです。
  8. Normal Aligmentを1.0に設定して、パーティクルが表面の湾曲にどのように整列するかを確認します。
  9. 次にSquare と Cubic パッキングモードを切り替えて、違いに注意してください。

結論
Normal Aligment を使用すると、Cubic パッキングによって曲面がオーバーラップする可能性が低くなります。Squareパッキングは少し高速で平らな面で使用する必要があります。

 

 

5_Volume_Packing_Modes .lxo

 

6_VolumeDistribution_Falloff_example.lxo

この例ではBlend Falloff を使用して、アニメートされたプロシージャルテクスチャをフォールオフフィールドに変換しています。
RayDomain は Box projection モードに設定され、Volume DistributionのPacking modeは Spherical に設定されています。

アニメーションをリアルタイムで見るには、タイムラインをスクラブしてください。

  • パーティクル分布は、最も均一な結果を生成するBlueNoise R2に設定されています。
  • BlueNoise Hammersleyは「半」アンフォーム分布で、R2よりも均一でない結果を生成します。
  • WhiteNoise PSRandは、完全にランダムな結果を生成する擬似ランダム分布です。

 

 

7_CUBE_vs_AABB_Packing_and_Transforms.lxo

Cubic vs AABB パッキングとトランスフォーム

AABBとは、Axis Aligned Bounding Boxの頭文字を取ったものです。

  • キュービック=黄
  • AABB = 緑

このチュートリアルでは、どちらのボリューム分布も VolumeMesh アイテムと Prototype アイテムを共有しています。
XYZのすべての寸法がちょうど1mなので、UnitCubeと名付けました。
Locatorアイテムはこの設定とは関係ありません。このチュートリアルのヘルパーとして機能するだけです。
Distributions は X 軸上で +/-1m 移動し、両者を離しています。

Distributions (Raycast mode)は、ボリュームメッシュやプロトタイプとは独立して動かすことができます。
シーンでの評価は、Ray Domain トランスフォームによって決定されるからです。同じルールが、Surface Distribution アイテムとRay Projectionアイテムにも適用されます。

 

チュートリアル
  1. シーン内のオレンジ色のロケータをクリックし、「Normal Aligment」チャンネルを開きます。
  2. Cubicパッキングが、すべてのバウンディングボックスの XYZ 寸法をどのように保持するかを観察します。
  3. AABBパッキングが、Replicatorのバウンディングボックスを動的に更新する様子を観察します。
  4. Particle Countを増やし(このチュートリアルリグでは1万個に制限)パッキングを観察します。AABBはパッキングをより最適化しますが、Cubicパッキングより若干パフォーマンスが劣ります。
    これはサイズや形状の異なる複数のプロトタイプがある場合に、より顕著になります。
    複数のプロトタイプを使用した AABB は、別のチュートリアルのシーンファイルで説明されています。トランスフォームの説明
  5. Ray Domain と Volume メッシュの可視性をオンにします。
  6. Volume Distribution アイテムの1つを移動します。
  7. 次に Ray Domain アイテムを動かして、何が起こるかを観察します。

    Ray DomainはDistributionがレイキャスティングを実行する場所をコントロールします。
    パーティクルは RayDomain が VolumeMesh と重なる場所にのみ追加されます。
    これらの2つの記述はSample ModeがRaycastingモードの時のみ有効です。

    Sample ModeがPreviewに設定されているときにステップ6と7を試してみると、結果がRay domain gizmoに束縛され、Volume meshのポリゴンを無視することが分かります。
    つまり、Previewはレイキャスティングのコストを無視して、特定のパッキングパターンをより速く見つけるための方法です。

     

     

    8_VolumeDist_Fill_a_Bowl_.lxo

    この例では球に立方体のパーティクルを充填するセットアップを紹介します。
    Ray DomainはBox projectionモードに設定され、Volume Distribution packingモードはCubicに設定されています。
    これらのモードは変更することができ、ユースケースによって異なる結果をもたらします。

    チュートリアル
    1. シーン内のパーティクルが球メッシュの「壁」内にどのように配置されているかを観察してください。
      レイキャスティングは各パーティクルに対して2本のレイを反対方向に送ります。両方のレイがポリゴンに当たった場合、法線がパーティクルの位置から離れる方向(つまりポリゴンの裏側)にあることから パーティクルがメッシュの内側にある可能性が高いことがわかります。
    2. プロパティのInvert Normalsパラメータをチェックし結果を確認します。
    3. レイキャスティングロジックを反転させたので、球にパーティクルが含まれているはずです。
    4. Replicatorの一部が球と干渉しています。これを修正するにはVolume Contraint を1.0に増やして、交差を減らします。
    5. Volume Contraint Mode を Replace に変更します。このパラメータのツールチップを見てください。

    DistributionはWhiteNoise PSRandに設定されています。均一なBlueNoise Distributionsを試して、その違いを見てください。

    チュートリアル終了

     

     

    9_Surface_Projection_Example.lxo

    タイムラインをスクラブすると、アニメーションが表示されます。
    Surface DistributionアイテムのPrototype Scale が 1.0 以上に設定され、プロトタイプのオーバーラッピングが意図的に発生するようになりました。Ray Projectionアイテムのスケールをアニメーションしています。

     

     

    10_Surface_Projection_Weightmap.lxo

    Plane メッシュを選択し、プロパティのWeight Mapにあるウェイトマップ「SurfDistWmap」を選択します。
    ウェイトマップツールでPlaneメッシュにペイントします。

     

    PalmTreeScene.lxo

    この数式ノードで使用する値によっては、かなり重いシーンになる可能性があります。そのため、クランプ関数は0.1〜5.0の間に値を制限しています。

    このシーンでは、2つのSurface Distributionが使用されています。
    一つはヤシの木用、もう一つは草用です。ヤシの木の下に草が生えるようにしたいので、これらの分布の間のパッキングは考慮されていません。

    また、Gound Planeにはウェイトマップが用意されています。いずれかの分布を選択し、ドロップダウンを使って選択します。ウェイトマップブレンドパラメータを使用して、それを微調整します。
    このシーンで遊んでみてください。

     

    参考

    Tips

    modoでパーティクルにテクスチャの色を設定する方法

    modoでパーティクルにテクスチャを使用して色を設定する方法について書いてみたいと思います。
    Steve Hillさんが公開していたビデオの内容を試してみた。という内容の記事です。

     

    ■サンプルファイル

     

    スケマティックはこんな感じです。

    パーティクルオペレータの「タイプ」で「新規」を使用して、パーティクルが発生時に色を設定します。

    テクスチャをパーティクルオペレータの「色」に接続するため、テクスチャの「スウィズル」を使用して画像をRGBそれぞれチャンネルごとに分解して、Falloff Probeを使用してテクスチャの座標の色をパーティクルに設定します。

     

     

    Raycastを使用した方法も試してみました。

    ■サンプルファイル

     

    スケマティックはこんな感じです。

    パーティクルオペレータの「タイプ」で「新規」を使用すると、Raycastを使用した場合もパーティクルが発生時の色を設定できます。しかし、パーティクルが移動してると、パーティクル発生位置に移動したReplicatorにレイがヒットしてしまい色が変化してチラツキが発生します。
    パーティクルを発生させた後に位置をオフセットしてあげれば、パーティクルにレイがあたらなくなり上手くいきそうですが、Raycastを使用する場合は注意する必要がありそうです。

     

    modoは701でパーティクルシミュレーションが搭載されましたが、パーティクル発生時にテクスチャーの色を設定して維持する方法が長い間わからないままでした。

    これまではReplicatorで複製するメッシュのマテリアルに、「ワールド座標系」を使用してテクスチャを貼る方法。「Raycast」を使用する方法の2つがよく紹介されてきました。

    しかし、「ワールド座標系」と「Raycast」は静止画では問題ないのですが、アニメーションするとテクスチャがワールド座標に貼りついたように見えるため、望ましい方法ではありませんでした。
    また「ワールド座標系」を使用すると、テクスチャの1ピクセルの色をメッシュの色として継承したいのに、テクスチャの模様がそのままメッシュに投影されてしまうという問題もありました。

    長い間謎でしたが、言われてみると単純でしたね。

     

    参考

    Tips

    MayaでFBXファイルのコンストレイントを読み込む方法

    MayaでFBXファイルのコンストレイントを読み込む方法について書いてみたいと思います。
    Mayaのファイル読み込みの動作が気になったのでメモです。

     

    FBXファイルのコンストレイント

    FBXファイルにはコンストレイントを保存することができます。FBXが対応しているコンストレイントは以下の5種類です。

    • ポイント
    • エイム
    • 方向
    • ペアレント
    • IK ハンドル(極ベクトルを含む)

    FBXのコンストレイント保存に対応してるソフトは多くありませんが、MayaやMotion Builderは入出力に対応しています。Unityなどのゲームエンジンでもコンストレイントを読み込むことができます。

     

    Mayaのコンストレイント。

     

    FBXのコンストレイント書き出しオプション。

     

    MayaでFBXファイル読み込み

    MayaでFBXファイルを読み込む場合、ファイルメニューの「読み込み」から行います。

     

    このとき読み込みダイアログのファイルの種類が「すべてのファイル」の状態でFBXを読み込むと、コンストレイントが正しく読み込めません。

     

    コンストレイントが読み込まれない。

     

    コンストレイントを読み込みたい場合は、ファイルの種類を「FBX」にしてから読み込む必要があります。

     

    コンストレイントが適用されている。

     

    ファイルの種類を「FBX」にしてFBXを読み込んだ後は、「すべてのファイル」に変更してもFBXのコンストレイントが正常に読み込むことができる状態になります。

    FBXの読み込みオプションではコンストレイントの読み込みはデフォルトでONなので「すべてのファイル」でも正しく読み込んでくれてよさそうなのですが、Mayaはファイルの種類を指定しないと正しくファイルをロードできない場合があるようです。ファイル読み込み動作に一貫性がないのは困りものですね。

    Tips

    modoのFBX出力の文字化けを回避する方法

    modoのFBX出力の文字化け回避方法について書いてみたいと思います。

     

    modoはレンダリング画像の出力先やFBX出力先のファイルパスに日本語文字を含む場合、文字化けが発生したり、ファイルの出力に失敗することがあります。

    先日、FoundryのサポートにFBXのファイルパスが文字化けするので改善して欲しいとバグを報告したのですが、日本語版WindowsではUnicodeに対応していないプログラムの言語にShift-JISが使用されてるのが原因だと教えていただきました。

    Windowsの非Unicodeプログラムのデフォルトの言語設定をUnicode UTF-8に変更すると、ファイルパスの文字化けを回避できます。

    Modo for WindowsはUnicodeアプリケーションではありませんが、レガシーマルチバイトエンコーディングに対応しており、日本語版WindowsではデフォルトでShift-JISエンコーディングが使用されています。
    Unicodeでないアプリケーションの言語は、コントロールパネルの「地域と言語」セクションの設定内で定義されます。この場所で言語を英語に切り替えると、問題が改善される場合があります。

     

    Windowsの非Unicodeアプリケーションのデフォルト設定をUnicode UTF-8に変更する方法

    Windows 10 の文字コードはUnicode UTF-16を使用しているようですが、非Unicodeアプリケーションでは互換性を維持するため、デフォルトでShift-JISが使用されます。

    非Unicodeアプリケーションのデフォルトの言語設定をUnicode UTF-8に変更するには、Windowsの「地域の設定」から「ベータ:ワールドワイド言語サポートで Unicode UTF-8 を使用」をONに変更します。

    コントロール パネル\時計と地域\日付、時刻、数値形式の変更\管理\システムロケールの変更

     

    この設定はUnicodeに対応していない全てのアプリケーションに影響します。古いアプリケーションを使用している場合は、今まで問題のなかったアプリケーションで逆に文字化けする場合があります。
    私の環境では圧縮解凍ソフトや一太郎2021など、グラフィック以外のソフトが文字化けするのでこの設定を使うわけにはきませんでした。

    以前はMicrosoftが「Microsoft AppLocale」という、非Unicodeアプリケーションをユーザーが選択した設定で実行できるようにするプログラムを公開していたようですが、現在のOSでは動作しなくなったため公開が終了してしまったようです。

     

    FBXファイルの文字化け

    「新しいフォルダー」にASCII形式でFBXを出力します。FBXファイルをテキストエディタで開くと「新しいフォルダー」が文字化けしているのが確認できます。

     

    「ベータ:ワールドワイド言語サポートで Unicode UTF-8 を使用」OFF

    FBXの出力先のパスが文字化け。

     

    テクスチャーパスが文字化け。

     

    「ベータ:ワールドワイド言語サポートで Unicode UTF-8 を使用」ON

    FBXファイルをテキストエディタで開くと「新しいフォルダー」が文字化けしていないことが確認できます。

    FBXの出力先のパスが正しく保存されるようになった。

     

    テクスチャーパスが正しく保存されるようになった。

     

    3dsMaxやMayaのFBX出力では文字化けが発生しないので、Modoを使う場合だけファイルパスに気を配る必要があるのが不便です。「FileName:」は文字化けしてないので同じようにファイルパスを保存してくれればいいと思うのですが、他のアプリケーションで実際に使用される方のパスが文字化けしてしまってます。ModoをUnicode対応にして文字化けを改善していただきたいですね。

    Tips

    Windowsで使用されるアプリケーションアイコンの画像サイズ

    Windowsで使用されるアプリケーションアイコンの画像サイズに関するメモです。

    Windowsではデスクトップやエクスプローラーなどでアイコン画像が表示されます。アイコン画像に使用される「.ico」ファイルには解像度の異なる複数の画像が格納されていて、エクスプローラーの表示設定によって適切なサイズの画像を表示します。

     

    Windowsで必要なアイコンの画像サイズ

    .icoファイル作成時に必要な画像サイズは以下の14枚です。
    * マークの5枚は最低限あった方がよいサイズで、それ以外のサイズはディスプレイの表示スケールとの組み合わせで使われる。

    • 16 x 16 *
    • 24 x 24 *
    • 32 x 32 *
    • 48 x 48 *
    • 256 x 256 *
    • 20 x 20
    • 30 x 30
    • 36 x 36
    • 40 x 40
    • 60 x 60
    • 64 x 64
    • 72 x 72
    • 80 x 80
    • 96 x 96

     

    ■サンプルアイコン

    このアイコンファイルには以下の14枚の画像が含まれています。

     

    表示スケールによって使用されるアイコンサイズが変わります。ただし、表示スケールの変更が即時適応されるわけでなく、Windows ログイン時の表示スケールが使用されるようでした。

     

    エクスプローラーでアイコンサイズの切り替え確認

    エクスプローラーの表示を切り替えて.icoファイルの表示画像が変わるのを確認した。

    表示スケール100%

    16、32、48、256の画像が使用される。

     

    表示スケール 125%

    20、40、60、256の画像が使用される。

     

    表示スケール 150%

    24、48、72、256の画像が使用される。

     

     

    いまどきのソフトならサイズの異なる画像を一括出力するのはそんなに手間ではないので、とりあえず全サイズを.icoファイルに入れておけば様々なディスプレイ環境に対応できるのでよさそうです。

     

     

    参考「Windows アプリの開発に関するドキュメント」

    https://docs.microsoft.com/ja-jp/windows/apps/design/style/app-icons-and-logos#target-size-app-icon-assets

    Tips

    MayaのRender Setupでマテリアルを置き換える方法

    MayaのRender Setupで、フェースアサインした特定のマテリアルをShader Overrideで置き換える方法の覚え書きです。

    Render Setupはアトリビュートの値をレイヤーのように上書きして、好みのレンダリング画像(カスタムAOV)を作成する機能です。Render SetupのShader Overrideを使用すると、特定のマテリアルを異なるマテリアルに置き換えてレンダリングすることができます。

     

    Collectionを作成して右クリックからCreate Shader Overrideを実行、Shading EngineのCollectionを作成します。
    IncludeにデフォルトでExpressionの*が入ってるので削除します。Addボタンで置き換え元のShading Engineを追加します。

     

    Shader Overrideで置き換え先のマテリアルを接続すれば設定完了です。

     

    画像ではPhongをRamp Shaderに切り替えてレンダリングしてます。

     

     

    マテリアル全体の置き換え、例えばAmbient Occlusion専用の画像を作成したい場合はMaterial Overrideを使用します。

     

     

    Render Setupで色など一部アトリビュートのオーバーライドの記事は多く見かけるのですが、フェースアサインしたマテリアルの切り替えについて書かれてる記事が見つけにくかったので、メモ的に残しておきます。

    Tips

    modoのEscキーによる選択解除の動作

    modoのEsc キーによる選択解除の動作について書いてみます。

    modoはEsc キーを押すとアクティブなツールを解除することができますが、続けてEsc キーを押すとアクションセンターやフォールオフ、選択コンポーネントを解除することができます。

    • ツール解除 → アクションセンター+フォールオフ+メッシュコンストレイント解除 → 選択解除

     

    modoの質問に回答してるのを見かけて知りました。これは便利なので積極的に使って行きたいですね。

    Tips

    modoでリプリケータをポイントクラウドに変換する方法

    modoでReplicatorの「ポイントソース」をポイントクラウドに変換する方法について書いてみます。

     

    Replicatorはメッシュの頂点にアイテムを複製する便利な機能ですが、Surface Particle Generatorを使用してランダムに複製している場合、特定のアイテムを削除したり位置を微調整することが難しい場合があります。

     

    modo 15.2で追加された「インスタンスをリプリケータへ」コマンドを使用すると、インスタンスの位置を元にポイントクラウド(トランスフォームマップを持った頂点)を作成することができるようになりました。

     

    Replicatorをポイントクラウドに変換する手順は以下の通りです。

    [変換手順]
    1. Replicatorを選択して「リプリケータのフリーズ」実行
    2. インンスタンスを選択して「インスタンスをリプリケータへ」実行

     

    Replicatorを選択して「リプリケータのフリーズ」を使用すると、インンスタンスが作成されます。

     

    インンスタンスを選択して「インスタンスをリプリケータへ」を使用すると、Point CloudとReplicatorにすることができるようになりました。プロシージャル的に頂点を作成するSurface Particle Generatorと異なり、Point Cloudは普通の頂点データなのでモデリングツールで頂点の位置等を編集することができるようになります。

     

    「リプリケータのフリーズ」するのが面倒なので、Replicatorをポイントクラウドに一発変換できるようにバッチコマンドを作ってみました。Replicatorを選択してからコマンドを実行してください。

    cmds.batch {Temp} {replicator.freeze} {select.itemType meshInst} {replicator.instanceToRep useItemMap:true onlySelectedInstances:false}

     

    select.itemTypeを使ってインスタンスを選択してるので、もしもシーンに複数のインスタンスがある場合は全部ポイントクラウドに変換します。
    トランスフォームマップを選択して頂点を編集すると、Replicatorで複製されたアイテムの位置回転スケールを編集することができます。

     

    「インスタンスをリプリケータへ」は便利に使えそうでいいですね。

     

    参考

    「インスタンスをリプリケータへ」コマンドは元々15.1の静的解析ツールに実験的に搭載されました。15.2では正式なコマンドとして追加されました。

    Tips

    modoのFBXのメディア埋を込み

    modoのFBXのメディア埋め込みについて書いてみます。

    modo 15.1v2から「初期設定」のFBX入出力に「メディアを埋め込み」が追加されました。これはシェーダーツリーで使用しているテクスチャ画像をFBX内に保存するためのオプションです。

     

    .lxo内に保存される画像パスに絶対パスや相対パスが混在してしまい、他の人にデータを渡したときにリンク切れが発生することがあります。「メディアを埋め込み」を使用するとFBXファイル内に画像を保存しているので、他の環境でファイルを開いても画像のリンク切れを気にしなくてよくなります。

    「メディアを埋め込み」を使用する場合は、画像パスに日本語文字が含まれていると正しく出力できないので注意が必要です。

    メディアの埋め込みした場合は、画像が含まれているためFBXファイルの容量が大きくなります。

    メディアを含むFBXファイルを開くと、.lxoファイルと同じディレクトリに「FBXファイル名.fbm」フォルダが作成されて画像が保存されます。

     

    画像を編集する場合はメディアの埋め込みしない方がFBXファイルの容量が小さく取り回しが便利なのですが、とりあえずFBXファイル単体でデータを完結したい場合には便利なオプションです。

    CG 日記

    Windows 10で非アクティブのウィンドウ色を変更する方法

    Windows 10で非アクティブのウィンドウ色を変更する方法について書いてみます。

     

    概要

    Windows 10 で配色にダークモードが追加されました。しかし、ウィンドウのアクセントカラーを設定していても、非アクティブのウィンドウ色は暗いグレー色固定です。ウィンドウが重なってると、どこがタイトルバーなのか判別しにくく誤操作が発生しやすくて困ります。

    非アクティブのウィンドウに好きな色を設定することで、ウィンドウの視認性を向上させることができます。

     

    非アクティブのウィンドウ色を変更する方法

    非アクティブのウィンドウ色を変更するには、レジストリエディーターで値を追加する必要があります。

    1.レジストリエディーターに以下のパスをペーストしてEnter、DWMキーに移動します。

    HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\DWM

     

    2.右クリックメニューから「DWORD (32ビット)値」を追加します。

     

    3.追加した値を「AccentColorInactive」にリネームします。値をダブルクリックして、ダイアログの「値のデータ」に16進数で色を入力します。

    PhotoShopなど一般的なグラフィックソフトでは16進数で色はRRGGBB順ですが、BBGGRRで入力する必要があるらしいです。最初に変更したい色を設定して、ずれた色相ぶん色相シフトした値を入力した方が編集しやすかったです。

     

    設定が完了すると、ウィンドウの非アクティブ色が変わってることが確認できます。

    Tips

    After Effectsで複数のフッテージのフレームレートを一括で変更する方法

    After Effectsで、複数のフッテージのフレームレートを一括で変更する方法について書いてみます。

     

    フレームレート情報を格納した動画ファイルの読み込みで問題になることは少ないかもしれませんが、CGのように連番ファイルを読み込む場合、意図したフレームレートで読み込まれない場合が多々あります。

    読み込んだ複数のフッテージのフレームレートを一括で変更する場合は、コピーしたいフレームレートのフッテージを選択して右クリックメニューから「変換を記憶」を実行し、ペーストしたい複数のフッテージを選択して右クリックメニューから「変換を適用」を実行します。

    フッテージを変換 / 変換を適用

     

    フレームレートの変更手順。

     

    たまに忘れてしまうので、メモ的に記事を残しておきます。

    Tips

    After Effectsのタイムラインでレイヤーを詰めて並べる方法

    After Effectsのタイムラインで、レイヤーの長さでレイヤーを詰めて並べる方法を紹介します。コンポジションをループさせたい場合にタイムリマップを使用するとレンダリング時間が長くなるため、複製したコンポジションを並べたい場合に便利です。

     

    After Effectsのタイムラインで、隙間が出来ないように各レイヤーの長さごときっちり詰めた状態で並べたい場合があります。

    上の画像を、下の画像のようにレイヤーを階段状に、きっちり詰めて並べたい。

     

    詰めてレイヤーを配置したい場合は「シーケンスレイヤー」を使用します。

    アニメーション / キーフレーム補助 / シーケンスレイヤー

     

     

    シーケンスレイヤーダイアログで「オーバーラップ」をONにしトランジションを設定すると、時間を指定してレイヤーがフェードするように設定することもできます。

     

    たまに機械的にレイヤー並べたい場合があるのですが、毎回忘れちゃうのでメモとして記事にしました。

    レイヤー構成や使用してるエフェクトによりますが、タイムリマップを使用してループすると毎フレーム計算されますが、コンポジションを複数並べた場合は、コンポジション単位でキャッシュされるのでタイムリマップよりレンダリングが速くなる場合があります。

    Tips

    After Effects ベータ版のインストール方法

    After Effects のBeta版のインストールする場合は、Creative Cloud アプリから「ベータ版アプリケーション」のカテゴリを選択してインストールします。

     

    After Effectsのベータ版では、削除された「複数フレームレンダリング」に変わるマルチフレームレンダリングが搭載されており、レンダリングの高速化を試すことができます(対応エフェクト以外のエフェクトを使用すると速度が低下します)。AE 2021よりは複数のCPUを使用してレンダリングしてる気がします。

    ベータ版を試そうかと思ったときに、インストール方法に迷ったのでメモしておきます。

    Tips

    modoのキャラクターアニメーションのパフォーマンス

    modoのキャラクターアニメーションのパフォーマンスについて書いてみます。

     

    はじめに

    modoはキャラクターアニメーションのパフォーマンスが遅いという問題があります。この問題を改善するためmodoは段階的にパフォーマンス改善しています。

    modo 15.1になってMaya、3dsMax、LightWaveなど、他の3Dソフトで見かけるアニメーションパフォーマンスを改善する機能が一通り搭載されたように思います。

    ハイポリのサブディビジョンメッシュを滑らかにアニメーションできるような改善には至っていませんが、現時点でアニメーションを作成する場合に、どのような所に注意した方がよいのかまとめてみたいと思います。

     

    アニメーション再生が遅い原因は?

    modoのアニメーション再生が遅い原因でよく言われるのが「デフォーマの計算が遅い」です。
    リグ単体では早いのに、スケルトンにバインドした場合や、デフォーマを追加した場合にパフォーマンスが遅くなるので「デフォーマの計算が遅い」と言われていました。

    しかし、開発者の方の発言によるとmodoのデフォーマはマルチスレッドで計算しており、実際の原因はグラフィックボードに送信するためのデータ生成(メッシュの細分割、三角形のインデックスの生成、法線計算、位置の計算)がボトルネックになってるとのことです。
    この計算はデフォーマを使用していると毎フレーム発生するので、デフォーマ計算が遅いと思われていました。

    modo 13.1ではボトルネックを解消するためサーフェス計算が新しく書き直されましたが、サブディビジョンサーフェースやカーブなど、一部のポリゴンタイプはまだ作業中です。(この書き換えによってデフォーマキャッシュが使用できなくなったのが残念です)

     

    GPUを強化すれば早くなる?

    グラフィックボードに送信するためのデータ生成がボトルネックということは、強力なグラフィックボード(GPU)にすればアニメーションのパフォーマンスがよくなるのでしょうか?

    残念ながら劇的に速くなくことはありません。昔からmodoのビューポートパフォーマンスは、GPUよりCPUの速度の方が重要だと言われています。Windows10のタスクマネージャーを使用するとGPUの使用率を見ることができますが、modoはGPU使用率が低いことがわかります。

     

    もちろんGPUレンダラーのmPathや、NVIDIA OptiXデノイザなどGPUを使用する機能を使う場合はGPUの性能が重要になりますが、modoのアニメーション再生やビューポートパフォーマンスには大きな影響はありません。

    ゲームエンジン的なアプローチのアドバンストビューポートを使用するとGPU使用率が上がりますが、デフォルト表示に比べてアドバンストは描画速度が遅いのでアニメーション作成に使用するのはお勧めしません。

     

    恐らくボトルネックになるサーフェス計算がCPUでおこなわれているため、modoではGPUよりもCPUのクロック数が高い方がパフォーマンスへの影響が大きいのかなと思います。以上のことから、modoでアニメーションを速くするには以下の2つが重要になります。

    • クロック数の高いCPUを使用する。またはCPU使用率(計算量)を下げる
    • GPUに転送するデータ生成量を減らす

    modoに限らず3DCG全般で同じ事が言えますね。

     

    キャラクターアニメーションのパフォーマンスをよくする方法

    前置きが長くなりましたが、modoでキャラクターアニメーションの再生パフォーマンスを速くした場合は以下の点に注意するといいです。

    • サブディビジョンはOFFの状態でアニメーションを作成すると軽い
    • サブディビジョンを使用する場合はSub-D、またはOpenSubdivを使用する
    • 速いリグを使用する
    • 複数のキャラクターが登場するシーンは、シーンを分けて作る
    • メッシュに依存したリグは避ける
    • 「メッシュスムージング」「シェーダーツリーを使用」をOFFにする
    • ディスプレースメントやバンプを使用する場合は、レイヤーの「GL 表示」をOFFにする
    • プロキシメッシュや代理メッシュを使用する

     

    以降ではキャラクターアニメーションのパフォーマンステストについて書いてみます。

     

    アニメーションのパフォーマンステスト

    キャラクターアニメーションを速くする方法をまとめるにあたり、「ポリゴン数」「リグの速度」「ビューポートの表示」の設定を切り替えて、アニメーション再生のパフォーマンスをテストしました。

    自分のPC環境でファイルをダウンロードして検証できるように、modoで代表的なリグであるCharacterBoxとACSのサンプルシーンを使用しました。

    テスト環境

    modo 15.1v1

     

    フレームレート

    アニメーション再生のパフォーマンスはGLメーターで表示されるフレームレートを参考にします。

     

    リアルタイムで再生 OFF

    「リアルタイムで再生」はOFFにします。

    「リアルタイムで再生」はシーンのフレームレートを維持するように再生するオプションで、ONの場合はアニメーションの再生速度が低下した場合にフレームをスキップすることで、シーンのフレームレートを維持しようとします。

    OFFにするとシーンのフレームレートに関係なく、再生可能な最高のパフォーマンスでアニメーション再生します。アニメーションの再生速度が低下した場合でも毎フレーム描画するので、パフォーマンスを調べる場合は「リアルタイムで再生」をOFFにする必要があります。

     

    一口にキャラクターアニメーションと言っても「ポリゴン数」「リグの速度」「ビューポートの表示」など様々な要素で構成されています。
    個々の要素ごとに分解して何がどのくらいアニメーションに影響を与えているかテストしたので、キャラクターアニメーションの参考にしてください。

     

    デフォルト状態のパフォーマンス

    まずはmodoデフォルト状態のパフォーマンスです。

    モデルのポリゴン数を近くするため「Human.lxo」はサブディビジョンレベルを3から2に変更、「Bolo_Walk.lxo」は1から2に変更しました。
    ポリゴン数は「Human.lxo」が59,296トライアングル、「Bolo_Walk.lxo」が33,600トラインアングルです。

     

    画面キャプチャーしてるので、少しフレームレートが遅くなってます。また、記載してるフレームレートはおよその値です。

    85FPS。

    34FPS。

     

     

    ポリゴン数

    ポリゴン数の違いによるパフォーマンスをテストしました。

    ポリゴン数が多ければ当然遅くなるのは予想できますが、サブディビジョンサーフェースを使用した場合と使用しない場合、サブディビジョンの種類でどのような変化があるかテストしました。

    アニメーション用途ではSub-D、OpenSubdivが適していそうです。

    Sub-D、PSub、OpenSubdiv

    ゲームのようなリアルタイム向けモデル以外は、サブディビジョンサーフェースを使用する場合が多いのではないでしょうか。
    modoには3種類のサブディビジョンが搭載されていますが、各サブディビジョンでのアニメーション速度をテストしました。

    • Sub-D : modoオリジナルのサブディビジョン Tab
    • Catmull-Clark(通称PSub) :ピクサーからライセンスしているサブディビジョン Sift + Tab
    • OpenSubdiv : Catmull-Clarkのオープンソース版。GPU計算に対応ししている

    サブディビジョンサーフェースはポリゴンを細分割して、曲線的なモデルを作成する機能です。Sub-DとCatmull-Clarkでは分割アルゴリズムが異なるので、サブディビジョンレベルによってポリゴンの増加量が違います。

     

    Sub-D

    サブディビジョンレベル 0 (ケージ ON)

    79FPS。レベル 0よりレベル1の方がフレームレート出るので、レベル 0は最適化されていない等の問題がありそうです。

     

    33FPS。レベル 0からレベル5までフレームレートに大きく変化がないので、このような単純なモデルの場合サブディビジョンよりACSのリグ計算がフレームレートのボトルネックになっていると思われます。

     

    サブディビジョンレベル 1

    98FPS。

    33FPS。

    サブディビジョンレベル 2

    88FPS。

    32FPS。

     

    サブディビジョンレベル 3

    74FPS。

    31FPS。

     

    サブディビジョンレベル 4

    59FPS。

    29FPS。

     

    サブディビジョンレベル 5

    49FPS。

    28FPS。

     

    Catmull-Clark

    サブディビジョンレベル 0 (ケージ ON)

    69FPS。

    33FPS。

     

    サブディビジョンレベル 1

    74FPS。

    32FPS。

     

    サブディビジョンレベル 2

    39FPS。

    25FPS。

     

    サブディビジョンレベル 3

    18FPS。

    18FPS。

     

    サブディビジョンレベル 4

    7.4FPS。

    9.7FPS。

     

    サブディビジョンレベル 5

    2.3FPS。

    3.7FPS。

     

    OpenSubdiv 3.0

    演算には「マルチスレッド」を使用しています。「CPU」より「マルチスレッド」の方がわずかにパフォーマンスがよかったのですが、1CPUしか使用しないようです。

    本来はGPUが最もパフォーマンスがいいはずなのですが、PC環境のせいでGPUを設定するとmodoがクラッシュするため、GPUを使用してテストできませんでした。

     

    サブディビジョンレベル 0 (ケージ ON)

    80FPS。

    35FPS。

     

    サブディビジョンレベル 1

    104FPS。

    36FPS。

     

    サブディビジョンレベル 2

    83FPS。

    34FPS。

     

    サブディビジョンレベル 3

    46FPS。

    29FPS。

     

    サブディビジョンレベル 4

    17FPS。

    18FPS。

     

    サブディビジョンレベル 5

    4.8FPS。

    7FPS。

     

    サブディビジョン OFF

    サブディビジョン OFFの状態で、Catmull-Clarkを使用して細分割したモデルをアニメーションしました。

     

    サブディビジョンレベル 0 相当

    110FPS。

    34FPS。

     

    サブディビジョンレベル 1 相当

    69FPS。

    32FPS。

     

    サブディビジョンレベル 2  相当

    26FPS。

    19FPS。

     

    サブディビジョンレベル 3 相当

    7.3FPS。

    7.3FPS。

     

    サブディビジョンレベル 4 相当

    1.7FPS。

    1.9FPS。

     

    サブディビジョンレベル 5は重すぎるので省略です。フレームレートのテストを表にすると以下のようになります。

     

    ポリゴン数増加のテスト結果

    サブディビジョンレベルによるポリゴン分割数

    サブディビジョンをONにすると、元のポリゴン数がサブディビジョンレベルに応じて細分割されます。サブディビジョンレベルを3以上にした場合、Sub-DよりCatmull-Clarkのほうがポリゴン数が多くなる。

    Sub-D
    Catmull-Clark
    サブディビジョンレベル 1
    4 倍
    4 倍
    サブディビジョンレベル 2
    16 倍
    16 倍
    サブディビジョンレベル 3
    36 倍
    64倍
    サブディビジョンレベル 4
    64 倍
    246倍
    サブディビジョンレベル 5
    100 倍
    1024倍

     

    Human.lxoのフレームレート

    サブディビなし
    Sub-D
    Catmull-Clark
    OpenSubdiv
    サブディビジョンレベル 0
    110 FPS
    79 FPS
    69 FPS
    80 FPS
    サブディビジョンレベル 1
    69 FPS
    98 FPS
    74 FPS
    104 FPS
    サブディビジョンレベル 2
    26 FPS
    88 FPS
    39 FPS
    83 FPS
    サブディビジョンレベル 3
    7.3 FPS
    74 FPS
    18 FPS
    46 FPS
    サブディビジョンレベル 4
    1.7 FPS
    59 FPS
    7.4 FPS
    17 FPS
    サブディビジョンレベル 5
    49 FPS
    2.3 FPS
    4.8 FPS

    Bolo_Walk.lxoのフレームレート

    サブディビなし
    Sub-D
    Catmull-Clark
    OpenSubdiv
    サブディビジョンレベル 0
    34 FPS
    33 FPS
    33 FPS
    35 FPS
    サブディビジョンレベル 1
    32 FPS
    33 FPS
    32 FPS
    36 FPS
    サブディビジョンレベル 2
    19 FPS
    32 FPS
    25 FPS
    34 FPS
    サブディビジョンレベル 3
    7.3 FPS
    31 FPS
    18 FPS
    29 FPS
    サブディビジョンレベル 4
    1.9 FPS
    29 FPS
    9.7 FPS
    18 FPS
    サブディビジョンレベル 5
    28 FPS
    3.7 FPS
    7 FPS

     

    サブディビジョンレベルを上げれば当然パフォーマンスが低下する結果になりましたが、いくつか興味深いことがわかりました。

     

    OpenSubdivとSub-Dのパフォーマンスがよい

    今回テストしたモデルではOpenSubdivとSub-Dのパフォーマンスがよいようです。

    modoにはOpenSubdivがオープンソースとして公開される前に、ピクサーから直接ライセンスしたCatmull-Clarkを独自に実装していました。このCatmull-ClarkはOpenSubdivよりトポロジー編集が速い物だとのことですが、やはりアニメーションの再生では、OpenSubdivの方が高速なようです。

    Sub-Dも決して遅くないので、アニメーションではOpenSubdivかSub-Dを使用するのがよさそうです。ただしOpenSubdivは少し動作が不安定でクラッシュしやすいように感じました。

     

    サブディビジョンレベル 0より、レベル1の方がフレームレートが高い

    modo 15.1でサブディビジョンレベルを0に設定すると「ケージ」が有効になる機能が追加されましたが、サブディビジョンレベル 0より、レベル1の方がフレームレートが高いです。

    バグなのか最適化が進んでないためか原因はわかりませんが、パフォーマンスを重視する場合はレベル 0を使用せずに、TabでサブディビジョンをOFFにした方がよいです。

     

    サブディビジョンはフリーズしない方がよい

    modoはTabで非破壊的にサブディビジョンを適用することができますが、サブディビジョンをフリーズするよりも、Tabで非破壊サブディビジョンを使用した状態の方がパフォーマンスがよいようです。

    modo 13.1でサーフェス計算コードの書き直しがおこなわれ、場合によっては3倍高速化しているとのことです。サブディビジョンよりもサブディビジョンをフリーズした方がパフォーマンスがよくなる場合があるかと思いましたが、非破壊サブディビジョンを使用した方がいいようです。

     

    サブディビジョンレベルを上げてもそれほど遅くならない

    サブディビジョンレベルを上げるとポリゴン数は指数関数的に増えますが、FPSは思ったより落ちないようです。

     

    リグの速度

    キャラクターアニメーションでは、使用するリグの計算速度も重要です。

    アニメーション作成では何度も再生しながらタイミングを調整します。どんなに便利な自動制御が組み込まれたとしても、リアルタイムで再生できないリグには価値がありません。静止画の場合でも動作が速いほうがトライアンドエラーがしやすくなるので、リグの速度は重要です。

    ここではCharacterBoxとACSを使用してリグの速度を測る方法を紹介したいと思います。リグの速度は全てのアイテムを非表示にするとわかります。

     

    リグなしの速度

    まずはリグをベイクした状態の速度を見てみます。CharacterBoxもACSもリグをmodo標準のスケルトンにベイクすることができます。
    ここではフレームレートの変化がわかりやすいように、サブディビジョンレベル2でフリーズしたメッシュを使用しました。

    Human.lxo

    • メッシュとスケルトン表示 25FPS
    • スケルトンだけ表示 420FPS
    • 全て非表示 590FPS

     

    Bolo_Walk.lxo

    • メッシュとリグ表示 28FPS
    • スケルトンだけ表示 250FPS
    • 全て非表示 490FPS

     

    2つのシーンでフレームレートに差が出てるのは、データの違いによる物です。
    Human.lxoはポリゴン数が多いのでメッシュを表示してると遅い。Bolo_Walk.lxoは指にスケルトンが仕込まれてるので、スケルトン表示のとき遅い。ということだと思います。

     

    リグの速度

    リグが動いてる状態でメッシュやリグ、コントローラーを全て非表示にするとリグの速度がわかります。

    • メッシュとリグ表示 23FPS
    • リグだけ表示 160FPS
    • 全て非表示 200FPS

     

    Human.lxo に指を追加

    • メッシュとリグ表示 22FPS
    • リグだけ表示 86FPS
    • 全て非表示 114FPS

    • メッシュとリグ表示 19FPS
    • リグだけ表示 44FPS
    • 全て非表示 49FPS

     

    CharacterBoxは指を追加すると114FPS。ACSはおよそ49FPSがリグ速度の上限だとわかります。
    リグ機能が異なるのでリグその物の速度を比べることは難しいですが、CharacterBoxやACS3は必用に応じてリグを追加できるので、リグのパフォーマンスを制御しやすいかもしれません。

     

    デフォーマの計算速度

    メッシュを非表示にしただけだと恐らくデフォーマの計算が走った状態ですが、メッシュを非表示にした場合と大きな違いはありませんでした。もしかしたらメッシュを非表示にするとデフォーマ計算を省くなど、最適化されてるのかもしれません。

    • デフォーマON 20FPS
    • デフォーマOFF 150FPS
    • リグだけ表示 160FPS(デフォーマONでメッシュ非表示にした場合とほぼ同じ)
    • 全て非表示 200FPS

     

    またメッシュを参照するコンストレイントを使用していると、メッシュを非表示にしてもパフォーマンスが変わらない場合があります。

    例えば下の画像はLocatorをポリゴンコンストレイントと、位置コンストレイントを使用したものです。ポリゴンコンストレイントを使用していると、メッシュを非表示にしてもフレームレートが遅いままです。Locatorを非表示にするとフレームレートが上がります。

    リグとメッシュに依存関係がある場合は、フレームレートがメッシュの表示速度の影響を受けるようです。

     

    ちなみに、CharacterBoxに自動制御を組み込んでカスタムした自作リグの場合、補助スケルトンを表示した状態だと14.5FPSでした。

    このリグはアニメーション用途ではなくて、どこまで自動制御組み込めるのか色々テストしていた物なのです。IK計算後の角度を使用してスケルトンを自動制御してるのですが、IKのようにワールド座標で計算された角度に連動してスケルトンを制御しようとすると、徐々にパフォーマンスが低下するようです。1関節につき5~6アイテム動いてるので、数が多いというのもあります。

     

     

     

    複数リグの速度

    シーンに複数のリグがある場合の速度をテストしました。

    modoはデフォーマなどマルチスレッドに対応してる機能がありますが、チャンネルモディファイヤは並列処理に対応していません。シーンに複数のリグがある場合、どのようになるのかテストしました。

    やはりリグの並列処理に対応していないため、数に応じて速度が低下しました。

     

    Human.lxoは指を追加して実際に使用するリグ構造に近い状態にしました。

    リグ1体
    • メッシュとリグ表示 59FPS
    • リグだけ表示 86FPS
    • 全て非表示 114FPS

    • メッシュとリグ表示 35FPS
    • リグだけ表示 45FPS
    • 全て非表示 49FPS

     

    リグ2体
    • メッシュとリグ表示 31FPS
    • リグだけ表示 46FPS
    • 全て非表示 65FPS

    • メッシュとリグ表示 17FPS
    • リグだけ表示 22FPS
    • 全て非表示 24FPS

     

    リグ3体
    • メッシュとリグ表示 20FPS
    • リグだけ表示 31FPS
    • 全て非表示 43FPS

    • メッシュとリグ表示 11FPS
    • リグだけ表示 14FPS
    • 全て非表示 15FPS

     

    リグ4体
    • メッシュとリグ表示 15FPS
    • リグだけ表示 23FPS
    • 全て非表示 32FPS

    • メッシュとリグ表示 8FPS
    • リグだけ表示 10FPS
    • 全て非表示 11FPS

     

    リグ5体
    • メッシュとリグ表示 12FPS
    • リグだけ表示 18FPS
    • 全て非表示 26FPS

    • メッシュとリグ表示 6.8FPS
    • リグだけ表示 9FPS
    • 全て非表示 9.6FPS

     

    複数リグのテスト結果

    Human.lxoのフレームレート

    メッシュとリグ
    リグ
    全非表示
    リグ1体
    59 FPS
    86 FPS
    114 FPS
    リグ2体
    31 FPS
    46 FPS
    65 FPS
    リグ3体
    20 FPS
    31 FPS
    43 FPS
    リグ4体
    15 FPS
    23 FPS
    32 FPS
    リグ5体
    12 FPS
    18 FPS
    26 FPS

     

    Bolo_Walk.lxoのフレームレート

    メッシュとリグ
    リグ
    全非表示
    リグ1体
    35 FPS
    45 FPS
    49 FPS
    リグ2体
    17 FPS
    22 FPS
    24 FPS
    リグ3体
    11 FPS
    14 FPS
    15 FPS
    リグ4体
    8 FPS
    10 FPS
    11 FPS
    リグ5体
    6.8 FPS
    9 FPS
    9.6 FPS

     

    チャンネルモディファイヤは並列処理に対応していないので、リグの数に応じてフレームレートが下がることがわかりました。

    CharacterBoxはリグのみ表示した場合と、全て非表示にした場合のフレームレートに差があります。CharacterBoxはスケルトンにプロシージャルメッシュを使用してるせいなのか、リグのみ表示してる場合に描画コストが発生してるようです。
    逆にACSはフレームレートに差がないため、ロケータのカスタムシェイプ表示はそれほど描画速度に影響がないことがわかります。

    CharacterBoxはシーンに3体リグを配置しても30FPSを維持できそうですが、ACSはシーンに2体配置するとリアルタイムでのアニメーション再生が難しくなりそうです。ACS3ならもっと軽くなってるかも知れません。リグは好みによる部分が大きいので、自作リグなどを含めて速度は気にしたいところです。

     

    リグをベイクした状態だと5体でも30FPS出ます。modoでも工夫次第ではアイドルアニメのダンスシーンを処理できるかもしれませんが、普通に別々のシーンでアニメーションを作成した後に、シーンを合成するのがスマートだと思います。

     

    ビューポートの設定

    ビューポートのスタイルやオプションを変更してアニメーションの再生パフォーマンスをテストしました。フレームレートが高い方がパフォーマンスの変化がわかりやすいのでHuman.lxoを使用しています。

    パフォーマンス

    ビューポートプロパティの表示属性タブには「パフォーマンス」というパフォーマンスに影響する表示をOFFにするオプションがまとまってます。

    データによりますが、これらのオプションをOFFにするとビューポートのパフォーマンスをよくすることができます。

     

    ファー

    ファー マテリアルのガイドをOFFにすることができます。

    • ファー ON 21FPS
    • ファー OFF 86FPS

     

    ディスプレースメント

    ディスプレースメントマップをOFFにすることができます。複数のテクスチャを一時的にOFFにしたい場合に有効なオプションです。

    • レイヤー OFF 86FPS
    • ディスプレースメント ON 16FPS
    • ディスプレースメント OFF 43FPS

     

    実はこの「ディスプレースメント」や、初期設定の「GLでのディスプレースメント有効」をOFFにしてもあまり速くなりません。ビューポートでディスプレースメントを表示しなくていい場合は。テクスチャーレイヤーの「GL 表示」をOFFにする方がパフォーマンスが上がります。

     

    メッシュスムージング

    ポリゴンのスムージング計算を無効にしてフラットシェーディングにします。ポリゴン数の多いモデルで効果があります。

    サブディビジョンを適用したメッシュには効果がありません。modoのサブディビジョンは細分割時に自動的にスムージングを適用するので、サブディビジョンを使用した段階でスムージング計算が走ります。

    画像はサブディビジョンレベル 3でフリーズしたモデルです。

    • メッシュスムージング ON 5.9FPS
    • メッシュスムージング OFF 7FPS

     

     

    以前、自作のモデルでメッシュスムージングのオプションが凄く効果的だった記憶があるのですが、どんな条件だったか出てこないので、思い出したら追記します。

     

    シェーダーツリーを使用

    シェーダーツリーの計算を省略します。テクスチャの多い複雑なモデルで効果があります。

    マテリアル数が少なく、テクスチャが使用されてないモデルでは効果が薄いです。

    • シェーダーツリーを使用 ON 85FPS
    • シェーダーツリーを使用 OFF 86FPS

     

    modoのシェーダーツリーはとても便利です。複数のマテリアルに同じテクスチャを一度に適用できたりマテリアルのオーバーライドが簡単で、階層構造で管理するマテリアルシステムの完成形というくらい素晴らしい機能なのですが、modoのパフォーマンスが悪い原因として上げられることが多いです。

    今回調べてみたら大きな速度低下はありませんでしたが、いくつか気になる点をまとめてみました。

     

    テクスチャを使うと速度が低下する

    あたり前ですがテクスチャを使うと少しフレームレートが低下します。ディスプレースメントを使用すると特に速度が低下しますが、バンプもそれなりに速度低下します。

    ディスプレースメントとバンプ以外は、どのレイヤーエフェクトを使用しても低下率はだいたい同じです。「ディゾルブ」のようにビューポートで効果が確認できないものや、「ポーリュームサンプル密度」のようにレンダリングでも効果のないエフェクトでも、一律フレームレートが低下します。

    テクスチャを一度でもビューポートに表示するとそれ以降は若干パフォーマンスが低下し、シーンを読み直すと改善します。

    ディスプレースメントとバンプを表示すると、それ以降ディスプレースメントやバンプ以外のテクスチャに切り替えてもフレームレートが落ちたままになります。

    • レイヤーなし 85FPS
    • 一度テクスチャを表示した後レイヤーをOFF 67 FPS
    • ディフューズ 65FPS
    • スペキュラ色 65FPS
    • バンプ  40FPS
    • ディゾルブ 41FPS  (バンプを表示しない場合は65FPS)
    • ボリュームサンプル密度 41FPS (バンプを表示しない場合は65FPS)

     

    テクスチャ解像度を変更しても速度は一定

    初期設定にはビューポートの「テクスチャ解像度」の設定があります。テクスチャ解像度を変更しても速度は低下しませんでした。テクスチャを多く使用してるシーンでは違いが出るかもしれません。

    • テクスチャ解像度 64 66FPS
    • テクスチャ解像度 2048 66FPS
    • テクスチャ解像度 4096 66FPS

     

    複数のテクスチャを使用しても速度は一定

    複数のテクスチャを適用しても速度は低下しませんでした。

     

    テクスチャを選択すると速度が低下する

    シェーダーツリーでテクスチャを選択するとわずかに速度が低下します。ドラッグアンドドロップのような操作は更に速度低下します。ディゾルブなど一部のエフェクトは選択したテクスチャをビューポートに表示するので何か処理が走ってるのかも。

    特に必要のない場合は、シェーダーツリーでは選択を解除した方が少しパフォーマンスがよくなるかもしれません。

    • 非選択 85FPS
    • 選択 77FPS

     

    今回テストした範囲では大きなパフォーマンス低下は確認できませんでした。テクスチャ表示やディスプレイスやバンプの速度が妥当なのかわかりませんが、表示する要素が増えると相応に処理が発生するのは理解できます。

    シェーダーツリーは機能の特性上、少しの変更でもツリー全体を更新する必用があるらしく、特にマテリアルの数が多い場合にパフォーマンスを低下させることが多い言われています。
    Vrayのようにビューポートを更新しないマテリアルはパフォーマンスがいいようなので、アニメーションで使用する場合は「GL 表示」をOFFにして必用なレイヤーだけビューポートに表示する使い方が適してそうです。

     

    表示スタイル

    ビューポートの表示スタイルを変更して、速度に変化があるかテストしました。表示スタイルの違いがパフォーマンスに影響することはないようです。

     

    アドバンスト表示は遅いですが、他の表示スタイルの速度は大きく変わりませんでした。メッシュがビュー全体を覆うようにズームした場合は、ワイヤーフレームの表示がわずかに速いようです。

     

    ワイヤーフレームオーバーレイ

    modoはメッシュにワイヤーフレームがうっすらと表示されています。他にもビューポートで表示する様々な表示を切り替えたらパフォーマンスに影響するかテストしました。

    昔使ってたソフトではワイヤーフレーム表示を使うと遅くなることがあったのですが、modoでは特に問題になることはないようです。

    サブディビジョン2でフリーズしたメッシュ。

     

    アニメーションを速くする工夫

    ここまではmodoの機能を使用したパフォーマンス改善をテストしました。テスト結果からよりアニメーションを速くするための工夫を紹介します。

    プロキシメッシュ

    メッシュを関節ごとに個別のアイテムに分割して、スケルトンにダイナミックペアレントする方法です。

    サブディビジョンレベル 4でフリーズしたメッシュ(948,736ポリゴン)だとフレームレートが1.6FPSしかでません。同じポリゴン数でも関節ごと個別のアイテムに分割して、スケルトンにペアレントすることで高速にアニメーション再生することができます。

    • メッシュ 1.6FPS
    • リグのみ 120FPS
    • プロキシメッシュ  100FPS

     

    プロキシメッシュを使用する方法はPCスペックの低かった時代からある定番ですが効果が高いです。この方法の弱点は以下の通り。

    • メッシュを用意するのが若干めんどくさい
    • めり込みなど細かな変形の確認がめんどくさい
    • モーフを使用したアニメーションの確認に弱い

    逆にキャラクターアニメーションではなく、メカニカルな物ならパフォーマンスを気にすることなくアニメーション生成できそうです。

    プロキシメッシュを簡単に作成する機能があれば便利なんですけどね。ACS3にはプロキシメッシュを作る機能が搭載されてるようです。

     

    保留される評価の代理メッシュ

    modo 15.1で追加された保留される評価の「代理メッシュ」機能を使用する方法です。この機能はメッシュを複製してサブディビジョンをOFFにするだけで、簡単に代理メッシュを設定できるのでお勧めです。

    画像では速度差がわかるようにサブディビジョンレベル1でフリーズしたメッシュにサブディビジョンを適用したモデルを使用しました。
    そのままアニメーションすると32FPSくらいですが、アイテムを複製してサブディビジョンをOFFにしたアイテムを「代理メッシュ」に指定すると65FPSくらいの速度になります。

     

    代理メッシュがわかりやすいように色を変えてみました。タイムラインスクラブやアイテム編集中だけ軽いメッシュに置き換わります。切り替わるタイミングで若干ラグが発生しますすが、ユニークな機能で再生パフォーマンスを改善する効果が高いと思います。
    逆に編集中の操作を軽くしたい場合は、15.1で追加されたメッシュオペレーターの「評価の保留」の効果が高いです。

     

    デフォーマを適用したメッシュを使用するとパフォーマンスが落ちてしまうという根本的な問題は解決することはできませんが、サブディビジョンを使用しない描画の速い代理メッシュを使用することで快適にアニメーションを作成することができるようになます。

    プロキシメッシュ並みの早さすることはできませんが、モーフやデフォーマの影響も確認する事ができるので便利です。

     

    複数アイテムにわける

    Human.lxoは1オブジェクト1メッシュのモデルです。メッシュを複数のアイテムに分けてパフォーマンスを確認しました。

    サブディビジョンレベル3でフリーズしたメッシュで、マッスルやモーフデフォーマを削除した状態のモデルです。

    デフォルトは10FPS。

     

    メッシュを頭、胸、腕、腰、脚の5アイテムに分割した場合。正規化フォルダは1つで、12.3FPS。

     

    メッシュを5アイテムに分割し、更に正規化フォルダをアイテムごとに5つに分けた場合、11.9FPS。

     

    1アイテムに全てのメッシュをまとめるより、適度にアイテムを分けた方がわずかにパフォーマンスがいいようです。デフォーマが並列処理されるぶんだけ、速度が上がるのかもしれません。

    アイテムごとに正規化フォルダをわけてインフルエンスを入れた場合は、わずかにパフォーマンスが落ちました。正規化処理が複数発生するからでしょうか。

    アイテムを分けた方がパフォーマンスがいいのはmodoに限らず、どの3Dソフトで同じですね。

     

    ソース制限

    正規化フォルダには1頂点に影響するウェイト数を制限するソース制限機能があります。この機能を使用した場合のパフォーマンスをテストしました。

    ソース制限OFF、11.4FPS。

     

    ソース制限3、10.3FPS。

     

    ソース制限1、10.2FPS。

     

    ソース制限はゲームエンジンの仕様に合わせるための機能なので、計算が速くなるイメージでしたが、実際にはわずかにパフォーマンスが下がるようです。

    画像では複数の正規化フォルダを使用してテストしていますが、1メッシュ1正規化フォルダの場合でもわずかに遅くなります。しきい値を大きく設定しても速度に大きな変化がないので、ソース制限の計算コストぶんだけパフォーマンスに影響があるのかもしれません。

     

    まとめ

    modoでキャラクターアニメーションを作る場合は、プロキシメッシュか代理メッシュを使うのが最も効果があることがわかりました。

    今回いろいろテストしたことで、これまで漠然と使ってたオプションが、どのようにパフォーマンスに影響しているのかわかりました。
    modoのアニメーション機能はわりと使いやすくて高機能です。デフォーマを使用したメッシュのアニメーションパフォーマンスが低い問題は、ぜひ対処して欲しいですね。そういった意味では「代理メッシュ」はmodoの問題点をフォローするいい機能追加だったように思います。

    本当は自作のモデルで代理メッシュをテストしたかったのですが、15.1でリレーションシップにバグが発生していてファイルを開くことができないので試せませんでした。バグが修正されたらテストしてみたいと思います。

    もっと複雑なモデルだとパフォーマンスを下げる要因がより複雑になると思います。もしパフォーマンスの問題に遭遇したら、この記事で書いたことが何らかのヒントになったなら嬉しいです。