Modo

CG News

CharacterBox  1.2.0 リリース

modo用のモジュラーリグプラグイン、CharacterBox  1.2.0 がリリースされました。modo13対応やミラーウェイトツール、ソフトIKなどの機能強化がおこなわれているようです。既存ユーザーは無償アップデート。これでやっとmodo13に移行できる。
https://www.psoft.co.jp/jp/news/20191111-cbox/

スケールを使用したリグ編集に対応

ソフト IK 強度

マッスルのロケータ対応

ミラーウェイトツール

対称タグ追加

リグエディットモードを刷新

対称編集ツール

対称アイテム選択

スケルトンサイズのコピー / ペースト

SPIK コントローラーを整列

ゴール回転に同期

FK を 2DIK に変換

FK の姿勢をできるだけ維持するように 2DIK ゴールの位置を移動します。

未使用のノードを削除

シーンに残った不要なデータをクリーンアップすることができます。

アクションレイヤー対応

スタンドアロンライセンスツールをアップデート

ネットワークレンダリング専用プラグイン

ネットワークレンダリング専用プラグインの提供を開始しました。

Modo 対応バージョン

Windows 版  Modo 10.2v2 / 11.x / 12.x / 13.x

CG News

Modo QuickExport Plugin

ゲームやチーム向けにモデルを手軽にエクスポートするキットが公開されています。価格は$10。
https://gumroad.com/l/jWtAW

概要

QuickExportはゲームやチーム向けに特別に設計された時間を節約するツールキットであり、従来のほとんどのパイプラインに適応することができます。

自動更新

MLToolsキットの一部であるQuickExportには自動更新機能が付属しており、修正や改善を行ったときに最新情報を簡単に入手できます。

特徴
  • シーンディレクトリに基づいてアイテムごとに保存されたパスをエクスポートします
  • シーンのエクスポートアイテムを簡単に識別するためのドッキング可能なエクスポートインターフェイス
  • アイテムまたはワールドスペースのエクスポート
  • 階層のマージ(およびルートのマージ)
  • MeshOp、Deformerおよびインスタンスのサポート
  • 設定可能なエクスポートパスプリセット
  • 構成可能なパスの置換(ゲームへのソース)
  • FBXプリセットおよび上記すべてのアイテムごとの設定
  • ジオメトリに適用されたモーフをエクスポートします
  • 階層のクリーンアップ
互換性

主にModo11および13でテストされていますが、今後のバージョンも引き続きサポートします。

CG News

Modo 13.2 リリース

Modo 13.2 がリリースされました。今回は機能追加が少ない気がしますね。個人的に気になる機能はCurve Falloff、Twist Extractor、Edge Chamferです。GPUパストレーサーは今後のスピードアップに期待かな。

https://community.foundry.com/discuss/post/1185693
https://learn.foundry.com/modo/content/help/pages/welcome_modo/whats_new.html

 

新機能

レンダリング

ハードウェアに依存しないAMD Radeon ProRenderと、NVIDIAのRTXテクノロジーを介したレイトレーシングを加速した新しいmPath Modoレンダリングにより、マテリアル評価が改善されました。

 

アニメーション

グラフエディタの改良により、カーブの正規化、スタックされたカーブ編集モード、スピードとベロシティの視覚化、キーハンドルの編集の簡素化などの新機能が導入されました。
アニメーションタイムラインの改善点としては、選択した項目またはアクションに基づいてタイムラインの範囲をすばやく設定できるTime Fitコマンドが新たに追加されました。

 

リギング

ツイスト角度の予測可能性と制御機能を備えた新しい強力なツールが導入されています。また、グラディエントベースのユーザチャンネルを追加する新しいオプションが追加されているため、高度なリギングやその他の手続き型ワークフローで柔軟性がさらに高まります。

 

シェーディング

X-RiteのAxFTM形式のサポートが1.1および1.4仕様に拡張され、現実世界の物理マテリアルを可能な限り最高のデジタル表現で提供します。

 

モデリング

ダイレクトおよびプロシージャル モデリングワークフロー用のまったく新しいエッジ面取りは、Modoのベベルツールに堅牢で信頼性の高い機能を提供します。

 


個人的には13.1に引き続きパフォーマンスの改善に期待していまが、間に合わなかったようで残念です。

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

フラストレーションはわかりますが、引き続きパフォーマンスの向上に取り組んでいきますのでご安心ください。13.1ではいくつかの素晴らしい作業が行われ、13.2でもパフォーマンスの作業を続けたいと思っていましたが、これらの変更のいくつかは時間がかかる大幅な変更であり、今回のリリースでは完了していません。私たちはパフォーマンス作業を前進させ続け、将来のリリースで必要とされる改善を盛り込むつもりです。

これまでの主な焦点はサーフェス生成を改善することでした。メッシュが変形していても、手続き型であっても、伝統的にモデリングされていても、画面にサーフェスを表示するための主要なボトルネックは、カードに送信するデータを生成しています。これにはメッシュのサブディバイド、トライアングルインデックスの生成、法線の計算、位置の計算などが含まれます。変形メッシュの場合、これはフレームごとに行う必要がある作業です。modoでは変形は並列化されているため、可能な場合はマルチスレッドとベクトル化の両方を使用して、できるだけ多くのスレッドの頂点位置を計算します。残念ながらデフォーマの計算はボトルネックではなく、すべてのデフォーマをメインスレッドに戻してサーフェスを計算するときに発生します。これが13.1の主要な焦点でした。

13.1にはサーフェス生成をバッチ処理に移行するために多くの作業を行いました。これにより基本的に同じタイプのすべてのポリゴンをグループ化し、ポリゴンのサーフェスプロパティを一度に計算できるようになりました。これには類似したポリゴンのメモリルックアップをローカライズするという利点がありますが、今後の作業のためにより良い/よりクリーンで/より効率的なAPIが提供され、さらに最終的には並列で実行されるように定義されていますが、現在はメインスレッドでのみ実行されます。これらの変更に合わせて新しいAPIを使用するようにフェースポリゴン生成コードを書き直した結果、場合によっては3倍に改善されました。ただし、他のポリゴンタイプでは、これらの改善の利点はまだ認識されていません。SubD、PSub、カーブなどは現在、新しいAPIを使用するために修正中です。

新しいパストレーシングレンダラーは技術プレビュー段階のようです。LPE(Light Path Expressions、単純な記法を使用して特定のライトの組み合わせなど欲しいレンダリング要素を出力する機能)は便利そうですが、パストレースがレンダリング時間のかかるアルゴリズムであるため、現時点ではデフォルトレンダラーの方が早いと思われます。画質やレンダリング速度が向上するまでは様子見かな。

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

パストレースはバイアスのないブルートフォースアルゴリズムであるのに対し、デフォルトレンダラーはサンプルマージや放射照度キャッシングなどのあらゆる種類のトリックを使用するため、多くの場合より高速です。

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

ほとんどの既存のパストレーサは伝統的な再帰型であり、各パスは次のパスに進む前に終了するまで(各パス頂点でのさまざまな数のディフューズ/スペキュラ/etcサブパスへの分割)トレースされます。mPathが異なるのは多数のパスの最初のセグメントが一度にトレースされ、結果のヒットポイントがすべてシェーディングされ、すべてのパスが1つのセグメントで拡張され、すべての二次ヒットポイントがシェーディングされるという点です。再帰や分割がないため、別個の拡散/鏡面反射光/などのサンプルカウントは適用されません。

この設計は「ウェーブフロント パストレーシング」と呼ばれることもあり、ArnoldやVrayなどの古いレンダラよりも、最新世代のスタジオレンダラ(ディズニーのHyperionなど)と共通しています。シンプルさは主な利点の1つです。すべてのサンプリングはNoise Threshold(上限は最高品質設定)によって制御され、パスの長さはPath Threshold(深さ設定によって制限される)によって制御されます。例外は、環境重要サンプリングを適用するかどうかですが、最終的には有益な場合はいつでも使用して、これも自動化したいと考えています。

ウェーブフロントスタイルのパストレースはDreamWorks Moonray(all CPU)やNVIDIA Iray(all GPU)など、さまざまなレンダラで使用されているため、さまざまなターゲット市場に適用できます。これはmPathをよりシンプルにするだけでなく、よりモジュール的にして、さまざまなレイトレーシングとシェーディングエンジンをサポートできるようにする方法でした(将来のすべてのGPUを含む)。ちなみにPixarもCPU/GPUのハイブリッドレンダリングをサポートするRenderMan XPUで同様の方向に進んでいるようです。

開発者ライブストリーミングでは、安定性、ノンリニアアニメーション機能より新しいIKソルバの開発が優先されたことや、USD、Hydraに関することが語られてるようです。

Modoの新しいmPathレンダリングエンジン

http://www.cgchannel.com/2019/11/technology-focus-modos-new-mpath-render-engine/

ModoのレガシCPUレンダラーのGPU対応置換

mPathはまだ進行中の作業ですが、最終的には2006年にソフトウェアに追加されたModoの古いデフォルトレンダラーの完全な置換として意図されています。
デフォルトのレンダラーは純粋にCPUベースですが、mPathはモジュラーアーキテクチャを特徴としており、幅広いハードウェアのサポートを組み込むことができます。

Maxwellカードを含む古いNvidia GPUのサポート

従来のパストレーサーとは異なり、mPathは非再帰的アプローチを使用します。このアプローチではカメラパスをトレースするプロセスは、カメラレイが当たるシーンのサーフェスをシェーディングするプロセスから切り離されます。
ヘイスティングス氏は、このアプローチによりFoundryはさまざまなハードウェアバックエンドをより簡単にサポートできるようになり、レイトレーシングとシェーディング用に個別のハードウェアバックエンドをサポートできるようになると述べました。

初期実装にはCPUベースのFoundry SSEと、NvidiaのOptiXフレームワークを使用するGPUベースの代替の2つのレイトレーシングエンジンがあります。Foundryのプレスリリースでは、mPathが「NvidiaのRTXテクノロジーを介した高速レイトレーシング」を提供していると説明していますが、実際には現行のRTX GPUは必要ありません。

Pixel Fondueストリームでヘイスティングス氏は、レンダラーが「RTXハードウェアで大幅に向上」している一方で、GPUレイトレーシングが古いNvidiaグラフィックカードでもサポートされていることを確認しました。これには2014年のGeForce GTX 800シリーズおよび2015年のQuadro Mシリーズで展開されたMaxwellアーキテクチャのカードが含まれます。

mPathはデフォルトのModoレンダラーよりどれくらい高速ですか?

mPathの明らかな利点はスピードです。ライブストリームで示した内部テストシーンでは、mPathでは100分でレンダリングされたのに対し、デフォルトレンダラでは360分でした。
他のテストシーンでは時間の節約はより小さくなりました。ヘイスティングスは「ジオメトリが多い複雑なシーン、またはイトバウンスが多い複雑なシーン」で改善が最も重要であるとコメントしました。

被写界深度の計算にもメリットがあります。デフォルトレンダラーは「約50%長く」かかり、ノイズの分布がより均一になり、ノイズ除去ワークフローに役立ちます。

その他の利点:使いやすさ、出力の柔軟性、より高度なマテリアルハンドリング

もう1つの利点は使いやすさです。mPathの特徴は、はるかに少ない制御パラメーターセットです。シーンのレンダリングに使用されるライトバウンスの数の設定に加えて、本質的に2つの重要なパラメーターがあります「ノイズしきい値」と「最大品質」。2つはmPathがレンダリング中の計算作業をどこに集中させるかを決定します。後の反復ではノイズが残っている画像の部分のみが改善され続けます。

mPathはライトパスエクスプレッションもサポートしているため、個々の光源がレンダーに与える影響をより柔軟に分割することができます。Foundryの製品設計者Greg Brownによると実質的に計算上のオーバーヘッドなしで、個別にレンダリングする必要なく、単一のレンダリングでライトパスを生成できるようになりました。
また、新しいエンジンは多くのベータテスターが以前のレンダリングでガラスの外観がどれだけ優れているかを驚かせた。屈折をうまく処理すると述べています。

将来的にmPathに追加される可能性のあるその他の機能には、テクスチャデータをストリーミングしてGPUでのレンダリング時のパフォーマンスを改善する機能、Open Shadling Languageのサポートが含まれます。

現在の制限

mPathは最初の実装ではかなり制限されています。レンダラーは現在、Modoのデフォルトのフィジカルマテリアルのみをサポートしており、従来型または省エネルギー型のマテリアルモデルはサポートしていません。
Modoのすべてのプロシージャルマテリアルとグラデーションをサポートしていますが、スキン、ヘアマテリアル、プリンシプルシェーダーはサポートしておらず、ボリュームメトリックスもレンダリングできません。
最初の実装はバケットベースであり、Foundryはアニメーションワークフローに利点があると説明していますが、任意の時点でレンダリングを停止するオプションを備えた完全なプログレッシブレンダリングが計画されています。

Tips

modoのバインド

modoの「バインド」について書いてみたいと思います。

バインドとはスケルトンとメッシュアイテムを関連付けて、スケルトンのトランスフォーム(移動/回転/スケール)を使用してメッシュを変形できるようにする機能です。一般的にスケルタルアニメーション(ボーンアニメーションやスキンアニメーションとも呼ばれる)するために必要な工程です。

 

バインド方法

バインドを実行するするには、いくつかの手続きが必要です。

  1. メッシュアイテムとスケルトンを準備する
  2. セットアップモードをONにする
  3. メッシュアイテムとスケルトンが選択された状態で「バインド」を実行する

 

バインドは何をしているのか

バインドを実行するとメッシュにウェイトマップが生成されるほか、シーン内にいくつかのアイテムが作成されることに気がつくと思います。

バインドは実行時にいくつかの処理を自動的におこないます。具体的には以下の通りです。

  1. 各スケルトンごとにウェイトマップを作成する
  2. ジェネラルインフルエンスを作成してメッシュ、ウェイトマップ、スケルトンを関連付ける
  3. 正規化フォルダを作成してジェネラルインフルエンスを入れる

 

手動でバインド

バインド済みのメッシュに後からスケルトンを追加したい場合など、手動でスケルトンとウェイトを関連付けたい場合があるかと思います。手動で設定するとこんな感じの手順になります。

 

バインドで使用されてる機能について

バインドで使用される機能について解説してみます。

ウェイトマップ

ウェイトマップは「頂点マップ」というメッシュの頂点にメタ情報を持たせる機能の1つです。modoは「UV」「モーフ」「頂点カラー」「法線」「トランスフォーム」など様々な情報を頂点に格納します。

ウェイトマップはその名称通り「重さ」という抽象的な値を頂点に格納します。このウェイトマップはmodoの様々な機能で利用することができます。

ウェイトマップの使用例

バインドで作成されるウェイトマップは、デフォーマがメッシュを変形するときの「影響の強さ」を指定するのに使用します。ウェイトの値が100%であればスケルトンのトランスフォームの影響を100%受けます。1つの頂点が複数のスケルトンから影響を受ける場合は、後述の「正規化フォルダ」によって正規化されたウェイト値が使用されます。

 

ウェイトマップのメリット

ウェイトマップはメッシュの頂点に情報を持たせることができるため、UVやテクスチャを作成することなく直接メッシュに選択範囲やマスクのようなものを作成することができて便利です。

また、modoの頂点マップはメッシュを編集してもある程度補間してくれるため、ウェイト/モーフ/UVなどを非破壊的にメッシュ編集できるという特徴があります。他の3Dソフトではありがちな、バインド後にメッシュを編集したらウェイトを最初からつけ直しというような問題が発生しません。

 

ジェネラルインフルエンス

ジェネラルインフルエンスは、メッシュのどこを変形するか指定するアイテムです。modoのデフォーマはプロシージャルモデリングやパーティクルシステムと同じようにノードベースの設計になってます。デフォーマは主に以下のノードで構成されています。

  • アイテム
  • インフルエンス
  • エフェクタ

「アイテム」は変形対象になるメッシュアイテムです。
「エフェクタ」はベンドやマグネットのように、どんな風に変形するか指定します。
「インフルエンス」はどこを変形するか指定します(ウェイトマップなど)。

ジェネラルインフルエンスはベンドやスケルトンによる変形など、一般的にアニメーションで使用するデフォーマ機能で使用されます。下の画像はベンド エフェクタを使用してメッシュを変形するときのノード構成です。

 

正規化フォルダ

正規化フォルダ(Normalizing Folder)はデフォーマの計算を1度におこなうための機能です。modoのデフォーマは「デフォーマリスト」の順番で変形を処理します。しかし、スケルトンで制御されるキャラクターのようなメッシュを変形する場合は、デフォーマを順番に計算するのではなく一度に変形を加える必要があります。

例えば下の画像では、センターのボックスにウェイトマップを100%ずつ重複するように設定しています。スケルトンを回転や移動したとき、センターのボックスは2つのスケルトンのトランスフォームが加算され2重に変形してしまいます。
General InfluenceをNormalizing Folderに入れると、ウェイトの上限が100%(スケルトンのそれぞれ50%ずつ)に正規化された変形になります。

 

スケルトンの変形は「トランスフォームデフォーマ」と同じ

スケルトン/ボーン変形まわりの仕様は3Dソフトによって様々ですが、modoのスケルトンによる変形は「トランスフォームデフォーマ」と同じです。

modoでは基本的にエフェクタ (ベンド、マグネット、ボルテックスなど)がジェネラルインフルエンスに変形方法を指示しますが、トランスフォーム(移動/回転/スケール)を持つアイテムは全てトランスフォームデフォーマとしてジェネラルインフルエンスに接続することができます。

バインドコマンドはロケータにしか対応していませんが、カメラ、ライト、メッシュアイテムなどトランスフォームを持つアイテムはスケルトンの代わりに使用することができます。

Mayaを使用した経験があればmodoのデフォーマのノード構成に違和感を感じることはないと思いますが、3dsMaxやLightWaveではエフェクタとインフルエンスがまとまった機能として提供されるため、ノード構成が少し複雑に見えるかも知れません。

恐らくエフェクタとインフルエンスを分けているのは汎用性を高めるための設計だと思います。サードパーティ製のエフェクタが開発されたとしても、ウェイトやフォールオフはインフルエンスによって一貫性のある動作が期待できます。
古いソフトはパラメータ固定のものが多かったので、このデフォーマではウェイトが使用できるのに、こっちのデフォーマではウェイトが使えない。というような一貫性のなさに苦労することがありました。

 

バインドが作成する特殊なウェイトマップ

バインドを使用して作成されたウェイトマップは少し特殊なウェイトマップです。バインドで作成されたウェイトマップは「頂点マップリスト」でロケータアイコン付きのマップとして表示され区別できます。下の画像では上が通常のウェイトマップ、下がバインドによるウェイトマップです。

なぜこのウェイトマップが特殊かというと、関連付けられたスケルトンを削除したタイミングでウェイトマップも同時に削除されます。

デフォーマリストにはジェネラルインフルエンスが残るので注意が必要です。有効なジェネラルインフルエンスが残ったままだと意図しない変形が加わることがあるため、バインドを繰り返して使用する場合はジェネラルインフルエンスを手動で削除する必要があります。

 

特殊なウェイトマップの作成手順

この特殊なウェイトマップは手動で作成することもできます。作成方法は「頂点マップ作成」するとき「__item_+シーンが管理するアイテム名」を入力します。

modoはアイテムツリーで表示されるアイテム名の他に、シーンが管理している名前を持っています。例えばシーンにLocatorを作成して選択します。「コマンド履歴」を見ると「select.item locator004 add」のようにシーンが管理するアイテム名を確認することができます。

頂点マップ作成ダイアログで「頂点マップの名称」に「__item_locator004」と入力してマップを作成すると、頂点マップリストではLocatorがアイコンつきの特殊なウェイトマップとして作成されたのが確認できます。

 

せっかくウェイトを調整したのに、スケルトンと一緒にウェイトマップが削除されると困る場合があると思います。そんな時のための便利なスクリプトを紹介します。

 

Convert Skeleton Weight to normal Weight

modoのバインドを使用した場合に生成される特殊なウェイトマップを、通常のウェイトマップに変換するスクリプトです。

http://modogroup.jp/tipsblog/scripts/cnv_skwgt2wgt/

 

Connect Weight Skeleton

同名前のウェイトマップとスケルトンを関連付けるスクリプトです。他のソフトで設定したウェイトをmodoのスケルトンに関連付けしたい場合に便利です。

http://www.modonote.com/script/connect-weight-skeleton/

Tips

modoのスケルトン

modoのスケルトンについて書いてみたいと思います。
スケルトンはキャラクターなどのメッシュを変形してアニメーションさせるときに使用します。キャラクターにポーズを取らせるとき、関節の位置を指定するために使用します。他の3Dソフトではボーンやジョイントと呼ばれたりします。

 

スケルトンの作成方法

スケルトンはスケルトンツールを使用して作成します。スケルトンツールは「モード」を切り替えることで、スケルトンを「追加」「編集」「挿入」「削除」することができます。

「対称」を設定するとスケルトンを左右対称に編集することができます。

 

スケルトンはロケータでできている

他の3Dソフトではボーンやジョイントと呼ばれる専用のアイテムがありますが、modoのスケルトンはロケータアイテムを階層化したものです。このためスケルトンツールを使用しなくてもスケルトンを作ることができます。
スケルトンはロケータの「シェイプ」や、階層構造を視覚化する「リンク」によってビューポート上での見た目が設定されています。

 

スケルトンの色は表示オプションの「ワイヤーフレームの色」「塗りつぶしの色」でカスタマイズすることができます。

modoではスケルトンとメッシュを「バインド」することで、はじめてスケルタルアニメーション(ボーンアニメーションやスキンアニメーションとも呼ばれる)することができるようになります。

modoのスケルトンが専用アイテムではなくロケータを使用しているのは、恐らく専用のアイテムを必要としない設計を目指しているからだと思います。バインドの記事で解説していますがmodoはスケルタルアニメーションにスケルトン以外のアイテムを使用することもできますし、スケルトンにマッスルボーンのような機能を搭載しなくてもリグを作ることができる環境が用意されています。リギングでは基礎となる汎用的な仕組みがあれば、機能が限定された専用機能を搭載するよりも将来的な自由度が高いということのように思います。

 

参考

Tips

modoでメッシュにパーティクルが集まる表現

Foundryのフォーラムでメッシュにパーティクルが集まるサンプルを公開してるのを見かけたので紹介します。パーティクルが収束するエフェクトに使えそう。
https://community.foundry.com/discuss/post/1184559

基本的にはMODO JAPAN GROUPさんが以前公開していた「パーティクルをメッシュの表面へと吸着させる方法」のパーティクル コンスレイントの代わりに、交差サーフェース コンストレイント (Intersect) を使用したバージョンです。

パーティクルでIntersectを使用するとサーフェース表面でパーティクルが動き続けるので、パーティクルシミュレーションの「ステップ」を上げると安定します。

Tips

modoでアイテムが揺れる表現

modoで移動したアイテムがバネのように揺れる表現について書いてみたいと思います。

■サンプルファイル

 

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

基本的には「トランスフォーム配列ツールでアニメーション作成」で紹介したように「Soft Lag」を使用して揺れを表現してます。
しかしメッシュ全体にSoft Lagを適用するとアニメーションの再生が遅くなるという問題があるため、今回はメッシュ全体を変形するのではなく Locators to Array と Create Polygons を使用してアイテムの位置からポイントを生成して、軽いメッシュにSoft Lagを適用することでアニメーションの再生が遅くなる問題を回避しました。

アルファベットのアイテムは「頂点の位置」を使用して頂点にコンストレイントしてます。

 

パーティクルに適用してみました。

サンプルファイル

Soft Lagはパーティクルと相性が良くないようです。パーティクルはフレームが進むごとにポイントを発生させますが、Soft Lagはポイントがない場合ワールド原点を前のフレームとして扱うようです。このためエミッターの位置を移動すると、原点から移動したような極端なラグが発生してしまいます。Soft Lagのトランスフォーム位置を参照してくれれば嬉しいんですけどね。

あと、ラグが好ましくないガクガクした挙動になります。ReplicatorをMerge Meshする方法も試してみましたが、同じようなフレーム間のカクつきが発生するようです。

Soft Lagは便利な機能なので、もっと改善して使いやすくして欲しいですね。

参考資料

Arrayを使用したモデリング

Arrayを使用したモデリングのチュートリアルが公開されてます。Arrayは様々な情報からポリゴンやパスを生成できるので、使い方しだいで面白いモデリングができますね。
https://www.pixelfondue.com/blog/2019/10/16/modeling-with-arrays

パート1:ひものボールまたはスパゲッティをボールのモデリング

パート2:麺を像に巻き付ける-レーザースキャナースタイル

Tips

modoで複数のスペキュラを重ねる表現

modoで複数のスペキュラをレイヤーのように重ねる表現について書いてみます。

■ サンプルファイル

 

現在のようにPBRマテリアルが主流になる前の時代、金属を表現する場合はスペキュラを重ねることで表現してました。modoではShaderの「ブレンドモード」を使用して複数マテリアルのスペキュラを加算することができます。

 

現在はマテリアルに「クリアコート」があるためスペキュラを重ねた質感が手軽に作れるようになってますが、スペキュラを3つ以上重ねたい場合には今回紹介した方法が便利かもしれません。あとクリアコートはレンダリングが少し遅い気がします。

 

スペキュラを加算したレンダリング。

クリアコートを使用したレンダリング。

 

参考

http://forums.luxology.com/discuss/post/42125

Multi-Coat

 

おまけ

スペキュラを重ねた金属表現はLightWave界隈では「Gaffer」が有名でした。3dsMaxにもMulti Layer Shaderがあり、かつては金属表現に欠かせない定番の設定でした。

Gaffer

セレクティブライト、多重スペキュラ、フレネル、反射の色、ブルームなどライティングに関連する様々な質感を制御することができるプラグインでした。
https://web.archive.org/web/20010108121200/http://www.worley.com/gaffer/gaffer_spec_control.html

 

MegaLight

スペキュラにトーンカーブのようにバイアスをかけることで金属っぽいスペキュラを表現したプラグイン。
http://www.dstorm.co.jp/dsproducts/FreePlugins/PreviousPlugins/MegaLight.html

 

Multi Layer Shader

Tips

modoのウェイトマップをアニメーション

Transfer Vertex Mapを使ってウェイトマップをアニメーションさせてみた。ちょっとしたテストです。

■サンプルファイル

 

Texture Falloffを使用したアニメーション。

 

基本的には法線の転送のウェイトマップ版です。現状はフォールオフを使っても0か1の値しか転送出来ないため、滑らかなウェイトにすることができないのが残念です。Merge MeshesしたメッシュにTransfer Vertex Mapが使えないのも残念。。。Merge Meshesつかればキャラクターのウェイト設定を使い回す仕組みが作れそうです。

C4Dのようにウェイトの範囲を時間経過で広げたり、時間差でウェイトを消したりできるようになって欲しいですね。

Tips

modoのコンストレイント ウェイト

modoのコンストレイントにあるウェイトチャンネルについて書いてみたいと思います。コンストレイントのウェイトを使用すると2点間でアイテムを等間隔に配置するようなリグを作ることができます。

modoのコンストレイントは複数のアイテムを指定することができます。ことのきコンストレイントの「ウェイト」を使用すると、コンストレイントの重みを調節することができます。ウェイトはプロパティに表示されないので、チャンネルビューポートを使用して設定します。

 

ウェイトを設定すると2点間でアイテムを等間隔に配置するようなリグを作ることができます。

Position Constraint、Rotation Constraintのウェイトを調整すると、こんな感じの制御ができるようになります。

 

コンストレイントは2つ以上の複数のアイテムに使用することもできます。

 

ウェイトの使い道は様々で「カメラブレンドリグ」のようなものが作れるので便利です。

Tips

modo終了時にコンフィグファイルに設定を保存しない方法

modoの終了時にコンフィグファイルに設定を保存しない方法について書いてみます。

modoはアプリケーション終了時にUIやウィンドウの状態をコンフィグファイル(MODOxx.x.CFG)に保存します。UIを意図せず変更して壊してしまうのを避けるため、コンフィグに設定を保存したくないという場合があるかもしれません。
そんな時はコマンドラインフラグを使用すると、コンフィグに設定を保存しないようにできます。

-dbon:noconfig

ショートカットのプロパティにフラグを追加すると便利に使えます。

 

ファイルに「アクセンス許可」で書き込みを禁止する場合と異なり、ファイルメニューの「設定の上書き保存」を使用して好きなタイミングで設定を保存できます。

 

参考

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

Tips

modoのパーティクルをサーフェースに沿って動かす方法

今回はメッシュの表面に沿ってパーティクルを動かす方法について書いてみたいと思います。

■サンプルファイル

アイテムのスナップ移動」でも軽く書いてますが、modoのパーティクルシステムは他のソフトと違い、アイテムのリギングで使用するノードをそのままパーティクルシステムで使用することができます。
汎用性が高くて面白い特長ですが、どうすれば欲しい表現を実現できるかわかり難いと感じることもあると思います。そこで「パーティクルをサーフェースに沿って動かす表現」を作る場合の考え方、どんな感じでノードを使えばいいか手順を書いてみます。

 

1.サーフェースに沿わせたい →「交差サーフェース」コンストレイント

パーティクルをサーフェースに沿わせたい場合、まずサーフェースと交差判定できるノードが必要そうだと思いつきます。modoのアニメーション機能でサーフェースと交差判定できる機能といえば、「交差サーフェース」コンストレイントです。

「交差サーフェース」コンストレイントは、サーフェース表面にロケーターをくっつけてくれる機能です。操作の基準となるアイテム、メッシュアイテムの順番で選択してモディファイヤタブの「交差サーフェース」ボタンを押すと、サーフェース表面に沿って移動するロケーターを生成してくれます。

スケマティックでノードの繋がりを見るとこんな感じになってます。

Toroidアイテムと、操作の基準となるアイテム(Locator)がIntersect ノードにつながって、交差位置用のアイテム(Locator_2)に位置が出力されていることがわかります。

このノードの処理をパーティクルで組めば同じようにサーフェースに沿ったパーティクルの移動が作れそうです。

 

2.「交差サーフェース」コンストレイントと同じ処理をパーティクルで組む

スケマティックはこんな感じです。Intersectの流れを見比べると「交差サーフェース」で作られたノード構成と同じようにリンクされてるのがわかると思います。

Particle Operatorの特性で「位置(Read Only)」「位置」の2チャンネル追加して、「交差サーフェース」と同様にノードをリンクします。Intersect の「位置出力」のチャンネルタイプマトリクスなので、Matrix Vectorを使用して「位置」チャンネルにリンクできるようXYZ軸に変換します。

 

「位置(Read Only)」「位置」について

パーティクルは「位置(Read Only)」「位置」の2つのチャンネルを使用することで、他のノードで計算した結果を戻すことができるようです。
modoは1つのノードであれば依存ループにならずに計算出来るのですが、パーティクルの場合は1つだけでは複雑な計算ができないため、このような動作になってるのかもしれません。

 

VDB Voxelを使用してメッシュを作成すると、サーフェース表面を水が流れるような表現にも使えそう。

パーティクルをサーフェースに沿って動かすのは Particle Snap Modifierを使用しても同じような表現は可能ですが、Particle Snap Modifierはパーティクルそのものの位置には影響がありません。
例えばサーフェースに沿って動いてるパーティクルから、さらにパーティクルを発生させたい場合には今回紹介した方法が便利だと思います。

Tips

modoのプロシージャルモデリングでソフトクリーム作ってみた

暑いのでmodoのプロシージャルモデリングでソフトクリーム作ってみた。プロシージャルにこだわって作ったので、モデルの形状は雰囲気です。

■サンプルファイル(13.1)

 

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

 

クリーム

クリームの螺旋はSpiral Curveアセンブリを使用してます。Transform Effectorを使ってカーブをアニメーションしてます。そのカーブをmodo13.1で追加されたCurve Sweepを使用してクリームのメッシュを生成してます。クリームのシルエットやカップコーンに入る部分の調節にはラティスデフォーマを使用してます。

Curve Sweepは複数のパスを使用して押し出したり、ミニグラフを使用してカーブの太さを制御できるので便利です。

 

スプリンクル

クリームのふりかけ(スプリンクル)は、ReplicatorとLinear Falloffのイージングを使用してアニメーションしてます。カラフルな色のレンダリングにはVariation Textureを使用してます。

変形するメッシュにSurface Particle Generatorを使用するとフレーム単位でポイントの位置が変わってしまうことがあるので、中央のソフトクリームはアニメーション終了時のメッシュを別アイテムとしてコピーしてSurface Particle Generatorのソースとして使用しています。

プロシージャルモデリング用のメッシュにダイレクトモデリングしようとすると警告が表示されますが、ポリゴン選択してコピーすることはできるので便利です。

 

コーンカップ

コーンカップはコーン断面のパスを作成し、Radial Sweepを使用してコーンがあらわれるアニメーションにしてます。Radial Sweepには始点と終端のキャップを生成するオプションがあるのですが、あまり形状が綺麗にならなかったのでOFFにしました。

 

 

modoのプロシージャルモデリングはアニメーションでは使うには遅いのが気になります。クリームが落ちてくる速度と形状がいまいちなのですが、動作が遅いのでタイミング詰めるのあきらめました。今回はプロシージャルにこだわって作りましたが、クリームのらせん形状はデフォーマを使ってアニメーションしたほうが軽く作れるかも知れません。

プロシージャルモデリングはモデリングするときに便利ですが、アニメーションで使用するにはもう少し速度が改善されると嬉しいですね。今後のバージョンアップで快適に動くようになるのを期待してます。