Modo

Tips

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

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

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

 

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

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

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

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

 

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

CG News

Modo 15.2 リリース

Modo 15.2がリリースされました。

https://community.foundry.com/discuss/topic/158167/modo-15-2-is-now-available
https://learn.foundry.com/modo/content/help/pages/welcome_modo/whats_new.html

メッシュフュージョンのチュートリアルも公開されました。
https://learn.foundry.com/course/6123/view/modo-15-2-fast-non-destructive-modeling-with-meshfusion-in-modo

 

 

アセンブリプリセットでプリセットを簡単に共有

プリセットはパッケージ化され、画像などの関連コンテンツがプリセットパッケージに含まれるようになりました。プリセットを他のアーティストに渡す際に、必要なコンテンツが揃っているかどうかを確認することができます。

新しいプリセットシステムでは、シーン内にアセンブリが自動的に作成され、プリセットとアセンブリの関係がより密接になりました。
アセンブリはスケマティックアセンブリのすべての要素を公開する必要がなくなりました。スタックノードとスケマティックには、スケマティックにいながらにして、より多くの作業を行うために必要な要素が含まれています。

 

ダイレクトモデリングとプロシージャルモデリング

プリミティブ・スライス

カーブはモデリングに不可欠な要素です。プリミティブスライスは、Modoのカーブモデリング機能をさらに向上させます。
プリミティブシェイプをジオメトリにスライスすることができ、スライスエフェクタを使ってプロシージャルツールのバリエーションを活用する場合には、深さを制御してブーリアンエフェクトを生成することもできます。

スライスエフェクター

 

エッジに頂点を追加

Edge Subdivideは、選択された各エッジを複数のエッジに分割するだけで、エッジに沿った頂点の追加が容易になります。これはトポロジーを素早く修正・改良するのに非常に便利です。

 

ウェイト付きエッジを使ってMeshFusionで正確なベベルを作成

15.0ではメッシュフュージョンのワークフローが全面的に見直されました。15.2ではさらにフュージョンの選択モードを廃止しました。変更したい要素を選択するだけで、必要な情報が得られるようになりました。

 

Geodesic Distance Modifierを使って複雑なパターンを作成

3Dサーフェス上に2Dデザインをプロシージャルに生成することは、デザイナーにとって非常に価値のあることです。Geodesic Distance Modifierを使用すると、2点間の距離を求め、サーフェス上の2点間のパスをトレースすることができます。これにより、複雑なパターンの生成が可能となり、エキサイティングなプロシージャルモデリングの結果を得ることができます。

 

頂点法線の設定と最大法線を使ったメッシュの調整

頂点法線と頂点マップのコントロールは、3D全般、特にリアルタイムレンダラーにとって非常に重要な部分です。最大法線のオプションは、マテリアル スムージング プロパティの一部になりました。カラーツールとRGBの設定ノードに、不連続値のオプションが追加され、選択範囲の境界を越えたカラーブレンドがなくなりました。最後に、Set Vertex Normals MeshOpが追加され、プロシージャルツールセットで可能なことがさらに広がりました。

 

選択スタックを使ってスケマティックビューポートを整理

ModoのOrder Of Operationsシステムは非常に強力です。しかし、スケマティックビューポートでMeshOpやSelectionOpの順番を理解するのは難しいものです。15.1でMeshOp Stackノードが追加されました。15.2では、選択操作にもこの機能が追加され、スタックがノードグラフとどのように関連しているかをアーティストにわかりやすく伝えられるようになりました。

 

レンダリング

mPathを使ってレンダリング時にブーリアン効果を作る

mPathはFoundryの強力な新しいハイブリッド・パストレース・レンダラです。15.2では、Render booleansを追加しました。これにより製品やグラフィックのビジュアライゼーションのための断面図の作成が非常に簡単になりました。

 

機能強化

スクリプトエディターのクオリティ・オブ・ライフの向上

リリースのたびに既存の機能やワークフローに意味のある改良を加えようとしています。スクリプトエディタとスケマティックビューポートには、スクリプト作成とナビゲーションをより快適にするための多くの改良が加えられています。「インスタンスをレプリカに変換」では、インスタンスとレプリカの切り替えが容易になりました。

 

スケマティックビューポートの強化による生産性の向上

 

AVPプログレッシブモードでレンダリング品質の高いプレイブラストを作成

Playblast Advanced Viewport Progressiveノードでは、ビューポートのプレイブラストを作成する際に、プログレッシブ・アンチエイリアシングの利点を活かすことができます。

 

インポートしたテクスチャをPBRワークフロー用に素早く設定

PBR ローダーは、インポートされた PBR テクスチャを正しいポリゴンタグを持つグループに自動的に追加するようになりました。

 


今回はプリミティブスライス、エッジ分割、スケマティックの改善がよさそうです。

噂によるとModo 13から取り組んでいた技術的負債に関する作業が、目標の80%〜90%に達したらしいです。CコードがC ++に置き換えられているとのこと、これで言語が古く開発者が見つからない問題も解決するのかしら?以前のように開発加速してくれたら嬉しいですね。

また、グレッグさんがModoのプロダクトマネージャーに就任したようです。Foundry はユーザーとのコミュニケーションが上手く行ってないんじゃないかとの意見に「来年ロードマップや『modoの状態』について話し合うことができるかもしれません」とのこと、「次の数回のBrewO時にぜひご注目ください。ModoとFoundry全般の将来について、さらにいくつかの発表があります」と言うことで、何かビジョンが共有されるのかが気になりますね。

CG News

HDR Light Studio - Xenon Drop 4

HDR Light Studio - Xenon Drop 4が公開されています。ブラックフライデーセール中でStudio Indie、Pro、Automotiveが15%OFFのようです。HDRモーションブラーが面白いですね。

https://www.lightmap.co.uk/blog/hdr-light-studio-xenon-drop-4/

 

進化したモーションブラー

HDR Light Studio - Xenon Drop 3では、HDRマップ用に使いやすいモーションブラーフィルターを導入しました。今回、最も要求の厳しいユーザーのニーズに応えるために、新たに高度なモーションブラーフィルターを追加し、追加のモーションブラーコントロールを提供しています。これにより、よりリアルでクリエイティブなモーションエフェクトが可能になりました。

カーブとチルト

モーションパスを任意の方向にカーブさせることができます。角を曲がるときのモーションブラーを再現するのに最適です。

 

ノイズプロファイル

パスにノイズプロファイルを追加することができます。ロードノイズの効果を再現したり、クリエイティブなライトトレイル効果を生み出すのに最適です。

 

深度画像

モーションブラーの量は、ロードされた画像の値によってピクセルごとにスケーリングすることができます。ユーザーが画像をペイントすることで、マップのどこにどれだけのモーションブラーをかけるかをコントロールすることができます。

 

Advanced Motion Blurは、自動車イメージの正確な反射や照明を作成するのに最適です。

 

新しい「高度なモーションブラー」フィルターの使い方は、以下のチュートリアルビデオをご覧ください。

 

NVIDIA Omniverseコネクション

NVIDIA Omniverse用の新しいHDR Light Studio拡張機能をリリースします。アーティストが使いやすいリアルタイム照明ツールキットを、3D制作パイプラインのためのNVIDIAの強力なマルチGPUリアルタイムシミュレーションおよびコラボレーションプラットフォームのユーザーが利用できるようになります。

この拡張機能は、HDR Light StudioとOmniverseの間にライブリンクを作成し、自動車、ビジュアライゼーション、エンターテイメントのアーティストが、正確でフォトリアリスティックな照明セットアップをより迅速に、直感的に、創造的に作成できるようにします。

HDR Light Studioライティングソフトウェアは、NVIDIAのアーティストが10年以上前からワークフローに欠かせないツールとして使用しています。その間、機能や互換性が向上し、マーケティングや広告イメージを制作するプロの3Dアーティストの間で高い評価を得てきました」と、NVIDIAのOmniverse開発プラットフォーム担当副社長のリチャード・ケリスは述べています。「この新しいOmniverse互換性リリースにより、我々のすべてのユーザーは、彼らのビジュアライゼーションを真に際立たせる直感的で高品質な照明ツールを利用することができます」。

新しいOmniverseの接続は、HDR Light Studio - Automotiveに含まれています。

 

アップデートされたBlender Connection

Blender Connection が更新され、Octane と RenderMan レンダラーのサポートが追加されました。
このリリースでは、Blender 2.93.2 以降のバージョンでのシーンエクスポートのバグも修正されています。

 

www.lauktien-friends.de のデジタルアーティストである Rüdiger Lauktien 氏は、新しい Blender Connection と Octane のベータテストを行いました。

「HDR Light StudioとOctaneを使ったBlenderでの作業は非常に中毒性があります。Cyclesと比較して、Octaneのレンダリングのリアルさと速さが気に入っています。しかし、Octaneはネイティブライトをサポートしていないため、ライティングのプロセスには時間がかかりました。Octane用のエミッシブメッシュを手作業で設定する必要がありました」。とRüdiger氏は言います。 「HDR Light Studioを使えば、製品撮影のための完璧な照明設定を簡単かつ迅速に行うことができます。必要な場所に正確にOctaneのライトを作成して配置し、製品のレンダリングを輝かせることができます」と述べています。

 

Cinema 4D R25コネクション

Cinema 4D R25 Connectionは、HDR Light Studio -Xenon Drop 4とともにリリースされ、Cinema 4D Physical Render、Redshift、Octane、Arnold、V-Ray 5、Coronaに対応しています。

 

Houdini 19 Connection - Coming Soon

Houdini 19 Connectionは、現在社内での品質テストを完了しており、数週間以内にリリースされる予定です。

リリースノートと互換性

完全なリリースノートは、HDR Light Studio - Xenon Drop 4のこちらをご覧ください。

CG News

Pushing Points MOP Booleans 2.1 for MODO

Pushing Points MOP Booleans Kitの2.1がリリースされました。2.0以降は動作環境がmodo 15.1以降です。バージョン1を購入してるユーザーは無料アップデートとのこと。価格は$ 50。

MOP Booleans Kitはmodo標準のプロシージャルブーリアンの組み立て簡単にセットアップするスクリプトと、アセットを組み合わせたキットです。2.0ではMeshFusionライクなボタンのUIが追加されて使い勝手がよくなってます。自分でプロシージャルモデリグをセットアップするの面倒くさい人には便利かもしれません。

https://vaughan3d.gumroad.com/l/WWlrn

 

Pushing Points MOP Booleans Kit version 2.0リリース

MOP Booleans Kitは、複雑なブーリアン演算を行う際の課題を解決するために設計されたMODOアドオンで、非破壊的なワークフローにより、非常に詳細なメッシュを簡単に作成することができます。

このキットのバージョン2.0がリリースされ、新しいUIベースのワークフローを提供します。これは、以前のバージョンのキットを購入された方には無料で提供されるアップデートです。

Gumroadアカウントにログインして最新版のキットにアクセスし、旧キットを新キットに置き換えてModoを再起動するだけです。

 

重要なお知らせ

バージョン1.5とバージョン2.0が正しく動作するには、Modoバージョン15.1が必要です。以前のビルドのModoを使用している場合は、これまで使用していたMOP Booleanのビルドを引き続き使用してください。

MOP Booleans v2.0で強化されたブール機能を利用するには、Modoの最新ビルドにアップグレードする必要があります。

 

modo 14.2ではブーリアンの高速化、15.0では複数のアイランドで構成された1メッシュでブーリアンができるようになりました。

 

modo 15.1では複数アイランドのブーリアンがさらに改善されて安定した物になりました。Pushing Points MOP Booleansではmodo 15.1のブーリアンを使用して、手軽にプロシージャルブーリアンを使用することができるようになってます。

 

15.1で追加されたスタックノードを使用して、ブーリアンする対象を管理できるようになったようです。

 

Pushing Points MOP Booleans Kit バージョン2.1リリース

プロシージャルメッシュやインスタンスメッシュを扱うことができるようになりました。

 

プロシージャルメッシュを使用したブーリアン。

 

インスタンスを使用したブーリアンの対応。

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でリレーションシップにバグが発生していてファイルを開くことができないので試せませんでした。バグが修正されたらテストしてみたいと思います。

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

Tips

modoのメッシュオペレーターのアセンブリ保存

modoのメッシュオペレーターをアセンブリとして保存する方法について書いてみます。

modoはスケマティックで作成した処理をアセンブリとして保存して、他のシーンで簡単に使い回すことができる仕組みがあります。

プロシージャルモデリングに使用するメッシュオペレーターもアセンブリとして保存して使い回すことができます。しかし、メッシュオペレーターをアセンブリとして保存すると、メッシュオペレーターの順番が変わってしまう問題があります。

サンプルファイル

 

例えばメッシュをマージして、Polygon Bevel、Edge Bevel、Transform Deformerの順番でメッシュを編集するアセンブリを作ったとします。

 

上の画像のような状態で「アセンブリプリセットを保存」し、保存したアセンブリを読み込むと、メッシュオペレーターリストの順番が変わってしまいます。

また、「アセンブリプリセットを保存」する場合はメッシュの接続を切った状態で保存しないと、中身が空になることがあるので注意が必要です。

 

メッシュオペレーターの順番を維持した状態でアセンブリを保存するには、デフォームフォルダを作成して、アセンブリにデフォームフォルダを入れた状態でアセンブリ保存する必用があります。

 

デフォームフォルダを含んだアセンブリでは、メッシュオペレーターの順番が維持されているのが確認できます。

 

 

Modo15.1ではメッシュオペレータースタックノードが追加されたので、スタックノードを使用してメッシュオペレーターの順番を維持することができるようになりました。

あまりメッシュオペレーターのアセンブリを作ることがないのですが、先日この問題にははまりました。こういう初見殺しの問題は早く修正して欲しいですね。

 

参考

https://support.foundry.com/hc/en-us/articles/115001763550-Q100346-How-to-retain-the-order-of-a-procedural-layer-stack-when-creating-an-Assembly-preset-in-Modo-11

CG News

Modo 15.1 リリース

Modo 15.1がリリースされました。

https://community.foundry.com/discuss/topic/157234/modo-15-1-is-now-available-for-download-and-trial
https://learn.foundry.com/modo/content/help/pages/welcome_modo/whats_new.html

 

Modo 15.1 - 洗練されたワークフロー

15シリーズの2番目のリリースとなるModo 15.1は、ワークフローの洗練と制作プロセスを大幅に改善する機能追加へのコミットメントを強化しています。

OmniHaulは、ツールのプロパティとチャンネルをジェスチャーベースでコントロールし、完全にカスタマイズすることができます。
カーブブーリアンは、複雑なジオメトリを作成するために簡単に利用できる2Dデザインを開発する新しい方法を提供します。
遅延評価と一時停止評価は、プロシージャルモデリングや、パフォーマンスを重視するリグのインタラクティブ性を劇的に向上させます。

15.1では、さらに多くの強力な機能が追加され、Modoがアーティストやデザイナーの生活をより快適に、より生産的にすることを約束します。

 

ようこそModo 15.1へ

インテリジェントな新しいワークフローの改良とパワフルな新機能の追加により、Modo 15.1は必ずや感動を与えます。

 

新機能

ダイレクトモデリング

Modoは、優れたモデリングワークフローとは何かを定義しました。リリースを重ねるごとに、パワーと柔軟性が増しています。ユーザーは、状況に応じた膨大な数のツールを使って、素早くジオメトリを作成、操作することができます。

15シリーズに新たに追加されたのは、カーブブーリアン、ジオメトリブーリアンの多くの機能強化、そしてサブディバイドです。
また、面取り編集も改良され、一連の新機能をサポートしています。

 

プロシージャルモデリング

ダイレクトモデリングツールを追加・強化する際には、その変更がプロシージャルツールセットにも適用されることがよくあります。これにより、どのモデリングステージでも編集可能な強力なモデリングツール群が生まれました。

15シリーズでは、Deferred and Paused Evaluation、Loop Slice、MeshFusion Edge Weights to Stripsのサポートが追加されました。
また、Merge MeshOpが更新され、スタック全体ではなく特定のプロシージャルレイヤーをマージできるようになりました。

 

レンダリングとシェーディング

Modoはパワフルなプレビューレンダリングウィンドウで有名ですが、mPath QuickCamはこの機能を新しい物理ベースのパストレースレンダラーに追加するための最初のステップです。

ユーザーは、標準のレンダリングウィンドウ内でゲームのナビゲーションのように「周りを見る」機能を含め、シーン内をナビゲートすることができるようになりました。
また、mPathでは、被写界深度を有効にしてもレンダリング時間への影響を最小限に抑え、分散をサポートしています。

 

アニメーションとリギング

リギングとアニメーションは、他のアプリケーションでは独立した機能として扱われることがよくあります。しかしModoでは、これらのツールをより包括的に扱い、アセットの作成、デザインの反復、コミュニケーションでの使用を重視しています。

スタックノードは、スケマティックノードグラフ内のスタックベースの関係を視覚化します。Rig Clayは、ユーザー定義のジェスチャーコントロールを可能にし、新たにメショプのコントロールにも対応しました。

 

パフォーマンスと継続性

Modoがリリースされるたびに、パフォーマンスの向上が機能として扱われます。

Python 3とQT5のサポートを追加しました。MeshFusion ワークフローオーバーホールでは、ワークフローとデザインの観点からパフォーマンスを改善し、MeshFusionをより楽しいものにしました。
Deferred and Paused Evaluationにより、MeshOpsとDeformerのインタラクティブ性が向上し、パフォーマンスのボトルネックが解消されました。

 

ビューポート

多くの3Dアプリケーションのビューポートは、最初はクイックプレビューレンダラーとして始まりました。しかしModoは、ビューポートの役割を、機能的でカスタマイズ可能なオーサリング環境へと進化させました。

コマンドリージョンとリグクレイの強化は、この取り組みをさらに強化するものです。アドバンストビューポートに被写界深度が追加されたことで、ユーザーはフルレンダリングを起動することなく、カメラの設定をインタラクティブに調整できるようになりました。
また、新しいMeshFusionワークフローは、ビューポートを中心としたワークフローを強調しており、コンテンツ制作の未来がどのようなものになるかというModoのビジョンの舞台となっています。

 

ワークフローとユーザーエクスペリエンス

Modosの機能は、常にワークフローとユーザーエクスペリエンスを最優先して設計されています。

OmniHaulは、カスタマイズ可能なジェスチャーベースのツールとチャンネルのコントロールを3Dビューポートで直接行うことができます。
強化されたブーリアン機能、拡張されたプリセット機能、そして新しいMeshFusionワークフローは、モデリングワークフローの未来を定義する基礎となる、全く新しいインタラクションパラダイムを導入します。

 

チュートリアル

 


 

新機能の数は多くありませんが、どれも便利な機能です。というか機能紹介ページに15,0の機能書いて水増ししてますねw
今回便利だと思う機能はOmni Haul、遅延評価、カーブブーリアン、スタックノードです。

Omni Haulはビューポートの何も無いところをドラッグした時のツールの動作をカスタマイズする機能です。これまでハードコーディングされてた操作をカスタマイズできるようになって凄く便利です。
これは単純にOmni Haulが追加されただけでなく、ポリゴンの分割操作がマウス右ドラッグに統一されるなどツール間で似た機能の操作が統一されいます。Omni Haulを使わなくてもツール操作が一貫性を持ったのは快適になったと思います。

Omni Haulはモデリングツールだけでなく、アイテムを移動回転するときも便利です。XYZ軸を個別のマウスボタンに割りふってダイレクトに軸を編集出来るようになるので、アニメーション作成などのアイテム操作が直感的になりました。
これまでも移動や回転ツールでCtrlキーを押しながらビュー操作すると軸を固定して操作することができてましたが、移動ツールは作業平面に沿った2軸しか操作できませんでした。Mayaのようにマウスの移動方向の軸を編集できればよかったのですが、作業平面固定なのがアニメーション作業では不便でした。回転ツールも同様でZ軸しか回転できず、LightWaveのように直感的に編集できないのが不満でした。

modoのツールはモデリングで便利なように作られてて、アイテム編集では微妙な動作していたところがOmni Haulによってだいぶ快適になると思います。

 

遅延評価と一時停止評価はダイレクトモデリングやプロシージャルモデリングのパフォーマンスが凄くよくなります。特にプロシージャルモデリングの遅延評価は複雑なデータの編集で効果的です。
ポリゴンのスムージングを遅延させる機能は複雑なメッシュでポリゴン全体を移動するのが遅い問題が改善します。どうも3DCGではスムージング の計算がボトルネックらしく、3dsMax 2022もスムージング計算を改善してたりします。

遅延評価はアニメーションでも恩恵があります。プロシージャルモデリングの遅延評価をONにすると、リグコントローラー操作時にメッシュ変形を計算しないので、実質リグの計算速度だけでコントローラーを操作できるようになります。

また、リグ操作やアニメーション再生時に軽いダミーメッシュに置き換えて表示する機能も追加されました。元のデフォーマパフォーマンスが改善してるわけじゃないので、どうしてもメッシュが切り替わる時に遅く感じますが、編集中のモデルを切り替えるという他のソフトでは見かけないアニメーションに適した機能が追加されたのは好印象です。

今回のアップデートで3Dソフトにある体感速度上げる工夫は一通り搭載されように思います。これまでのパフォーマンス問題を全て解消するような劇的な変化ではありませんが、modoにアニメーション機能が搭載されてから欲しかった機能が一通りそろったのでとても嬉しいバージョンアップになっています。

 

リリースノートや機能紹介に書かれてませんが、プレイブラストにフレーム番号非表示やアルファオプションが追加されたり、Particle GeneratorのTypeにUse Arrayチャンネルが追加されたり、カスタムOCIOプロファイルをキットとして追加できるようになったり、細かな機能強化もおこなわれています。

 

modoは13シリーズ頃からロードマップとして技術的負債の解消に取り組んできました。願わくば、そろそろ開発スピードを元に戻して作業が楽しくなる機能を追加して欲しいですね。

 

ビジョンとロードマップは何ですか?

私は様々なインタビューの中で、どちらかというと情報を積極的に提供していることがお分かりいただけると思いますが、なぜこのようなスレッドを立てたのでしょうか。正直なところ私はもっと多くのことを共有したいと思っていますが、そうするにはしばしば問題があります...。

  1. 多くの方が求めている情報は非常に具体的なもので、より高いレベルのビジョンではありません。例えばボリュームメトリクスはいつ作業されるのか、レンダリングウィンドウはいつ作り直されるのか、といったことです。
    これらは非常に具体的なもので、私たちはバックログを追跡し順位をつけていますが、正直なところ2週間ごとに私がバックログを見直し、調整しています。
  2. これは物事が頻繁に変化することにつながります。これはアジャイルであることの一部であり、多くの人にとって最も重要なことを行うためにペースを保つことです。
  3. ある機能をリリースすることを計画しても、準備ができていなかったり、技術的な制約があって解決には複数回のリリースが必要だったりするため、プロセスの後半でそれを撤回することがあります。
  4. 重要な問題、コードのリファクタリング、パフォーマンスに関する作業などが発生し、一見単純に見えることが想像以上に困難になることもあります。

 

では、ハイレベルな優先事項は何でしょうか?

私たちは、以下の3つの取り組みを行っています。

  • お客様を大切にする:お客様から寄せられた課題を最優先で解決すること
  • 拡張性があること:昨年開始した技術的負債の処理を完了させ、主要分野におけるアプリケーションのパフォーマンスと拡張性を引き続き向上させ、APIとSDKのドキュメントを改善して統合機能を拡張することが次に優先されます。
  • 作成速度:新機能の追加やワークフローの強化は、ユーザーがデザインを作成して画面に表示するまでの速度に重点を置いています。ほとんどの場合、モデリング機能とレンダリングのパフォーマンスが対象となります。

ここからさらにレベルアップすると以下のようになります(これも変更される可能性があります)。

  1. 技術的負債:サポートするライブラリ、ビルドシステム、ビジュアルスタジオのコンパイラ、コアコードをc++、Python 3、Qt 5などに更新する。
  2. バグ修正: 多くのUI/UXの改良、クラッシュの問題、リリース間のリグレッション、その他の小さな問題。
  3. UXとワークフロー: 既存のツール、マーキング/パイメニュー、シェーダツリーの強化、ビューポート表示オプションなどModoを再び楽しくするための多くのクリーンアップと改良。
  4. モデリング機能とイノベーション:MeshFusion、プロシージャルモデリング、ダイレクトモデリング、UVツールなど、非常にクールな機能強化。
  5. レンダリング: USD/Hydraによるサードパーティ製レンダリングデレゲートのサポート強化、全く新しいパストレーサー(mPath)、オフラインレンダリングとビューポートにおけるGPUアクセラレーション。
  6. アニメーション/リギング:IK/FKソルバーの継続的な改良、スケマティックの強化、「rigClay」と呼んでいるものによるインコンテクスト・リギング・コントロール、そしてさらなるパフォーマンスの向上。
    なお、この作業はプロシージャル・モデリングの一部とブレンドされています。

 

なぜ、個人ではなく大企業に対応するようになったのですか?

現在のビジネスは昔に比べてはるかに多様化しています。私が入社した頃(701の頃)は、95%以上が個人向けのシングルシートの販売や、大企業のシングルシートの販売でした。今日ではこのミックスは全く異なり、ビジネスの大半は複数のシートを持つアカウントから来ています。
これは多くの皆さんの採用の増加につながり、また他のソフトウェアプロバイダーがModoを中心としたツールを開発するようなビジネスの安定性を構築するという意味で、良いことだと思います。

確かに複数シートのアカウントに特化したことはしていますが、個人を無視しているわけではありません。我々はフィードバックをカテゴリー別に分類し、そのカテゴリー間でできる限り均等になるように努力しています。
しかし、マルチシートアカウントの比率が高くなると、個人の視点での評価が低くなっていくのは避けられないことです。

私たちが常に課題としているのは、多くの皆さんに影響を与えるものを見つけようとすることで、声の大きい人が必ずしも大多数を代表しているわけではありません。私が言えることは、限られたリソースと時間の中で、できる限り調和のとれた活動を行うことです。

 

ベータチームに参加することはできますか?

最近、Modoのベータ版のプロセスを変更しました。アクティブなお客様であれば誰でもベータテストに参加できるという、よりオープンなアプローチを採用しました。以前のような排他的なグループではなく、このフォーラムのそのエリアに自ら登録するだけでよいのです。

新機能を設計する際に、1対1で作業するお客様もいます。これはもう少し限定的で、個人がかなりの時間を投資する必要があります。
また、ベータテストではなく、開発者が作業するためのユーザーストーリーを練る間、slackでの議論にとどまることもよくあります。もしあなたがこのプロセスに参加したいのであれば、お気軽に私に直接メールしてください。

 

なぜ新しいリリースについてメールしてくれないのですか?

GDPRの規則により連絡先リストが大幅に削減されたことも知っています。多くのお客様は、活動していないと判断されたためにこのリストから削除されたか、ある時点でメールの受信を拒否したと思われます。
残念なことに削除した、あるいは受信していない可能性の高いメールの中にあるリンクを使って、再び受信することしかできません(悔しいですが)。

これは現在使用しているマーケティングオートメーションシステムの大きな欠点であり、そのため年内にシステムの入れ替えを行う予定です。ご迷惑をおかけしますが、早く改善されることを願っています。

 

この製品をダメにしているのは、「スーツ」や「ファンドマネージャー」です

ファウンドリーのこの部門のプロダクト・ディレクターとして、私にはこのチームの50人近くの給料を支払うだけの収益をもたらす責任があります。
上からの唯一の命令は、キャッシュフローをプラスに保つことです。私はもちろん、私たちがやっていることや、みんなで決めたことを報告しますが、Cスタッフが関わるのはそれが限界なのです。

謎の権力者に責任転嫁するのは本当に不当なことです。もし誰かに指摘されたり、理由を聞かれたりしたいのであれば、遠慮なく私に指摘してください、私はかなり面の皮が厚いので。

Tips

FBXファイルのUp軸

FBXファイルの拡張オプション「軸変換」のUp軸について書いてみます。

3Dソフトは座標系の違いによってシーンの上方向をY軸(Y-Up)であらわすソフトと、Z軸(Z-Up)であらわす2種類のソフトが存在します。Y-Upの代表的な3DソフトはMaya、modo、LightWave、Cinema 4Dです。Z-Upの代表的な3Dソフトは3ds Maxです。

FBX形式を使用してデータをやり取りする場合、Y-Upのソフト間では軸が問題になることは少ないですが、Z-Upの3ds MaxからFBXを出力する場合は注意が必要です。

 

FBXの軸変換オプション

3ds MaxからFBXファイルを出力する場合、拡張オプションに「軸変換」というオプションがあり、Y-UpとZ-Upを指定することができます。

 

しかし、残念なことに「軸変換」はトランスフォームに-90°を入れて回転するだけで、インポート先のソフトにあわせて軸を変換(回転をフリーズ)しません。軸変換でY-UpやZ-Up変更しても、FBX出力したソフトのUp軸が維持されます。

例えば下の画像は3ds MaxからY-Upで出力したFBXをMayaに読み込んだ物です。見かけのUp方向はあってますがトランスフォームの回転に-90が入っており、オブジェクトの軸はZ-Upのままです。

 

Mayaでは「トランスフォームのフリーズ」を使用すると回転値をフリーズして、Y-Upにすることができます。

 

3ds MaxからY-UpでFBX出力する方法

FBXのインポート先でMayaのようにトランスフォームをフリーズできる場合は問題ありませんが、FBX出力時にトランスフォームを適切なUp軸にしたい場合があります。

3ds MaxからY-UpでFBX出力したい場合は「基点のみに影響」をONにして基点を回転します。

 

 

modoの軸変換

modoでは読み込んだFBXの軸変換に2つの方法が使用されています。

Y-UpのFBXファイルを読み込んだ場合、トランスフォームアイテムのPreRotationが追加されて-90°回転した状態になります。

 

Z-UpのFBXファイルを読み込んだ場合、FbxUpAxisConvertという名称のロケータが追加されて-90°回転した状態になります。

 

Y-UpのソフトからZ-Upで出力したFBXの場合、FbxUpAxisConvertとPreRotationが追加され両方の回転に値が入ります。

 

modoでトランスフォームの「フリーズ」を使用すると、回転を0にして軸をY-Upにすることができます。

参考資料

Triplanar kHellstr for Modo

Modo用のTriplanarアセットが公開されています。非商用は無料です。

https://khellstr.gumroad.com/l/JwEkf

TriplanarはXYZの3軸方向から異なる画像をマッピングする手法です。キューブプロジェクションに似てますが、各画像が徐々に透明にブレンドされるので、プロジェクションの切れ目が目立ちにくいという物です。UV展開せず手軽に切れ目のないマッピングを適用できるので、一部で人気のあるマッピング手法のようです。

私が最初に見かけたのはVrayフォーラムでしたが、今はArnoldMariなどにも搭載されてるみたいですね。modoにはテクスチャー リプリケーターもありますが、建築系のようなタイリングテクスチャを使用したい場合はTriplanarが便利かもしれません。

 

 

概要

Modo用のTriplanar Texture Projection Assemblyです。使い方はビデオをご覧ください。

// 非営利目的であれば、無料で使用できます。もしそれでお金を稼いだら、何かを支払ってください 🙂

Tips

modoのライト減衰の制御方法

modoのライトマテリアルを使用した減衰の制御方法について書いてみます。

modoのレンダラーはフィジカルベースです。フィジカルベースレンダラーのライトは、ライトの明るさによって照射範囲が自動的に減衰します。フィジカルライトはリアルなライティングになるのでメリットが多いのですが、爆発などエフェクトで使用したい場合に制御しづらい場合があります。

modoではライトマテリアルにマップを設定することで、昔のレンダラーのように指定した距離でライトを減衰させることができます。

 

下の画像はスポットライトを使用した通常のライト減衰です。

 

ライトのプロパティではフォールオフタイプを使用してライトの減衰の種類を指定することができますが、古いレンダラーのようにライトの照射範囲を1mに制限するような細かな制御ができません。

 

ライトの減衰を制御する場合はシェーダーツリーのライトマテリアルにGradientを追加し、レイヤーエフェクトを「ライトディフューズ量」に設定します。
Gradientの入力パラメータを「ライトまでの距離」に設定すると、Gradientのカーブを使用してライトの照射範囲を制御することができます。

 

Gradientのカーブをギザギザに繰り返すと波紋のようなライトになります。

 

Gradientのレイヤーエフェクトを「ライトの色」にすると、ライトからの距離で色を変化させることもできます。

 

modoのレンダラーはフィジカルベースでありながら、古いレンダラーのように柔軟な制御ができるところが便利ですね。

以前書いた爆発を作る方法では、爆発中心の明るさを制御するのに今回紹介した方法を使用しています。

 

参考

https://community.foundry.com/discuss/post/1220577

Tips

modoでウェイトマップをパーティクルサイズマップにリマップ

modo 15.0でRemap Weightのターゲットに「パーティクル サイズマップ」と「パーティクル ディゾルブマップ」が追加されました。パーティクル サイズマップを使ってReplicatorで複製したアイテムをアニメーションする方法について書いてみます。

 

 

パーティクル サイズブマップを使用したアニメーション

サンプルファイル

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

 

Set Weightを使ってウェイトマップを作成し、Grow Weightのステップを使用してウェイトマップをアニメーションしています。
modo 15.0で追加されたSmooth Weightでウェイトを滑らかにした後、Remap Weightでウェイトをパーティクルサイズマップに変換してます。

Spikeを使用しているのはポリゴンの中心にアイテムを配置するためです。Replicatorのソースモードには「ポリゴンを使用」という設定がありポリゴンの中心にアニテムを複製することができるのですが、残念ながらパーティクルサイズマップの読み取りに対応していません。

このためSpikeを使用してポリゴンの中心に頂点を作成して、Remap WeightにSelect by Previous Operationを使ってSpikeで作った頂点にだけパーティクルサイズを設定しています。ちょっと回りくどいですね。

 

 

Surface Particle Generatorにはウェイトマップをパーティクルサイズマップとして使用する機能があります。ランダムにアイテムを複製したい場合は、Surface Particle Generatorを使用した方がノードが単純です。

サンプルファイル

 

modo 14から15にかけて頂点マップ系のノードが増えて便利になってます。この調子でマップ制御系のノードを充実して欲しいですね。

参考資料

Modo Item Icons

modo用のアイコン集が発売されました。400以上のアイコンが含まれているようです。価格は£4。
modoのアイテムアイコンは一部のビューポートで表示されなかったり、アイコンが設定されていなかったりします。こういうのは標準で対応して欲しいですね。

https://gumroad.com/l/modoitemicons

概要

Modoの内蔵アイテム用の400以上のアイコンです。

アイコンには、プリセットブラウザのサムネイル、アイテムリストとスケマティックビューポートのアイコンが含まれています。

アイテムのカテゴリーには、アイテム、ロケータ、ライト、デフォーマ、フォールオフ、ダイナミクス、フォース、パーティクルモディファイア、プロシージャルアイテム、ボリューム、メッシュ操作、チャンネルモディファイア、アレイ、グラデーション、コマンドリージョンなどが含まれます。

15.0用に作られています。10.2までテストしてます。

Tips

modoのスナッピング

modoのスナップ機能について書いてみます。

modoは強力なスナップ機能を搭載していて、グリッド、頂点、エッジ、ポリゴン、カーブなどのエレメントに対して、柔軟にスナッピングすることができます。
スナップは機械的なモデリングで頂点やポリゴンをぴったりくっつける場合に便利です。また、モデリングだけでなく、アイテムモードでアイテムを配置する場合にも便利に使えます。

スナップの使用方法

スナップ機能はツールバーの「スナッピング」をONにすると有効になります。

modoのトランスフォームツール(移動、回転、スケール)は、ツールをアクティブにし状態でビューポートをクリックすると、クリックした位置を基準に動作します(アクションセンターが設定されていない場合)。
「スナッピング」をONにするとメッシュのエレメント(頂点、エッジ、ポリゴン)にアクションセンターがスナップするようになり、スナップしやすい動作に切り替わります。

 

スナップする対象は「スナッピング」ポップアップで設定します。ポップアップはツールバーの「スナッピング」ボタンをAlt を押しながらクリック、またはツールプロパティの「スナッピング」ボタンで表示することができます。

 

スナップ対象はアイテムモード、コンポーネントモードで個別に設定することができます。グローバルを使用すると、アイテムモードとコンポーネントモードの両方のスナップ対象を設定することができます。

 

ツールがアクティブな状態でXキーを押したままにすると、キーを押してる間だけスナップを有効にすることができます。

 

スナップタイプ

スナップする対象は13種類あります。このうち3種類はペンツールでしか動作しません。

 

グリッド

ビューポートのグリッドにスナップします。「固定グリッドを使用」を使用すると任意のグリッドサイズを指定することができます。

 

頂点

メッシュやカーブの頂点にスナップします。「固定スナップ」を使用すると常にスナップした状態にすることができるので便利です。

 

エッジ

エッジやカーブにスナップします。

 

エッジの中心

エッジの中心や、カーブの中心にスナップします。

 

ポリゴン

ポリゴンやカーブにスナップします。

 

ポリゴンの中心

ポリゴンの中心にスナップします。カーブの場合はよくわからない位置にスナップします。

 

交差

ポリゴンが交差した所にスナップします。カーブの場合は頂点間を直線としてあつかうようです。

 

エッジを選択した場合は、選択したエッジの交点にスナップします。

 

ボックス

メッシュのバウンディングボックスにスナップします。バウンディングボックスの四隅と、辺の中心にスナップします。

 

ピボット

アイテムのピボットにスナップします。センターにはスナップしません。

 

ワールド軸

XYZ軸方向にスナップします。ペンツールとミラーツール専用です。

 

直線

2頂点間の直線上にスナップします。ペンジェネレータ系のツール専用です。

 

直角

辺に対して直角にスナップします。ペンジェネレータ系のツール専用です。

 

ガイド

ガイドラインにスナップします。メッシュコンストレイントにまとめられていますが、機能的にはスナップ用の機能です。ガイドにスナップさせるには「スナッピング」をONにする必要があります(スナップタイプの設定は不要です)。

 

ガイドは無限に続く直線です。あまり便利な使い道が思いつかないのと、modo 15.0では動作が不安定になっていてクラッシュしやすいので、あまりお勧めしません。

 

スナップツール

ツールバーの移動ツール、回転ツールボタンを長押しすると、あらかじめスナップがセットされた便利ツールを使用することができます。

 

特にドラッグ スナップ リジッドは便利なのでお勧めです。

 

頂点、エッジ、ポリゴンのスナップは使用頻度が高いので忘れることはないですが、交差、直線、直角は忘れがちなので動作をまとめてみました。

2軸だけスナップさせる「2Dスナップ」や、スナップ対象を距離で指定する「深度制限」など、スナップのオプション機能が充実してるのも便利ですね。

 

参考

 

Tips

modoのアイテム配置に便利なツール紹介

modoのアイテム配置に便利なツールの紹介です。

3Dソフトを使用していると、シーンにアイテムを配置するという作業が多いです。そこでmodoの便利なアイテムの操作方法として、アクションセンター、スナップ、トランスフォーム配列ツールを紹介したいと思います。

アクションセンターを使用したアイテム操作

アクションセンターはツールの基点を指定する機能です。アクションセンターはmodoの強力なモデリング機能の1つとして紹介したことがありますが、アイテムを配置する場合にも便利に使用することができます。

移動ツール

アクションセンター「ローカル」を使用すると、アイテムのローカルの角度ごとに移動することができます。
これは他の3Dソフトでもよく見る定番の動作です。

 

回転ツール

アクションセンター「自動」を使用すると、選択中のアイテムをまとめて回転することができます。
ツールプロパティの「位置のみ」をONにすると、アイテムの角度を維持した状態で位置座標を回転することができます。

 

スケールツール

アクションセンター「自動」を使用すると、選択中のアイテム+アイテムの座標をスケールすることができます。
ツールプロパティの「位置のみ」をONにすると、アイテムのスケールを維持した状態で位置座標をスケールすることができます。

 

スナップを使用したアイテム操作

モデリングで便利なスナップ機能はアイテム配置にも使えます。グリッド、頂点、エッジ中心、ポリゴン中心、バウンディングボックス、など様々な条件でスナップすることができます。

 

トランスフォームツールを使用したアイテム操作

モデルツールタブの「複製」にはアイテム配置に使えるトランスフォームツールがあります。トランスフォームツールを使用するとアイテムの配置で便利に使えます。

カーブトランスフォーム

アイテムをカーブ上に配置することができます。

 

トランスフォームスキャッタ

アイテムをランダムに移動、回転、スケールすることができます。ジッターツールも同じようなことができます。

 

トランスフォーム配列

アイテムを等間隔に配置することができます。

 

トランスフォームラディアル配列

アイテムを放射状に配置することができます。らせん状にオフセットすることもできます。

 

 

modoは他にも「ソフト移動」「シアー」「ツイスト」「ベンド」など変形ツールを使用してアイテムの位置を編集することができます。

 

今回紹介したトランスフォームツールや変形ツールを使用したアイテム操作は、静止画用途だけでなくアニメーション作成にも使用することができるので知ってると便利だと思います。

CG News

Deadlineがライセンスフリーモードを10に拡張

レンダリング管理ソフトDeadline 10.1.15.2がリリースされました。今回のアップデートからライセンスフリーモード使用できるワーカーの数が2から10になり、使用制限が緩和されたようです。数台のPCでレンダリングするぶんには十分使えそうです。

https://docs.thinkboxsoftware.com/products/deadline/10.1/1_User%20Manual/manual/release-notes.html#deadline-release

改善点

  • ライセンスフリーモードで許可されるワーカーの数が、2から10に増えました。
  • Deadlineが、MongoDB 4.2をサポートするようになり、新しいRepositoryをインストールする際にMongoDB 4.2.12をインストールするようになりました。
  • ホワイトスペースを含むリポジトリパスにコマンドを送信すると、リモートコマンドの実行に失敗することがある不具合を修正しました。
  • アプリケーションロードバランサーの背後にある場合に、リモート接続サーバーがリクエストを受け付けないという問題を修正しました。
  • Env:<EnvVariable>フォーマットを使って、Deadline InstallersとDeadline Commandにパスワードを指定する機能を追加しました。
  • Free on AWSのライセンスに、GovCloudや中国を含む追加のAWSリージョンのサポートを追加しました。
  • .NET Coreをバージョン3.1.113にアップグレードしました。
  • PATH環境変数を上書きした場合に、DeadlineSandboxが失敗するバグを修正しました。
  • 1台のマシン上で同時に実行できるリモート接続サーバは最大1台に強制しました。