今回は、カスタムノードにカスタムパラメータを追加してみますVerbとProtoヘッダファイル最近のHDKでは、SOPノード作成にVerbという仕組みを使うことが多いようです。Verbというのは、かなりざっくりいうと、SOPの振る舞いを定義する際、ジオメトリへの処理と、それ以外のパラメータ操作などの処理を分離する仕組みです。[参考]プログラム的にVerb(動詞)を使ったジオメトリVerbを利用してSOPを作成する際、これまで何度か言及していた、「Protoヘッダファイル」をビルド手順の中で生成し利用することになります。Protoヘッダファイルの主な役割Protoヘッダファイルには、ジオメトリ処理以外の実装が自動的に記述されます。※これは現時点での理解なので間違っているかもしれませんが、この仕組みにより、開発者は面倒なパラメータとジオメトリ処理をつなぐ実装を省略し、主にジオメトリ操作に関する処理に注力すれば良くなります。主なProtoヘッダファイルの役割は以下のようなものになります。Script」を記述、または「*.ds形式のファイル」として用意して、PRM_TemplateBuilderに与える必要があります。Scriptに関するリファレンスマニュアルのようなものを見つけることは出来ませんでした。Scriptを生成する方法があったので紹介します。やり方は、概ね以下の手順になります。Scriptの形式で取得できます。その後、ソースコードの*theDsFileに、取得したコードをそのままコピペするなどして与えた後、いつも通りの手順でビルドするだけです。Scriptを頂いて、カスタムSOPにそのまま持たせてみたものです。以上、カスタムSOPにカスタムパラメータを追加する方法でした。なにか間違いや、不明な点などあれば、コメントいただけると嬉しいです。Yamabe.Michiyoshi2最近、どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。今回は、SOP_Starのサンプルコードを参考にしながら、全く何の処理もパラメータも持たない、空っぽのSOPを作る最小構成のコードを書いてみました。事細かにコードの説明を書いてもとりとめが無くなりすぎて、読むに耐えない感じになり非常に微妙だったので、簡単な解説付きのテンプレートコードを転載するに留めます。いくつか補足が必要そうな箇所もあるので、後でメモを書くかも。カスタムSOPのパラメータテンプレートクラス名SOP_Template.hpp(.h)最小構成のヘッダファイルは以下のようなものになりそう。SOP_TEMPLATE#endifSOP_Template.cpp(.C)最小構成のソースコードは以下のようになりそう。ノードのメイン処理はここに記述する}CmakeLists.txtCMakeLists.txtは、自分の環境ではだいぶいじってしまっているため、サンプルを少し改変しただけの状態ではちゃんとテストできてないので、動作に若干自信なし。実践してみたい方がいれば、と思い、参考程度にコードを載せてみますが、間違ってたらすみません。(大まかには合ってるはずですが)CMakeLists.txtファイルは、サンプルを以下のような形で編集し、ソースコードと同じフォルダに置けば、以前の説明と同じ手順でビルドできると思われます。最近、どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。IDEからビルドする場合は、代わりにCMakeを使用することをお勧めします。」との記載があります。「hcustomによるビルドでは単一のソースファイルしか扱えない」旨の記述もあり、hcustomは手軽ではあるけど不便だろうなぁと想像しています。いうわけで、今後使い続けることになりそうなCMakeでのビルドを知るため、前回のhcustomによるビルドに引き続き、CMakeを使うビルドを試してみようと思います。今回もサンプルの「SOP_Star」を使います。■CMakeとは?CMakeは、プログラムのビルド処理を自動化してくれる便利ツールです。今回CMakeで行う処理は、大きく分けて以下の2つです。されたそれらのファイルを使ってビルドを行う■環境の準備まず、手元の環境ですが、以下のようなツールがインストールされています。・ソースコードをコピーする以下のフォルダを、任意の場所にコピーします。今回は、以下のようにコピーしました。Tools」と検索し、起動します。18.0.532」というタイトルの、Houdini関連の環境変数が一通り自動的にセットされたコマンドプロンプトが立ち上がります。※どんな環境変数がセットされているかは「set」と打ち込んでEnterを押すことで一覧表示、確認できます。Studioのソリューションファイル以外にも、いろいろなファイルが大量に生成されます。これらの生成されたファイルがソースコードと混ざってしまうと、生成前の状態に戻すことが難しくなります。そのため、予めビルド生成物をまとめるbuildフォルダをつくり、もとのソースコードとCMakeの生成ファイルを切り分けて管理できるようにします。ソースコードと同じフォルダにbuildという名前のフォルダを作ります。D:\temp\HDK\build_cmake\SOP_Star\build次に、以下を実行し、ソリューションとプロジェクトを生成します。..カレントのbuildフォルダに、各種ファイルが生成されます。ここで生成されるソリューションとプロジェクトは、SOP_Starフォルダの直下にあるCMakeLists.txtファイルに記述された設定に基づいて作成されます。カスタムプラグインを作成するためのCMakeLists.txtを書く際は、このCMakeLists.txtを参考にすれば良さそうです。・プラグインをビルドする続いて、以下を実行します。--clean-firstこれで、カレントのフォルダにあるソリューションとプロジェクトファイルを使い、プラグインが以下のフォルダにビルドされます。・無事ビューポート内に星型のジオメトリが現れればOKです。ここまでで、hcustomとCMakeのそれぞれを使って、手軽にプラグインがビルドできることを確認してみました。同じ要領で、サンプルにある各種プラグインをビルドすることができそうです。最近どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。HDKリファレンスによるとHoudiniプラグインは、hcustomを使うことで簡単にビルドできるらしかったので、まずは初歩中の初歩として、最も簡単そうなこの方法から試してみました。今回使用するコードは、サンプルにある「SOP_Star」です。Tools」と検索し、起動します。18.0.532」というタイトルの、Houdini関連の環境変数が一通り自動的にセットされたコマンドプロンプトが立ち上がります。※どんな環境変数がセットされているかは「set」と打ち込んでEnterを押すことで一覧表示、確認できます。D:\temp\SOP_Star・protoヘッダファイルを作成しますgenerate_proto.pyを利用し、SOPプラグインのコード内で、ノードのパラメータを定義している文字列(theDsFile)の記述をもとに、パラメータへのアクセスを簡単にしてくれるprotoヘッダファイルを自動生成しておきます。・無事ビューポート内に星型のジオメトリが現れればOKです。・protoヘッダファイルに関して古い文献を探すと、protoヘッダファイル不使用の解説が見つかったります。SOP_Star.Cを実行すると、protoヘッダファイルが見つからずにビルドが失敗するようでした。現時点では、protoヘッダファイルを使うことでプラグインのパラメータアクセスが簡単になるので、必ず用意するものと考えて良さそうだと考えています。追記サンプルのソースコードを覗くと、もともとprotoヘッダファイルをincludeするように指定されていました。protoヘッダファイルを作らないとビルドがコケるよね、というオチ。protoヘッダファイルを使うやり方は新しいやり方なのだと想像できるし、何より便利な方法なので、積極的に利用するのが良さそうという見方は変わらず。protoヘッダファイルの作成と、ソースコードでincludeする、ということをお作法としておけば間違いないのではないかと思いました。既存のノードネットワークを変更する際、変更する対象が巨大であるためにどこを変更すべきかわかりにくくなってしまっていたり、ある箇所への変更が他の箇所に影響してしまい、メンテナンスしづらい状況を経験したことは誰にでもあると思います。この記事では、そのような状況を改善・予防するため「リファクタリング」と呼ばれる手法に焦点を当て、筆者の主観をもとに基本的な手法を紹介したいと思います。コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずにソースコードの内部構造を整理することである。いくつかのリファクタリング手法の総称としても使われる。十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。(Wikipediaより抜粋)※ここでいう「プログラムの外部から見た動作を変えず」というのは、リファクタリング前後で、リファクタリングする対象が行う処理の結果を変えないという意味です。■HoudiniでのリファクタリングHoudiniでの作業はプログラミング色が強く、ノードネットワークを組み立てることはプログラミングすることそのものと言えます。ノードネットワークは、ある種ソースコードのようなものです。HoudiniではVEX/Wrangle/Pythonなど、プログラミングそのものを行う要素も含んでいます。そのため「リファクタリング」手法のいくつかをHoudiniでも比較的素直に取り入れることができます。■リファクタリングのメリットリファクタリングにより、ノードネットワークの構造を整理することができ、結果として以下のようなメリットが得られます。□名前の変更ノード名、パラメータ名、アトリビュート名、Wrangleの変数名など、各種「名前付きの要素」を、誰が見てもわかりやすい形にリネームします。これにより、その要素の役割が判断しやすくなり、時間が経ってから見直したときや、他人へデータを渡したときに処理の内容を理解する助けになります。部分だけでノードごとの基本的な動作が伝わりますその要素が何を行うものであるか判断できるよう、名前の先頭に目的に応じたプリフィクスを追加します。ルールに則ったプリフィクスを利用すると、ひと目でその要素が大雑把にどのような動作をするものか判断しやすくなり、メンテナンス性が向上します。ノード名はそのノードの動作に適した動詞をプリフィクスにします。変数名の場合も同様に、変数の役割がわかるようなプリフィクスをつけます。このようにしておけば、ノードリストなどでノードを検索する際のヒントにもなります。test_・意味のある名前についてaaaaaaaaaaaは最終的に必要?目的は?1年後に思い出せる気がしません・・・プログラミング学び初めの頃によくやってしまいがちなことの一つに、実験用の変数のような「瞬間的にほしい要素」に対し、一見して意味のない名前をつけるということがあります。これは、実験中はいいのですが、実験終了後にこの要素が不要となったにもかかわらず、要素を消し忘れたまま時間が経ってしまった時に問題を引き起こします。このような要素は本来不要であるにもかかわらず、なんとなくまだ必要そうな気がしてしまい、出来上がった仕組みを壊してしまうことに対する恐れも手伝い、消せないまま放置してしまったことがある方は多いのではないでしょうか。実験用に作った要素が最終的に採用され、利用されることになるケースもあります。このような場合も、はじめから意味のある名前をつけておけば、名前を修正する手間が省けて一石二鳥です。miewaaaaaa※ループカウンターで使われる[i,j,k]や、座標を表現する際に使われる[x,y,z][u,v,w]などは、それ単体では意味のないアルファベットですが、一般的な名前として広く認知されているので、意味を持っています。そのため、使用しても何ら問題ありません。いくつか種類があります。目にする主な記法はだいたい以下の3通りだと思います。CalcCutDistancePointNumPrimAreaAddTwoPoints筆者は最近、Pythonのコード規約であるPEP8にならうことが多いです。具体的に言うと以下のようなルールに従っています。・略称について略しすぎると、そのノードの役割が全くわからなくなります名前付き要素に略称を使うことは可読性を損なう一因となります。メンテナンス性を高めるためには、極力名前のパーツに略称を使わないことが望ましいといえます。あるノードを「calc_center_position」という具体的な名前にする場合を考えます。このとき、「position」という言葉が長すぎると感じるかもしれません。そのような場合、略称を使いたくなります。ここで「position」を「p」と極端に略した場合、その「p」がどのような意味合いで選択された名前なのか第三者には瞬時に理解できません。(もちろん前後の文脈から想像はできますが、瞬時に理解するのは難しいでしょう)もしかしたら、数日後の自分ですらその「p」が何なのか即答できないかもしれません。そこで、この「position」という文字列を、一般的によく使われる「pos」という略称に置き換えるのは悪くない考えです。前後の文脈によっては「pos」から「positive」など、別の言葉を連想する可能性もあり得るので、意味をはっきり伝えるという意味では少し確実性に欠けます。いえ名前が長くなりすぎるのも困りものです。実際のところ、若干の読みやすさを犠牲にして、明らかに一般的な共通認識として定着している略称のみを必要最小限の範囲で使用するのが良い落とし所となるでしょう。nm,・長すぎる名前について長過ぎる名前は、詳細はわかりますが不便です適度に略称を取り入れながら、ほどほどの長さに収めましょう名前の文字数は長くても20文字~30文字までといった意見をよく見かけます。確かに長い名前はコードが複雑化すると全体が見づらくなる原因になります。した文章のような長さの名前はおすすめできません。省略しすぎて意味が全くわからない名前よりは遥かに良いです。短すぎる名前を使うくらいなら、意味のわかる長い名前を使いましょう。CodeやSublimeなどに、対応する言語のプラグインをインストールして外部エディタとして利用すると、インテリセンス(コード補完機能)が使えるようになります。Houdini内ではノードパスなどでインテリセンスが利用できます。そのため、多少長い名前を使用していても間違いなく簡単に入力できるうえに、いざ名前が長すぎたと感じる場合でも、エディタの機能で特定の対象だけ簡単にリネームできるので、さほど問題になりません。上記を踏まえた上で、具体的な名付けの例を挙げてみます。point_numベクトルAとBの内積を格納する変数名dot_A_B□アルゴリズムの更新とテストcompare_geometryでunittestを行いながら処理を分解リファクタリングの重要なポイントに、処理の内容を変えずに構造を整理するということを挙げました。そのためには、リファクタリングの前後で結果に差がないことを確認しながら作業をすることが重要です。通常のプログラミングでのリファクタリングは以下のように進めます。リファクタリング対象を複製し、もとのロジックをとっておきます。リファクタリング後の処理がどうなっていれば正解なのか判断できるデータを作ります。このデータを、リファクタリング後の処理結果と常時比較しながら、結果が異なる場合に即座に検知するために使います。この比較は、一般的にユニットテストと呼ばれます。リファクタリング語の処理結果が、リファクタリング前と同じであることを確認しながら構造の修正を行います。リファクタリング対象のノードや一連のノードチェーンを複製、分流。SOPを作成し、分流したノードの出力を接続します。SOPでリファクタリング前後の結果を簡単にスイッチして確認しやすくします。ジオメトリのアトリビュートを比較するユニットテスト用HDAを作成してもいいでしょう。リファクタリング前後で結果が同じであることを確認しながら構造の修正を行います。□関心の分離1つのWrangleに3種類の処理が含まれていたので分解した例1つのノードでは、1度に1種類の処理のみを行うようにします。SOPでは色を設定することのみを行うようにします。SOPでは、色を設定すると同時に法線を設定するように複数種類の処理をさせることはしません。色の設定と別に法線を設定する必要がある場合、2つの処理を切り分けて別々のノードを作成し、それぞれで処理を行います。処理を切り分けることでその処理が影響する範囲が小さくなります。これにより、この処理に対する何らかの変更が必要な場合に気を配る必要にある範囲が小さくなります。これが「関心を分離する」ということです。関心を分離した結果、それぞれの処理に変更を加えたい場合や、ある処理の前後に新たな処理を追加する場合に、変更すべき箇所がわかりやすくなります。ノードを切り分ける場合は、処理のステップが複数のノードに分かれるので、各ノードのVisibilityフラグを切り替えながら、各処理ごとの結果が確認しやすくなります。Wrangleの場合、コード中の特定の行で処理を止めて途中経過を確認するようなデバッグ機能がないので、Wrangleコードとそのコードで使われるパラメータを機能単位のWrangleに切り分けて関心を分離することになります。整理された5つの処理を、1つのsubnetに集約したHoudiniに限らず一般的なプログラミングでは、複数の小さな処理を積み重ねて大きな処理を組み立てていきます。Houdiniでは、複数のノードをSubnetノードにパックしてまとめることができます。複数の小さな処理で成り立つ大きな処理をパックすることで、処理のくくりが明確になり、ノードネットワークの見通しが良くなります。これは一見すると、上で挙げた「関心の分離」に反するように見えます。たしかに、何も考えずにSubnetに複数のノードをまとめてしまうと、むしろノードネットワークが俯瞰しづらくなり、混乱の原因になります。そのため、処理を集約する際は、必ず集約する処理に対し関心の分離を適用します。複数の処理を一つのSubnetにまとめるタイミングは、関心の分離を適用する前でも後でも問題ありません。関心の分離を適用するとノードが増えます。ノードネットワーク全体が膨大なノード数で構成されていて、これ以上ノードを増やすと視覚的に全体を俯瞰しづらくなる場合などは、先に関心の分離を適用する処理の範囲をSubnetにまとめておき、そのSubnet内で適用することで、その他の箇所に気を取られずに作業できるようになります。これもまた、ノードネットワーク全体を巨大な処理と見立てた関心の分離とも呼べます。一心不乱にノードネットワークを作成していると、途中で行ったコピー&ペーストの影響なども手伝い、全く同じ処理を随所で繰り返している事態に陥ることがあります。同じ処理が複数箇所にあり、それぞれの処理に同じ変更を加えたい場合、それぞれに対し個別に同じ変更を加えるのは現実的とは言えません。このような場合、処理を切り出して再利用できるようにします。その後、切り出した再利用可能な処理で各所の重複部分を置き換えることで、その後の処理変更が1箇所で行えるようになります。・HDASubnetにまとめた仕組みは、デジタルアセットに変換することで再利用が簡単になります。Blockを通して、一連の処理を再利用できます。他にも多くのリファクタリングテクニックがあるのですが、ここでは基本的なものに絞って紹介させていただきました。タイムリミットも迫り記事も長くなってしまったので、より実践的なリファクタリングの実例紹介は別の機会に・・・この記事について、なにかご質問や間違いがありましたら遠慮なくツッコミをいただけると助かります。最後に、個人的にリファクタリング関連で参考になったと感じる書籍をいくつか紹介します。Houdiniはそもそもプログラミングツールではないため、これらの書籍で紹介されるすべてのテクニックが適用できるわけではありませんが、多くの点で役立ちます。(今回ご紹介したリファクタリングや、Wrangle、Pythonでコーディングする際など)特に「レガシーコード改善ガイド」の方は、古いコードのメンテナンスに際し起こりうる様々な問題ごとに適用できる、リファクタリングとテストを使うコード改善テクニックが紹介されています。今回紹介したユニットテストを使う安全な開発方法(テスト駆動開発)も、こちらの書籍から着想を得ています。興味のある方はぜひ読んでみてください。Yamabe.Michiyoshi返信パラメータ名の確認まず最初に、パラメータへアクセスする際はパラメータ名が重要になるので、名前の確認方法から。Sheetで、ノードとパラメータをツリー表示で確認できる。各項目名の右端にある、カッコで囲まれた名前が実際にアクセスする際に使用するパラメータ名。Scaleのような単一の値を持つパラメータと、位置や回転など、複数の値をひとまとめにして持つ配列パラメータがある。Divisionsという「ラベル」が付けられたパラメータは、実際の名前が「divrate」であり、3つの子要素(divratex/y/z)を持っている配列パラメータである事がわかる。Editorに、パラメータラベルをドラッグ&ドロップすることで正しい配列パラメータのパスと名前が確認できる。ポップアップウインドウで確認Parametersパネルなどでパラメータ名ラベルの上にマウスカーソルを置き、少し待つと、パラメータ情報がポップアップで表示される。この中の、Parametersの部分にある文字列が、このノードにおけるパラメータの正式な名前になる。パラメータ名であると確認できるが、あくまでも配列要素の単一パラメータ名のみがわかる。Sheetを確認するなど一手間必要。node.parm('parm_name')単一パラメータの値を取得するeval~と名づけられたメソッドを使う。型を指定して型変換しながら値を取得するメソッドや、時間指定で値を取得するメソッド、それらを組み合わせて取得するメソッドなどもある。)パラメータをセットする値のセットは、set系メソッドを使う。事前に組み立てたパラメータ辞書をsetParmsメソッドに与え、一括で値をセットするのがとても楽なのでおすすめ。その際、setParmsメソッドでは配列パラメータ名は認識できないので、各要素を個別の単一パラメータとして辞書に値を用意します。Yamabe.Michiyoshi返信あるシーンを開いた時、膨大なオブジェクト数とグループ数により階層が深く、なおかつすべてのノードに命名規則が全く見当たらないという、ツール作成者視点でシーンを眺めた時、ついつい汚い床の上をのたうち回りたくなるような状況は往々にしてあることなのですが、そのような状況下でのHoudiniの選択操作は、他のDCCツールよりも遅れを取っている気がします。ビューポートで選択しているすべてのノードの親を簡単にまとめて再選択したかったり、同様に、選択アイテムのすべての下流ノードをまとめて選択したかったりと言った状況です。ノードを右クリックして表示されるポップアップメニューから、Inputs/Outputsサブメニューを駆使してみるも、単一の選択アイテムのみがノード検索の起点になるので、複数のノードツリーをまとめて選択できなかったりします。このように、意外とHoudiniデフォルトの選択機能に痒いところが多かったので、選択補助スクリプトを書いてみました。ついでと言ってしまうと何だか申し訳なく感じてしまうのですが、簡単なメモを書き残したいと思います。)かなり基本的なところではこんな感じ。他にもたくさんあるので、その他のメソッドは要マニュアル参照。出力の全子孫を取得するメソッドがパット見見つからない感じだったので、再帰的に子孫をたどる関数を作ってみる。選択解除node.setSelected(0)上記を組み合わせて、現在のノードから1つ上流のノードを探し、再度全下流ノードを探して全選択を行うなどの便利なコマンドを作成できます。ワンランク上のキャラクターリギング」に、株式会社コロッサス名義で「ダイナミックコントロールリグのためのツール活用術」というタイトルの記事を寄稿させていただきました。地味に手間のかかる馬の手綱セットアップを例として、ダイナミックリグの作成方法と、ツールによって作業を簡単化する方法を紹介しています。2.0によるOpenMayaの基本的な使い方の解説と、メッシュ上の最近接点の取得や、カーブ上の一点が持つ各ベクトルからのマトリクス組み立てといった、覚えておくと色々な場面で役に立つ内容も盛り込んでみました。現在在籍している「株式会社コロッサス」のブログにて、ツールの配布等もしておりますので、ぜひ本誌を手に取っていただけると幸いです。18日目に投稿させていただいた記事です■はじめにHoudiniには外部デバイスからインタラクティブにデータを入力する機能があります。今回は、その機能を利用して外部に接続した各種フィジカルデバイスの操作から、Houdiniへデータを入力する方法を色々と書いてみたいと思います。手頃に試せそうな例として、ここでは以下のデバイスからの入力を試してみます。CHOP・CHOPデータの在り処についてCHOPのデータは、「CHOPチャンネル」が持っています。CHOPチャンネルのデータへアクセスする際は、CHOPノードだけではなく、CHOPノード内にあるCHOPチャンネル名まで指定する必要があります。・CHOPデータの詳細確認CHOPノードを中ボタンでクリックするとCHOP内のチャンネル数や、開始/終了フレーム、サンプルレートなどの詳細情報が表示されます。赤く囲んだ部分には、このCHOPに含まれるチャンネル名と値が表示されています。この例の場合、ステレオのオーディオファイルを読み込んでいるので、このCHOPには左右2チャンネルの波形データが含まれていることがわかります。割り当てられています。チャンネルへのフルパスは以下のようになります/obj/driver_chopnet/WAV_FILE/chan0・CHOPチャンネルへのアクセスCHOPチャンネルの各情報は、chop系エクスプレッション関数を使って取得します。これらの詳細はマニュアルを参照してください。先の例で登場したCHOPチャンネルが持つ現在時間のデータが欲しい場合は、データを呼び込むパラメータボックス内で以下のエクスプレッションを使用します。Viewに表示されます。View・CHOPデータのサンプルレートCHOPでは様々な波形データを扱うことができます。波形データは自由に再生時のサンプルレート(一秒あたりのデータ数)を指定できるようになっています。サンプルレートの高いオーディオデータを30fps設定のシーンでアニメーションカーブとして使う場合、サンプルレートを30にリサンプルしてから使用するのが負荷軽減につながって良いのではないかと思います。Rateパラメータで指定します。・上で読み込んだWAVデータの波形を30fps化したところ・外部から入力されたデータのレコーディング外部から入力されたデータを記録しておき、再生することができます。CHOPを下流に接続してそちらで記録するほうがデータの取り回しの面で良いと思います。パラメータをオンにした状態で行います。CHOPの簡単なチュートリアルで作業の流れを掴んでみます。CHOPのRecordパラメータをOnにし、シーンを再生しますこの時、シーンのリアルタイム再生モードをオンにしておくと実際のフレームレートでレコーディングできます。Onceにしておくことでリピート再生をオフにし、うっかり開始フレーム付近を書き換えてしまうのを防げます。6・マウスカーソルを自由に動かし、グラフが描かれていくのを確認します各カーブの上には、対応するカラーでチャンネル名が表示されています。CHOPのRecordをOffにします8・/obj/に新たにBoxオブジェクトを作ります9・boxオブジェクトのTranslateX/Yにエクスプレッションを設定します・TranslateXchop(“../../ch/ch1/record1/geo1:tx”)・TranslateYchop(“../../ch/ch1/record1/geo1:ty”)10・シーンを再生して結果を確認しますboxオブジェクトが、マウスが動いたとおりに移動するのが確認できます。Tabletをオンにして、同様の操作をすることで、筆圧やペンの傾きなどを検知し、記録できる事がわかると思います。Scaleパラメータにアサインすると楽しいかもしれません。■データ入力手順のまとめこれが外部入力系のCHOPを使うワークフローの基本的な手順です。手順をまとめると以下のようになります。1・外部入力を受け付けるCHOPを作成2・CHOPにデータの窓口となるCHOPチャンネルを作成3・任意のパラメータからchop関連のエクスプレッション関数でCHOPチャンネルのデータを参照するこれはその他のデータ入力CHOPを使った場合も同様です。これだけ理解できれば、あとは応用して色々できるはず。