CG 日記

Tips

modoのパーティクルの基礎

パーティクルの基礎で、パーティクルで発生しやすい問題の対処方法について書いてみたいと思います。

パーティクルが震える

パーティクルが平面とコリジョン判定するようなシーンで発生しやすいのが、パーティクルが静止せずプルプル動き続ける現象です。

これはコリジョンアイテムのダイナミクス設定「パーティクル衝突粘性」のデフォルト値の 50 mm 原因です。「パーティクル衝突粘性」を 0 または 100 mm など大きな値にすることで解決することができます。


「パーティクル衝突粘性」はパーティクルがコリジョンアイテムの表面をどの程度の距離くっつくかという設定です。水がアイテム表面をつたうような表現のときに使用できます。

パーティクルが停止するかしないか微妙なときに、「パーティクル衝突粘性」の値が影響して震える現象が発生するような気がします。

 

パーティクルがコリジョンを突きぬける

パーティクルの速度が速い場合に、コリジョンを突きぬけてしまうことがあります。これは Particle Simulation の「ステップ」の値を大きくすることで解決することができます。
「ステップ」は「シミュレーションを演算」した場合のみ確認できます。シミュレーションの再生ボタンによるプレビューは「ステップ」1 固定なので注意が必要です。

 

パーティクルの軌道がカクつく

パーティクルエミッターの移動速度が速い場合に、パーティクルの軌道がカクカクしてしまうことがあります。これも Particle Simulation の「ステップ」の値を大きくすることで解決することができます。

modoに限らずCGのシミュレーションはデフォルトで1フレーム単位で計算するソフトが多いです。パーティクルの速度やエミッターの移動が速い場合は、1フレーム間隔だと計算精度が足りなくなりコリジョン抜けやカクつきが発生します。そんなときのために1フレーム間隔より細かく計算するための設定が「ステップ」です。計算量は指数関数的に増えますが、正確な計算結果を得ることができます。

modoではパーティクルとメッシュのコリジョンを設定するために「ダイナミックコライダー」を適用すると solver アイテムが追加されます。 solver アイテムにも「演算精度」という「ステップ」と同じような設定がありますが、「演算精度」を上げてもパーティクルの突きぬけには変化がないようです。リジッドボディーやソフトボディーと連携する場合には「演算精度」が影響してくるのかも知れません。

Tips

TurbulenceFDのキャッシュをVDBに変換する方法

LightWaveやCinema4D用のフルードダイナミクスプラグイン TurbulenceFD のキャッシュファイルをVDBに変換する方法について書いてみます。

今まで気がつかなかったのですがTurbulenceFD v1.0 Build 1422(2017-03-23)からbcf2vdbコマンドラインユーティリティが追加されました。bcf2vdbはTurbulenceFDのキャッシュファイル.bcfを.vdbに変換するツールです。このツールはプラグインの圧縮ファイルに含まれているので最新版をダウンロードしてみてください。

変換方法
  1. コマンド プロンプトを起動します。
  2. コマンド プロンプトウィンドウに bcf2vdb.exe をドラッグアンドドロップします。
    ドラッグアンドドロップすると、コマンドプロンプトにbcf2vdb.exe へのパスが表示されます。
  3. スペース キーを押します。
  4. キャッシュファイル.bcfを保存しているフォルダをドラッグアンドドロップして、エンターキーを押します。.bcfと同じフォルダに.vdbファイルが生成されます。

このツールはファイルの保存先やファイル名のパターン、レンダリングする必要がないチャネルを選択することができるようです。

このツールを使うとLightWaveやCinema 4Dで計算したシミュレーション結果を他のソフトで使用することができるようになります。これは便利ですね!

 

参考

https://forum.jawset.com/viewtopic.php?p=6278#p6278

Tips

modoのテクスチャリプリケータ

modoにはアイテムをメッシュの頂点に複製する「リプリケータ」という機能がありますが、テクスチャ版の「テクスチャリプリケータ」という機能が便利なので紹介したいと思います。

テクスチャリプリケータ はアイテムの頂点にテクスチャを配置することで、模様を作ったりテクスチャのタイリングを目立たなくしたりに使える機能です。

画像だけでなくプロシージャルテクスチャにも使用する事ができます。ノイズテクスチャを使用すると下の画像のようになります。

Surface Generatorと併用することで、アイテムのメッシュに依存することなくランダムにテクスチャを散布することができます。
modoはプロシージャルテクスチャ機能が豊富なので、ゲーム向けにテクスチャをベイクして活用したいときなんかにも便利に使えると思います。

Gradient レイヤーにはテクスチャリプリケータに関連する設定があります。入力パラメータを「テクスチャパーティクルID」に設定するとランダムな色を設定することができます。

入力パラメータを「ロケータまでの距離」に設定すると、放射状のグラデーションにすることができます。

 

テクスチャリプリケータの面白いのが「パーティクルソース」にParticle Simulationを指定できて、パーティクル特性を利用できることす。例えばパーティクルが「サイズ」が徐々に大きくなるように設定すると、テクスチャリプリケータに反映されます。
下の画像はシェーダーツリーでレイヤーエフェクトを「ディフューズ色」と「バンプ」に設定したものです。

スケマティックも貼っておきます。Particle Operator に「寿命」と「サイズ」を追加して、「寿命」チャンネルを「サイズ」にリンクします。これで個々のパーティクルが発生してから徐々に大きくなるように設定しています。

 

あまり語られることはありませんが、modoのパーティクルはモデリング、レンダリングに次いで強力な機能だと思います。パーティクル機能とテクスチャリプリケータを併用することで、水の波紋、オブジェクトが濡れる表現、文字を書く、など他のソフトでは専用プラグインが必要そうな表現を標準機能だけで作ることができます。

次回はパーティクルとテクスチャリプリケータ使ったエフェクト的な表現について書いてみたいと思います。

Tips

modoでグリッドアセンブリの作り方

手続き的にグリッドを表示するアセンブリの作り方を書いてみます。

modoのロケータはデフォルトで十字アイコンですが、「シェイプ」を「カスタム」にすることで、リギングに使えるプリミティブ形状を設定することができます。LightWaveには「Item Shape」という同じような機能があるのですが、modoに搭載されていないシェイプ形状として「 グリッド 」があります。

modo11.0からプロシージャルメッシュを「ワイヤフレーム」表示することができるようになったので、プロシージャルのCubeをリギングすれば簡単にグリッドのアセンブリを作ることができます。

アセンブリの中身はこんな感じです。

作り方で迷いそうなのは、軸XYZを切り替えたときにCubeのサイズXYZへの出力を切り替える部分でしょうか。
軸の切り替えはチャンネルタイプ「軸」の値を、条件式ノード「A は B と等しい」を使用してスイッチしています。値が等しい場合は「1」を、値が異なる場合は「0」を出力します。
あとは条件式ノードの出力値を演算ノードで乗算することで、指定された軸にみえるCubeの「サイズ」にのみ「Scale X」「Scale Y」の値が流れるようにしています。

スクリプトとかプログラム的なことはよくわからないので、条件式を使った切り替え方法としてこういう使い方が正しいのかわかりませんが、やりたいことはできている気がします。

補足ですが、ビューポートでアイテムをワイヤフレーム表示するには「3Dビューポートプロパティ / アクティブメッシュ」で、「描画スタイルの独立」をONのする必要があります。

 

Cubeの大きさに合わせてセグメントの分割数を増やす動作は、モデリング系のアセンブリにも使えるんじゃないかと思います。

Tips

modoで関節の位置にあるロケータでアップベクターを制御する方法

前回に引き続きIK制御に関連したリグの作り方です。IKで制御されている関節の位置にコントローラーを配置して、そのコントローラーを回転してアップベクターを制御するリグの作り方を書いてみます。

 

このリグは好き好きあると思いますが、IKの「モディファイヤ依存ループ」を回避する方法として紹介してみたいと思います。基本的には「IKゴールの移動範囲を制限する方法」と同じで、IK制御に関連しない階層を使用するのがポイントです。

作成手順です。

  1. IKとアップベクターが設定されてたシーンファイルを準備します。
  2. ロケータを3個追加します。
    追加したロケータはそれぞれ、スケルトンの位置、アップベクター位置、IKゴール位置に配置します。アイテムの配置はドロップアクションの「位置を一致」を使用すると便利です。
  3. ロケータに親子関係を設定します。
    アップベクターに配置したロケータを、IKゴールに配置したロケータにペアレントします。IKゴールに配置したロケータを、IKゴールにペアレントします。
    アイテムのペアレントはドロップアクションの「同位置でペアレント」を使用すると便利です。
  4. スケルトンの「ワールド位置」を、スケルトンの位置に配置したロケータにリンクします。
    チャンネルビューポートから「ワールド位置」をスケマティックに追加して、ロケータの「ワールド位置」にリンクします。これにより異なる階層にあるロケータが、スケルトンにペアレントしたように動作します。
  5. 同様にアップベクターの位置に配置したロケータの「ワールド位置」を、アップベクターにリンクします。
    本来はスケルトンの位置のロケータに、アップベクターを直接ペアレントできればスマートなのですが、「モディファイヤ依存ループ」が発生してしまいます。このため異なる階層にあるロケータの「ワールド位置」をアップベクターにリンクすることで「モディファイヤ依存ループ」を回避しています。
  6. スケルトンの位置のロケータの回転Yを、IKゴール位置のロケータにリンクします。
    これでスケルトンの位置にあるロケータを回転させることで、アップベクターの位置を変更することができるようになります。

このあたりのリグの組み方がわかると、IKの「モディファイヤ依存ループ」に苦しまずに済むかも知れません。

Tips

modoでIKゴールの移動範囲を制限する方法

前回modoのIKについて書いたので、ついでにIKに関連したリグの組み方の例として、IKゴールの移動範囲を腕や脚の長さより遠くに移動しないように制限する方法を書いてみます。

 

LightWave のIKには「ゴールを接着 (Keep Goal In Reach)」という機能があり、IKチェーン(IKによって制御されているスケルトン)の長さより遠くにIKゴールが移動しない設定がありました。この設定をmodoで再現したものです。

作り方は単純でDistance Constraint を使用してアイテムの移動範囲を制限します。

作成手順です。

  1. IKの始点と同位置にロケータを作成して、ロケータの子のスケルトンにIKを適用します。
    これはFBIKのアップベクターの作成手順で使用する階層構造と同じです。
  2. Distance Constraint を作成します。
    Distance Constraint はその名の通り、距離でコンスレイントするモディファイヤです。
  3. ロケータを作成して、IKゴールの位置に移動します。
    ロケータをビューポートでドラッグアンドドロップ(長押し)すると、ドロップアクションメニューが表示されるので「位置を一致」を選択すると簡単に同じ位置にアイテムを移動できます。
  4. IKゴールをロケータの子にし、ロケータの「ワールド位置」をスケマティックに追加します。
  5. Distance Constraint を設定します。
    IKチェーンの親のロケータと、IKゴールの親のロケータの「ワールド位置」を Distance Constraint の「起点」と「終点」にリンクします。Distance Constraint のプロパティでクランプを「最大」、距離をIKチェーンの長さに設定します。画像ではIKチェーンの長さを計るために、測定モディファイヤの Measure Distance を使用しています。
  6. 最後にMeasure Distanceの「位置出力」を、IKゴールの親のロケータにリンクします。
    IKを制御するときはIKゴールを直接編集するのではなく、ロケータを編集することでIKチェーンの長さより遠くに移動しない状態になります。親アイテムを移動したときもIKゴールが一緒に引っぱられて動きます。
    注意点としては、見た目は制限されていてもトランスフォームの値は生きていることです。IKゴールを遠くまで移動してしまうと、IKチェーンの親アイテムを移動したときに、なかなかゴールに到達しない感じになります。

IKに関連したリグを組もうとすると発生しやすい問題が「モディファイヤ依存ループ」です。IKはIKゴールの位置を使用してスケルトンの位置や角度を計算するため、IKチェーン内のスケルトンの位置や角度を使用してIKゴールを操作しようとすると処理がループしてしまい計算不能になります。

IKに関連したリグを作るときは、IKチェーンと関係ない階層のアイテムを使用するとうまく行くと思います。

CG 日記

modo 11 リプリケータのパフォーマンス向上


modo 11からReplicatorのパフォーマンスが改善されました。Cboxのサンプルファイルを見てて気がつきましたが、modo 10に比べて2倍以上早くなってました。
このシーンはキャラクターがパーティクルで533体複製されているのですが、シーンをリアルタイム再生したとき平均して 25FPS くらいでてます。modo 10だと画面を引いたときに 9FPS しかでなかったので、だいぶ高速化されている気がします。

バージョンアップのたびに少しづつパフォーマンスが改善されてるので、12シリーズもパフォーマンス向上を期待したいですね。

Tips

modoのインバースキネマティクス

modoのIKについて書いてみたいと思います。
modoには「Dual Joint Planar IK」と「Full Body IK」2種類のIKがあります。それぞれメリットとデメリットがあり、アニメーション用途で安定したIKが必要な場合は「Dual Joint Planar IK」がいいかもしれないという話です。

 

IK とは?

3DCGでアニメーションを作成する場合、ざっくり「FK」と「IK」2種類の制御方法に分かれます。

IKは元々工業用のロボットアーム制御用に開発された技術で、人間の腕のように複数の関節で構成されている階層構造を効率的に制御するための機能です。
ロボットの関節角度を決めるとき、階層構造の親から順に計算する方法を FK (フォワードキネマティクス) 、子の位置から親の関節角度を計算する方法を IK (インバースキネマティクス) といいます。

例えば腕が何かをつかむ場合に、「上腕」「前腕」「手のひら」を個別に回転して姿勢を決める方法が FK です。

 

複数の関節位置を「IKゴール」と「アップベクター(ポールベクター)」を使用して姿勢を決める方法が IK です。「IKゴール」は手の到達位置、「アップベクター」は肘の方向を指定するのに使用します。

FK は関節を個別に回転する必要があるので、関節数が多い場合にアイテムを一つ一つ回転する必要があります。IK は「IKゴール」と「アップベクター」2アイテムで全ての関節を制御できます。

一見FKよりIKの方が便利なように見えますが、それぞれアニメーションの内容によって向き不向きがあります。例えば走るアニメーションの場合、手の振りはFKが使いやすく、脚の動きはIKが向いています。そのため多くのIKはFKとブレンドしたり、切り替えることができるようになっています。

 

さて、ここから本題です。
modoには「Dual Joint Planar IK」と「Full Body IK」2種類のIKがあり、それぞれメリットデメリットがあります。

 

Dual Joint Planar IK

シンプルなIKモディファイヤです。IKで制御可能な関節数が2つに限定されています。

  • 使用できる関節数に制限あり(2関節)
  • アップベクター対応

IKで制御される関節の位置は、IKの始点となる関節位置、IKゴール、アップベクターの3点からなる仮想平面上を移動するように動作します。このためIKの始点、IKゴール、アップベクターのいずれかが完全に重なった(平面が形成できない)場合は、IKは計算することができなくなります。

3DソフトのIKは、だいたいこんな動作になってると思います。

 

Full Body IK

IKinemaというライブラリを組み込んだフルボディーIKシステムです。
Full Body IKはその名の通り、手を引っぱると自動で体全体が自然な姿勢を保ってくれる、聞くだけなら夢のようなIKシステムです。またモーションキャプチャデータを体格の異なるスケルトンにリターゲッティングするのに使用されます。
Dual Joint Planar IK のように関節数に制限はありませんがアップベクターをサポートしていません。

  • 使用できる関節数に制限なし
  • アップベクター非対応
  • モーションのリターゲット

画像ではアップベクターの設定にmodo標準の「方向コンストレイント」を使用しています。IKの始点の関節と全く同じ位置にロケータを作成し、IKを設定するスケルトンをロケータの子の階層におきます。ロケータからIKゴールに方向コンストレイントを設定します。方向コンストレイントの「上方ベクトル (アップベクター)」を設定することで、IKのアップベクターのような動作を設定しています。

 

Full Body IKは不安定?

Full Body IKは高機能で便利そうですが、modoではアップベクターをサポートしていないためリグを構築したりする場合に不安定になるという問題があるようです。

スケルトンの位置にいくつか制限があり、スケルトンが完全に直線的に配置されてる場合に不安定になります。
一般的に直線的に関節が配置されてる場合は、Dual Joint Planar IKを含めIKが正しく動作しないか不安定になります。IKを使用する場合は少し関節を曲げるのがIKのお作法ですが、Full Body IK ではIK制御下にない親の位置も影響するような気がします。IKが上手く動かないときは、スケルトンの位置をずらすと上手く動くようになるかも知れません。

上の画像のように方向コンストレイントを設定する方法はmodo 601のチュートリアルビデオ 「Fireboy」で紹介されていたもので、後にMattさんやMODO JAPAN GROUPさんがビデオで紹介しています。
親が回転するからそれっぽく動いてるだけで、Full Body IK がアップベクターとして計算に使用してるわけではないので、この疑似アップベクターではIKが不安定になるのではないかと思われます。

Full Body IK を安定させる方法として、「精度」を 2 から 3 に上げるといくらか改善することがあります。

 

Full Body IK が不安定という問題は Foundry フォーラムで繰り返し話題になっていて、以下のスレッドでは Sergio さんが Full Body IK についてコメントしています。
https://community.foundry.com/discuss/topic/122645/fbik-leg-rig-is-acting-super-strange

これが私がFBIKソルバを多く使うことができない理由の1つです。
それは気の利いたアップベクターが欠けている!! 誰かがそれを取り上げる前に、Mattの回避策は必ずしも機能しません。

FBIKはやんちゃで、 Planar IKは途方もなく制限されています。
使用可能なIKソルバーを取得するまで、Modoでキャラクターを作成することは苦痛を伴うことになるでしょう。(それは自分のコースのスレッドで述べていますが、これは本当に対処する必要があります。)

Mattの回避策でも作業するのは非常に難しく、アップベクターの位置を常に調整しなければならない。

そのような脚は古い方法が良いと思う。複数のPlanar IKチェーンを重ねる。 1つは脚、2つは足用です。

Sergio Mucino さんは Maya、Modo、Softimage、3ds maxを使用するTD/Riggerの方で、映画「アイアンマン3」や「デッドプール」に参加されてます。有料チュートリアル「キャラクターリギングコース」をリリースしている方でmodoに精通していると思われます。

Sergio さんが難しいと言ってる以上、Full Body IKを使用して安定したアップベクターの設定方法を見つけるのは難しいように思います。

 

 

まとめ

Full Body IK がアニメーションで動作が安定しないなと思った場合には、「Dual Joint Planar IK」を試すといいかもしれません。
アニメーションの作成方法は様々です。アップベクターが不安定でもキーをたくさん打て制御するのが苦にならなければ Full Body IK で問題ないと思います。3ds MaxのBipedはアップベクターもなく「鎖骨」「上腕」「前腕」「手のひら」全部まとめて1つのキーフレームで管理する変わったシステムだったりするので、気にしなければ気にならない問題かもしれません。

 

ちなみにフルボディーIKの特長である「手を引っぱると自動で体全体が自然な姿勢」というのは、手付けのアニメーションでは使われることが少ないようです。フルボディーIKらしいIKを使ったことないので具体的なことは書けませんが、決めたポーズが勝手に動いてしまうのでアニメーターには不評なようです。

Mayaには MotionBuilder 由来の HumanIK  というフルボディーIK機能を搭載していますが、個人サイトや小規模なアプリ開発を除くと、フル3Dの映画やゲームのモーション制作に使われているという事例を見かけることが少ない気がします。

ゲームのようにインタラクティブにアニメーションが変化するものや、アニメーションのリターゲッティング、モーションキャプチャのデータ補正には有用な技術だと思います。

LightWaveもVer 9まではIKが弱くアニメーションでガクガク震えることがありましたが、まさかmodoでもIKに悩まされるとは思いませんでした。(´Д`υ)

Tips

modoでカメラ ブレンド リグの作り方

トランスフォーム コンストレイントを使用して、複数のアイテムの位置や回転をブレンドするリグの作り方について書いてみたいと思います。

3DCGは意外とカメラの制御が難しかったりします。例えば商品説明のように決められたカメラ位置の間を滑らかに移動したい場合や、宇宙探査機のスイングバイのように異なる運動曲線間をスムーズに繋げるのに苦労することがあります。
複数アイテムのマトリクスをシーケンシャルにブレンドすることで、下の画像のようなカメラブレンド アセンブリを作ることができます。

画像ではカメラ直接使用していますが、カメラをペアレントしたロケータをブレンドした方がいいと思います。
アセンブリの中身です。

左から右に解説します。

  1. グループロケータにユーザーチャンネル「Mixer」を追加しています。チャンネルタイプは「パーセンテージ」、マトリクスのブレンド制御用のチャンネルです。
  2. 同じくグループロケータにユーザーチャンネル「Pos_x」「Rot_x」を追加します。チャンネルタイプは「行列」で、位置と回転用のマトリクスチャンネルです。
    グループロケータ「Item_x」が複数存在するのは、Transform Constraint の仕様に対処するためです。Position Constraint の「Weight.」チャンネルを見るとわかりますが、Transform Constraintは入力されたアイテム名でチャンネルを管理します。このため1つのグループロケータに複数のマトリクス チャンネルを追加して管理しようとしても同じチャンネルとみなされて上手く動きません。
    これらのユーザーチャンネルは「アセンブリ入力」としてチャンネル公開します。
  3. Position Constraint と Rotation Constraint ノードを追加します。
    Constraint ノードの「入力」にマトリクスチャンネルをリンクすると「Weight.アイテム名」チャンネルが追加されます。「入力」には複数のマトリクスをリンクすることができ、各「Weight.」の値でコンストレイントの強さをブレンドすることができます。
  4. Channel Relationship を追加します。
    「Mixer」チャンネルの値を Channel Relationship を経由して「Weight.」チャンネルを制御します。
    制御方法は単純です。「Mixer」が100%のとき「Weight.Item_1」が100%、それ以外の「Weight.」は0%になるようにすれば、Weightを制御できます。同様に「Mixer」が200%のとき「Weight.Item_2」が100%、それ以外の「Weight.」は0%になるようにするため、Relationshipのグラフはリニアな山型に設定します。各ノードで100%ずつシフトしてる感じです。
  5. 最後にConstraint ノードの「出力」を、グループロケータのユーザーチャンネル「Out_Ppos」「Out_Rot」を経由して「アセンブリ出力」します。

Constraint ノードの「Weight.」が全て0とき全て0を出力するようで、 「Mixer」が 0のときアイテムが突然ワールド原点に移動するような挙動になります。

結構単純なアセンブリですが、モーションミキサー作ってるみたいで面白いですね。
今回は位置と回転だけのブレンドですが、Scale Constraintを使えばスケールも対応する事ができます。好みに応じてカスタマイズすると面白いと思います。

Tips

modoのマトリクスチャンネル

チャンネルタイプの続きで、modoのマトリクス(行列)チャンネルについて書いてみます。
普通に3Dソフト使ってたときはマトリクスって何?という感じでよくわかってませんでした。今も正確なとことろは全くわかってませんが、リグを構築するにはマトリクスチャンネルの使い方を知っておくと便利です。

 

マトリクスチャンネルとは

マトリクスチャンネルはアイテムの「位置XYZ」「回転XYZ」「スケールXYZ」が全部セットで格納されてるようなチャンネルです。

もう少し詳しく書くと、マトリクスは3Dの座標変換になくてはならないもので、これがなければ親子関係も何もはじまらないくらい3Dの根源的な物っぽいです。
一般的に3DCGでは「位置XYZ」「回転XYZ」「スケールXYZ」と便利関数がセットになった、4×4の行列を使用するそうです。正しく理解したい人は座標変換に詳しい人に聞いてください (´Д`υ)

 

何ができるの?

リグ作ってるとアイテムの回転や位置が欲しいことが多々あります。そんなときマトリクスチャンネルを使用して「位置」「回転」「スケール」を取り出すことができます。逆に「位置」「回転」「スケール」を行列にすることもできます。
コンストレイント系モディファイヤはマトリクスチャンネルを使用してるので、マトリクスの分解と再構築方法を知ると様々なリグに応用できると思います。

modoには便利なノードが用意されてるので、マトリクスが何かという難しいことを知らなくてもリグを作ることができます。よく使う便利なノードについて書いておきます。

 

Matrix Vecto

マトリクスから位置を取り出すことができます。回転行列をリンクすると正規化された方向ベクトルを取得できます。

 

Matrix To Euler

マトリクスから角度を取り出すことができます。
オイラーは「回転順序」によって回転結果が変わるので注意が必要です。数学的にそういう物らしいので、出力した角度がなんか違うなと思ったら「回転順序」を変えてみるといいかもしれません。

 

Matrix Construct

「位置」「スケール」をマトリクスにすることができます。

 

Matrix From Euler

角度を回転行列にすることができます。

 

座標変換の知識があれば「ワールド回転からローカル角度を計算する方法」のように3D空間で必要な様々な値を取り出したり便利に使えるみたいです。
マトリクスチャンネルは「ワールド位置」「ワールド回転」「ローカル」など色々ありますが、チャンネルにどんな値が入ってるかは「マトリクスの計算順」が参考になると思います。

次はマトリクスチャンネルを使って、アイテムやカメラの位置をシーケンシャルにブレンドするマトリクスミキサー的なリグについて書いてみます。

Tips

modoでアイテムのスナップ移動

Channel RelationShipで紹介したグリッドにスナップしたように移動する方法で思い出しましたが、演算の「切り上げ」「切り下げ」ノードを使って正数を出力しても同じ表現ができるので、その方法について書いてみます。

「切り上げ」「切り下げ」そのままだと、スナップする間隔が指定できません。
任意の大きさでスナップする計算方法は以下の通りです。

  1. 「位置」÷「スナップする間隔」の値を「切り上げ」ます。これで何マス移動したかを求めます。
  2. 「切り上げ」の出力値を「スナップ間隔」でかけてやります。これでアイテムの位置を求めます。
  3. グループロケータの「SnapSize」と「XYZ」はユーザーチャンネルです。
    「SnapSize」は浮動小数点数タイプのチャンネルで、スナップする間隔を入力します。例えば 1 を入力すると 1m 間隔でスナップします。

ロケータの位置をアセンブリを経由してトーラスの位置に出力すると、トーラスがスナップしながら移動するようなアニメーションになります。

このスナップ計算は以前ゲーム作ろうと思ってマップチップ移動調べたときに、チュートリアル見て覚えました。こういう計算は自分では全く思いつかないので、ゲーム系の解説しているサイトはすごくためになります。

modoのパーティクルはアイテムと同様にモディファイヤで制御することができます。パーティクルに今回作ったスナップ アセンブリを使用すると、パーティクルの位置をスナップさせることができます。

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

トーラスからSurface Emitterを使用して、寿命が1フレームのパーティクルを発生します。
Particle Operatorを使用してパーティクルの「位置」を、Collector / Emitterを使用して別のParticle Simulationに継承します。このときスナップアセンブリを使用して、パーティクルの位置が一定間隔にスナップする設定しました。
右下のParticle Operatorは「寿命」と「サイズ」をChannel RelationShipを使用して、発生後30フレーム経過したら小さくなって消えるようしています。

パーティクルのスナップの処理はレゴ風エフェクトに使えないか試したのですが、パーティクルの発生数が多いと同じ座標に複数のパーティクルを重なった状態になって使えませんでした。パーティクル制御の参考になるかと思ったので失敗例として公開しておきます。

アイテムとパーティクルの両方で同じアセンブリが使えるのは、機能ごとに似たような別の仕組みを覚え直す必要がなくてとても便利ですね。

Tips

modoのプロシージャルモデリングで雪の表現

modoのプロシージャルモデリングで雪が積もるやつまねてみた。

  1. 複数のプリミティブをMerge Meshで1つにまとめる。(雪用のメッシュ)
  2. メッシュをPush Influenceで法線方向に縮める
  3. Transform Deformerで位置をオフセットする。
  4. Transform InfluenceのFalloffにNoiseMapを設定して、でこぼこ感を追加する。
  5. 最後にVDBVoxelに雪用のメッシュを設定して、近いメッシュが繋がるようにする。

接地面がふっくら積もった感じにするのが難しかったです。GL上では確認できませんがディスプレイスメントマップで雪を表現することもできます。

 

参考

 

Tips

modoでトラックパッド コントローラーを作る方法

今回はスライダーの作り方の続きで、トラックパッドコントローラーの作り方について書いてみたいと思います。

スライダーはY軸のみ使用しましたが、トラックパッドコントローラーはXYの2軸を使用します。作り方は基本的に同じです。違いがあるとすれば、平面の位置にどのように値をマッピングするか?という部分を少し考える必要があります。

顔などのモーフマップを制御することを想定して、値のマッピングのしかたをいくつか紹介してみたいと思います。スライダーのときと同じで、トラックパッドの平面のサイズは1m (-500mm~500mm) の範囲を制御領域としています。

Clampノードやチャンネルのロックなどの説明は省くので、Clampは何に使ってるの?という方は前回のスライダーの作り方を参照してみてください。

 

2モーフを制御する方法

上下の位置で2つのモーフマップを制御する方法です。単純に上下2つのモーフならスライダーでもできますが、左右の位置をMorph InfluenceのFalloffの制御に使用してみました。

これは目のまばたきのような左右対称のモーフで使用することを想定したマッピングです。
一般的に目のモーフを作成する場合は「両目閉じ」のモーフを1つ作り、そこから「左目閉じ」「右目閉じ」と複数のモーフに派生させると思います。modoのデフォーマはFalloffを使用して変形する範囲を制御できるので、両目閉じのモーフ1つあれば「左目閉じ」「右目閉じ」のモーフを作らなくていいかもしれません。

モーフマップは以下のような2種類です。

マッピングのイメージは以下の通りです。
グラデーションはモーフマップの数と、モーフインフルエンスの「強さ」の段階をイメージしています。

アセンブリの中身は以下の通りです。グラフはChannel Relationshipの設定です。

コントローラーの「位置Y」をChannel Relationshipを使用して Morph Influence の「強さ」に出力しています。
「位置X」を使用してFalloffの方向を指定しています。画像では条件式ノードの「A は B より大きい」を使い、「位置X」が0より大きい場合は「出力True値」として「90」、0より小さい場合は「出力False値」として「-90」を出力します。この出力をFalloffの「回転Y」にリンクすることでモーフの領域を左右どちらかに制限しています。画像ではわかりやすくFalloffのサイズを大きめに設定していますが、小さく設定すればキッチリ左右でモーフをわけることができます。
「アセンブリ出力」するチャンネルには、ユーザーチャンネルを経由したものを使用しています。

 

4モーフを制御する 1

左右の位置、上下の位置で4つのモーフマップを制御する方法です。
比較的単純なマッピング方法で、隣り合う2つのモーフマップを制御できます。目のウインクと同時に、口元や頬のモーフを制御するような使い方でしょうか。

モーフマップは以下のような4種類です。

マッピングのイメージは以下の通りです。

アセンブリの中身は以下の通りです。

XYの2軸ですが特別な設定はなく、ほぼスライダーと同じ感じで作れると思います。
Channel Relationshipの出力先が少しこんがらがるかも知れませんが、1つずつ確認すれば難しくないと思います。これもアセンブリ出力にユーザーチャンネルを経由させています。

 

4モーフを制御する 2

左右上下の4つの象限それぞれ独立してモーフマップを制御する方法です。象限ごとに出力値が独立しているので、モーフ以外にも色々使える気がします。

マッピングのイメージは以下の通りです。

アセンブリの中身は以下の通りです。

各象限ごとにX軸とY軸用のChannel Relationshipを用意し、出力値をかけた値をモーフインフルエンスに出力しています。位置はChannel Relationshipを使用することで0~1の範囲にリマッピングされているので、X軸とY軸の出力値ををかけることでコントローラーがいる象限の値のみが出力されます。
個人的にこの制御方法を一番作りたかったのですが、どう計算すればいいのかわからなくてしばらく悩んでました。完成してみると凄く単純ですね。

この記事ではChannel RelationShipを使用していますが、Expressionノードや演算ノードの組み合わせでも同じ事ができると思います。好みに合った方法を選択するといいと思います。

また、今回紹介した制御方法は1軸ごとに1モーフのような単純な物です。コントローラーが便利になるのは複数のモーフマップをミックスして制御するときだと思います。たとえば目のまばたきの中間状態を制御したり、眉毛の移動に合わせて額のシワを制御したりという感じです。

 

おまけ

複数のモーフマップをどのようにすれば自由自在に制御できるのか?というマニアックな電子書籍「The Art of Moving Points」を紹介しておきます。
国内の制作事例を見ると最終的な表情のモーフがずらり並んでる事が多いですが、決め打ちではなく汎用的に使用できるモーフとは?みたいな内容です。

The Art of Moving Points

フェイシャルリグで参考になりそうな記事へのリンクも貼っておきます。1つのコントローラーで複数のパラメータを同時に制御することで、とてもリアルなフェイシャルを表現している気がします。
資料をブログで管理してると検索が楽でいいですねー

CG 日記

Filmic Tonemapping

Foundryフォーラムで話題が再燃してたので、Filmic トーンマッピングについてメモしときます。
https://community.foundry.com/discuss/topic/129634/opencolorio-we-need-filmic-modo
https://community.foundry.com/discuss/topic/138289/the-secret-ingredient-to-photorealism-video-link-modo-rendering-workflow

Filmic トーンマッピングはコダック反応曲線の近似値として作成されたもので、ゲームを映画風の見た目にするよう開発されたトーンマッピングでした。Filmic トーンマッピングはGrand Theft Auto VやUnchartedシリーズで使用されてるようです。
http://duikerresearch.com/2015/09/filmic-tonemapping-ea-2006/
http://filmicworlds.com/blog/filmic-tonemapping-with-piecewise-power-curves/

プリレンダリングでは2017年1月頃、BlenderにFilmic トーンマッピングが追加されて話題になりました。

 

以前のmodoはトーンマッピングで明るい部分が飽和しやすいという問題がありました。901からはVrayで使用されているトーンマッピングタイプ Reinhart Luminance と Reinhart RGBを選択できるようになりました。デフォルトでは「トーンマッピング量」が0%なので、トーンマッピングしたい場合には自分で値を設定する必要があります。

トーンマッピングのアルゴリズムは色々あるみたいですが、それぞれメリット/デメリットがあるようです。
プリレンダリング用途では3Dソフトのトーンマッピング機能を使用するよりも、コンポジットソフトを使用して調節した方が自由度が高いです。.exrのような浮動小数点形式で出力する場合は、3Dソフトのカラーマネジメントは使用せずリニアなカラースペースとして出力されるのはそんな理由からなのかもしれません。

The Ultimate Guide to Tonemapping

https://vimeo.com/ondemand/tonemap