Houdiniプラグイン開発備忘録4 ~ カスタムSOPにカスタムパラメータを追加する編

今回は、カスタムノードにカスタムパラメータを追加してみます


VerbとProtoヘッダファイル

 最近のHDKでは、SOPノード作成にVerbという仕組みを使うことが多いようです。
 Verbというのは、かなりざっくりいうと、SOPの振る舞いを定義する際、ジオメトリへの処理と、それ以外のパラメータ操作などの処理を分離する仕組みです。

[参考]プログラム的にVerb(動詞)を使ったジオメトリ

 Verbを利用してSOPを作成する際、これまで何度か言及していた、「Protoヘッダファイル」をビルド手順の中で生成し利用することになります。


Protoヘッダファイルの主な役割

 Protoヘッダファイルには、ジオメトリ処理以外の実装が自動的に記述されます。

※これは現時点での理解なので間違っているかもしれませんが、この仕組みにより、開発者は面倒なパラメータとジオメトリ処理をつなぐ実装を省略し、主にジオメトリ操作に関する処理に注力すれば良くなります。

 主なProtoヘッダファイルの役割は以下のようなものになります。

  1. PRM_Templateを生成する
  2. パラメータの操作を簡単化する関数群を自動生成する

Protoヘッダファイルの作り方

 Protoヘッダファイルは何もしなくても勝手に作成されるわけではなく、ソースコードの中にそのノードがどのようなパラメータを持っているかを示す「Dialog Script」を記述、または「*.ds形式のファイル」として用意して、PRM_TemplateBuilderに与える必要があります。

 このDialog Scriptは、ソースコード中で *theDsFile に記述します。

static const char *theDsFile = R"THEDSFILE(
・・・
)THEDSFILE";
//SOP_Starの例

static const char *theDsFile = R"THEDSFILE(
{
    name        parameters
    parm {
        name    "divs"      // Internal parameter name
        label   "Divisions" // Descriptive parameter name for user interface
        type    integer
        default { "5" }     // Default for this parameter on new nodes
        range   { 2! 50 }   // The value is prevented from going below 2 at all.
                            // The UI slider goes up to 50, but the value can go higher.
        export  all         // This makes the parameter show up in the toolbox
                            // above the viewport when it's in the node's state.
    }
    parm {
        name    "rad"
        label   "Radius"
        type    vector2
        size    2           // 2 components in a vector2
        default { "1" "0.3" } // Outside and inside radius defaults
    }
    parm {
        name    "nradius"
        label   "Allow Negative Radius"
        type    toggle
        default { "0" }
    }
    parm {
        name    "t"
        label   "Center"
        type    vector
        size    3           // 3 components in a vector
        default { "0" "0" "0" }
    }
    parm {
        name    "orient"
        label   "Orientation"
        type    ordinal
        default { "0" }     // Default to first entry in menu, "xy"
        menu    {
            "xy"    "XY Plane"
            "yz"    "YZ Plane"
            "zx"    "ZX Plane"
        }
    }
}
)THEDSFILE";

Dialog Scriptを生成する

 頑張って調べてみましたが、この記事を執筆している時点では、Dialog Scriptに関するリファレンスマニュアルのようなものを見つけることは出来ませんでした。
 そのかわり、リファレンスに頼ってフルスクラッチで書かなくとも、簡単にDialog Scriptを生成する方法があったので紹介します。

 やり方は、概ね以下の手順になります。

  1. パラメータ定義を抽出するためHDAを作成
  2. HDAに、カスタムノードに持たせたいパラメータを作成
  3. HDAのhou.ParmTemplateGroup.asDialogScript()でDialog Scriptのコードを取得
# Dialog Scriptを出力するサンプル
hda_node = hou.node("/to/hda/node/path")
hda_type = hda_node.type()
hda_definition = hda_type.definition()
hda_parm_template_group = hda_definition.parmTemplateGroup()
hda_dialog_script = hda_parm_template_group.asDialogScript()
print(hda_dialog_script)

 これにより、そのHDAに定義されたパラメータ定義が、Dialog Scriptの形式で取得できます。

 その後、ソースコードの*theDsFileに、取得したコードをそのままコピペするなどして与えた後、いつも通りの手順でビルドするだけです。


テスト

 以下は、HDAとして標準で用意されているColor SOPからDialog Scriptを頂いて、カスタムSOPにそのまま持たせてみたものです。


以上、カスタムSOPにカスタムパラメータを追加する方法でした。
なにか間違いや、不明な点などあれば、コメントいただけると嬉しいです。

AppleデバイスのLiDARスキャナとHoudini

 最近のiPad ProやiPhone 12 Pro / Maxに搭載されているLiDARスキャナで取得した点群をHoudiniに取り込んでみるテストをしたのでメモ。

使用機材

iPad Pro 2020
Houdini 18.5.351
pronoPointsScan

PCにファイルを転送する

  • pronoPointsScanで点群をスキャンし、ファイルとして保存します
  • iOSのファイルアプリで、「このiPad内 → pronoPointScan」を開きます
  • 先程保存した目的のファイルを「コピー」
  • PCから参照しやすい場所に「ペースト」
    • 今回は、OneDrive経由でPCにファイルを転送しました

Houdiniでファイルを開く

Table Import SOPを作り、先程PCに転送したtxtファイルを開きます。

pronoPointsScanから出力されるデータは非常にシンプルで、以下のようなフォーマットになっています。

各行が一つ一つのポイント情報に相当し、各行にはそれぞれ以下のように数字が羅列されています。

@P.x,@P.y,@P.z,@Cd.r,@Cd.g,@Cd.b


@Cdを修正

pronoPointsScanで生成した点群データのカラー値は0-255なので、Wrangleを書いて0-1に修正します。

v@Cd = fit(v@Cd, {0,0,0}, {255,255,255}, {0,0,0}, {1,1,1});

方向を修正

Bound SOPで点群のOBBと、OBBをまっすぐに戻すためのxformアトリビュートを作成


点群ジオメトリにxformアトリビュートをコピー

Attribute Copy SOPで、点群ジオメトリにOBBのxformアトリビュートをコピーする


点群の軸を修正する

Match Size SOPで、Bound SOPで生成されたxformアトリビュートを使い、点群の軸を修正する

今回は点群の撮影場所が室内だったこともあり、たまたまいい方向に向いてくれましたが、点群の形状によっては全く見当違いな方向に向く可能性があるので、その場合は適宜、いい感じに工夫する必要があります。


問題点

  • Table Import SOPが非常に遅い
    • Pythonでやるなら先にtxtを解釈し、行数分のポイントを作成した後、アトリビュート配列を組み立ててから、hou.Geometry.setPointFloatAttribValues(name, values)を使って、一括でセットするなどしてタイムロスを最小限に抑える必要がありそう。
  • ポイントにはそもそも法線情報がないので、Poinit Cloud Iso SOPなどで面を貼るためには下準備が必要

以上、手軽にLiDARスキャナで遊べる小ネタでした。

Houdiniプラグイン開発備忘録3 ~ 最小構成のテンプレを書いてみる編

最近、どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。

今回は、SOP_Starのサンプルコードを参考にしながら、全く何の処理もパラメータも持たない、空っぽのSOPを作る最小構成のコードを書いてみました。

が、事細かにコードの説明を書いてもとりとめが無くなりすぎて、読むに耐えない感じになり非常に微妙だったので、簡単な解説付きのテンプレートコードを転載するに留めます。

いくつか補足が必要そうな箇所もあるので、後でメモを書くかも。

※コメント中の

TODO:は要編集の箇所
NOTE:はメモ

VSCodeでTODO Highlightなどを使うと見やすいかも

名前規則

サンプルを見る限り、以下のようなルールで各要素に名付けを行うのが通例っぽいです
以下は、templateというラベル名のSOPの場合

■各ファイル
SOP_Template.cpp
SOP_Template.hpp
SOP_Template.proto.h

■コード内の各要素
SOP_Template         カスタムSOPクラス名
SOP_TemplateVerb     カスタムNodeVerbクラス名
SOP_TemplateParms    カスタムSOPのパラメータテンプレートクラス名

SOP_Template.hpp(.h)

最小構成のヘッダファイルは以下のようなものになりそう。

// TODO: インクルードガードはカスタムSOPクラス名に合わせ指定
#ifndef __SOP_Template_h__
#define __SOP_Template_h__

// NOTE: 編集不要
#include <SOP/SOP_Node.h>
#include <UT/UT_StringHolder.h>

// TODO: ネームスペースを書き換える
namespace SOP_TEMPLATE
{
    // NOTE: ここではSOP_Nodeクラスを継承し、カスタムのSOPクラスを宣言する
    // TODO: カスタムSOPクラスを指定
    class SOP_Template : public SOP_Node
    {
    public:
        static OP_Node *myConstructor(OP_Network *net, const char *name, OP_Operator *op)
        {
            // NOTE: 自身のインスタンスを返すようにする
            // TODO: カスタムSOPクラスを指定
            return new SOP_Template(net, name, op);
        }

        // NOTE: 以下は編集不要
        static PRM_Template *buildTemplates();                 // パラメータテンプレートクラスを返す
        virtual const SOP_NodeVerb *cookVerb() const override; // Verbの仕組みで処理を行うメソッド
        static const UT_StringHolder theSOPTypeName;           // ノードタイプの内部名を格納する変数

    protected:
        // NOTE: コンストラクタを定義
        // TODO: カスタムSOPクラス名を指定
        SOP_Template(OP_Network *net, const char *name, OP_Operator *op) : SOP_Node(net, name, op)
        {
            mySopFlags.setManagesDataIDs(true);
        }

        // NOTE: デストラクタを定義
        // TODO: カスタムSOPクラス名を指定
        virtual ~SOP_Template() {}

        // NOTE: 以下は編集不要
        virtual OP_ERROR cookMySop(OP_Context &context) override
        {
            return cookMyselfAsVerb(context);
        }
    };
} // namespace SOP_TEMPLATE

#endif

SOP_Template.cpp(.C)

最小構成のソースコードは以下のようになりそう。

// NOTE: このテンプレはprotoヘッダファイルを使用する前提のもの
// TODO: インクルードするファイル名を書き換える
#include "SOP_Template.hpp"
#include "SOP_Template.proto.h" // protoヘッダを使うことが前提

// NOTE: 最低限必要なヘッダファイルのインクルード
#include <UT/UT_StringHolder.h>
#include <UT/UT_DSOVersion.h>
#include <OP/OP_Operator.h>
#include <OP/OP_OperatorTable.h>
#include <PRM/PRM_TemplateBuilder.h>


// TODO: 任意のネームスペースを指定
using namespace SOP_TEMPLATE;

// TODO: カスタムSOPクラスを指定
// TODO: 任意の内部名を指定
const UT_StringHolder SOP_Template::theSOPTypeName("template"_sh);

// NOTE: プラグインロード時にOP_OperatorTableにカスタムSOPを登録する
void newSopOperator(OP_OperatorTable *table)
{
    table->addOperator(new OP_Operator(
        // TODO: 必要に応じて書き換える
        SOP_Template::theSOPTypeName,   // SOPの内部名
        "template",                     // SOPのラベル名
        SOP_Template::myConstructor,    // 自身のインスタンスを返すメソッド
        SOP_Template::buildTemplates(), // パラメータテンプレートを指定
        0,                              // 最低限必要な入力数
        0,                              // 入力プラグの数
        nullptr,                        // Custom local variables (none)
        OP_FLAG_GENERATOR));            // Flag it as generator
}

// NOTE: SOPに持たせるパラメータを定義する
// TODO: .dsファイル、または.dsファイルと同様のルールで書かれたraw文字列を代入する
static const char *theDsFile = R"THEDSFILE(
{
        name        parameters
}
)THEDSFILE";

// NOTE: *theDsFile で記述された内容をもとにパラメータテンプレートを生成する
// TODO: カスタムSOPクラスを指定
// TODO: 正しいcppファイル名に書き換える
PRM_Template *SOP_Template::buildTemplates()
{
    static PRM_TemplateBuilder templ("SOP_Template.cpp"_sh, theDsFile);
    return templ.templates();
}

// NOTE: Verbの仕組みを使うため、カスタムNodeVerbクラスを宣言
// TODO: カスタムNodeVerbクラス名を指定
class SOP_TemplateVerb : public SOP_NodeVerb
{
public:
    // NOTE: デフォルトコンストラクタとデストラクタ
    // TODO: カスタムNodeVerbクラス名を指定
    SOP_TemplateVerb() {}
    virtual ~SOP_TemplateVerb() {}

    // TODO: protoヘッダで定義されているパラメータテンプレートクラスを指定
    virtual SOP_NodeParms *allocParms() const
    {
        return new SOP_TemplateParms();
    }

    // NOTE: theVerbメンバ変数の宣言
    // TODO: カスタムNodeVerbクラスを指定
    static const SOP_NodeVerb::Register<SOP_TemplateVerb> theVerb;

    virtual UT_StringHolder name() const
    {
        // TODO: カスタムSOPクラスを指定
        return SOP_Template::theSOPTypeName;
    }

    // NOTE: 編集不要
    virtual CookMode cookMode(const SOP_NodeParms *parms) const
    {
        return COOK_GENERIC;
    }

    // NOTE: 編集不要
    virtual void cook(const CookParms &cookparms) const;
};

// NOTE: 静的なメンバ変数の定義はクラス定義の外に書く
// TODO: カスタムNodeVerbクラスを指定
const SOP_NodeVerb::Register<SOP_TemplateVerb> SOP_TemplateVerb::theVerb;

// TODO: カスタムSOPクラスを指定
const SOP_NodeVerb *SOP_Template::cookVerb() const
{
    return SOP_TemplateVerb::theVerb.get();
}

// NOTE: SOPのメイン処理 Verbを使う場合はSOP_NodeVerbのcookに実際の処理を委譲する
// TODO: カスタムNodeVerbクラスを指定
void SOP_TemplateVerb::cook(const SOP_NodeVerb::CookParms &cookparms) const
{
    // TODO: ノードのメイン処理はここに記述する
}

CmakeLists.txt

CMakeLists.txtは、自分の環境ではだいぶいじってしまっているため、サンプルを少し改変しただけの状態ではちゃんとテストできてないので、動作に若干自信なし。
もし実践してみたい方がいれば、と思い、参考程度にコードを載せてみますが、間違ってたらすみません。(大まかには合ってるはずですが)

CMakeLists.txtファイルは、サンプルを以下のような形で編集し、ソースコードと同じフォルダに置けば、以前の説明と同じ手順でビルドできると思われます。

# NOTE: 変更不要 対応するcmakeの最小バージョン
cmake_minimum_required( VERSION 3.6 )

# NOTE: sln内に作成するプロジェクト名
# TODO: 任意の名前を指定。カスタムSOPクラス名が良さそう
project(SOP_Template)

# NOTE: 変更不要 cmakeファイル検索パスを追加
list( APPEND CMAKE_PREFIX_PATH "$ENV{HFS}/toolkit/cmake" )

# NOTE: Houdiniが用意しているcmake関数などを含むパッケージを読みこむ
find_package( Houdini REQUIRED )

# NOTE: ライブラリ名変数にカスタムSOPクラス名の文字列を代入しておく
# TODO: ライブラリ名を変更SOP_TemplateのようにカスタムSOPクラス名にするとよい
set(library_name SOP_Template)

# NOTE: ここの指定でprotoヘッダが作られるようになる
# TODO: ソースコードファイル名(.c/.cpp)を記述
# NOTE: 初投稿で間違いがあったので修正した
houdini_generate_proto_headers( FILES SOP_Template.cpp )

# NOTE: ライブラリに追加するファイルを記述
# TODO: 必要なcpp/hppファイルを羅列する
add_library( ${library_name} SHARED
    SOP_Template.cpp
    SOP_Template.hpp
)

# NOTE: 変更不要
target_link_libraries( ${library_name} Houdini )

# NOTE: 変更不要
target_include_directories( ${library_name} PRIVATE
    ${CMAKE_CURRENT_BINARY_DIR}
)

# NOTE: 変更不要
# TODO: 必要に応じてオプションを追加
houdini_configure_target( ${library_name} )

Houdiniプラグイン開発備忘録2 ~ CMakeでのビルド編

最近、どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。

HDKリファレンスには、「Visual Studio IDEからビルドする場合は、代わりにCMakeを使用することをお勧めします。」との記載があります。

また、「hcustomによるビルドでは単一のソースファイルしか扱えない」旨の記述もあり、hcustomは手軽ではあるけど不便だろうなぁと想像しています。

というわけで、今後使い続けることになりそうなCMakeでのビルドを知るため、前回のhcustomによるビルドに引き続き、CMakeを使うビルドを試してみようと思います。

今回もサンプルの「SOP_Star」を使います。


■CMakeとは?

CMakeは、プログラムのビルド処理を自動化してくれる便利ツールです。
今回CMakeで行う処理は、大きく分けて以下の2つです。

・Visual Studioのソリューションとプロジェクトの自動生成
・自動生成されたそれらのファイルを使ってビルドを行う


■環境の準備

まず、手元の環境ですが、以下のようなツールがインストールされています。

Houdini 18.0.532 Indie
Visual Studio 2019 / 2017 / 2015 Community
CMake 3.18.1


■ビルド手順

・ソースコードをコピーする

以下のフォルダを、任意の場所にコピーします。
今回は、以下のようにコピーしました。

コピー元:$HFS\toolkit\samples\SOP\SOP_Star
コピー先:D:\temp\HDK\build_cmake\SOP_Star

※$HFSは、Houdiniのインストールフォルダで、デフォルトでは以下のようなパス

C:\Program Files\Side Effects Software\Houdini 18.0.532

・Command Line Toolsを起動する

スタートメニューで「Command Line Tools」と検索し、起動します。
「Command Line Tools 18.0.532」というタイトルの、Houdini関連の環境変数が一通り自動的にセットされたコマンドプロンプトが立ち上がります。

※どんな環境変数がセットされているかは「set」と打ち込んでEnterを押すことで一覧表示、確認できます。


・ソリューションとプロジェクトを生成する

CMakeでソリューションの生成を実行すると、カレントのフォルダに、Visual Studioのソリューションファイル以外にも、いろいろなファイルが大量に生成されます。

これらの生成されたファイルがソースコードと混ざってしまうと、生成前の状態に戻すことが難しくなります。

そのため、予めビルド生成物をまとめるbuildフォルダをつくり、もとのソースコードとCMakeの生成ファイルを切り分けて管理できるようにします。

まずソースコードと同じフォルダにbuildという名前のフォルダを作ります。

D:\temp\HDK\build_cmake\SOP_Star\build

Command Line Toolsで以下を実行し、カレントのフォルダをbuildフォルダに移動します

cd /d D:\temp\HDK\build_cmake\SOP_Star\build

次に、以下を実行し、ソリューションとプロジェクトを生成します。

cmake ..

カレントのbuildフォルダに、各種ファイルが生成されます。

ここで生成されるソリューションとプロジェクトは、SOP_Starフォルダの直下にあるCMakeLists.txtファイルに記述された設定に基づいて作成されます。

カスタムプラグインを作成するためのCMakeLists.txtを書く際は、このCMakeLists.txtを参考にすれば良さそうです。


・プラグインをビルドする

続いて、以下を実行します。

cmake --build . --clean-first

これで、カレントのフォルダにあるソリューションとプロジェクトファイルを使い、プラグインが以下のフォルダにビルドされます。

%USERPROFILE%\Documents\houdini18.0\dso
SOP_Star.dll
SOP_Star.exp
SOP_Star.ilk
SOP_Star.lib
SOP_Star.pdb

・Houdiniでプラグインの動作を確認する

・Houdiniを起動
・Geometryを内でTABメニューから[star]と検索し[Star]ノードを作成
・無事ビューポート内に星型のジオメトリが現れればOKです。


ここまでで、hcustomとCMakeのそれぞれを使って、手軽にプラグインがビルドできることを確認してみました。

同じ要領で、サンプルにある各種プラグインをビルドすることができそうです。

Houdiniプラグイン開発備忘録1 ~ hcustomでのビルド編

最近どうしても自作したいSOPがあり、Windows環境でのHoudiniのプラグイン開発を少しずつ学び始めたので、忘れないようにメモしていこうと思います。

HDKリファレンスによるとHoudiniプラグインは、hcustomを使うことで簡単にビルドできるらしかったので、まずは初歩中の初歩として、最も簡単そうなこの方法から試してみました。

今回使用するコードは、サンプルにある「SOP_Star」です。


■環境の準備

まず、手元の環境ですが、以下のような状態です

  • Houdini 18.0.532 Indie
  • Visual Studio 2019 / 2017 / 2015 Community

■ビルド手順

・ソースコードをコピーする

以下のフォルダを、任意の場所にコピーします
今回は、以下のようにコピーしました

コピー元:$HFS\toolkit\samples\SOP\SOP_Star
コピー先:D:\temp\SOP_Star

※$HFSは、Houdiniのインストールフォルダで、デフォルトでは以下のようなパス

C:\Program Files\Side Effects Software\Houdini 18.0.532

・Command Line Toolsを起動する

スタートメニューで「Command Line Tools」と検索し、起動します。
「Command Line Tools 18.0.532」というタイトルの、Houdini関連の環境変数が一通り自動的にセットされたコマンドプロンプトが立ち上がります。

※どんな環境変数がセットされているかは「set」と打ち込んでEnterを押すことで一覧表示、確認できます。


・ソースコードのあるフォルダをカレントにします

cd /d D:\temp\SOP_Star

・protoヘッダファイルを作成します

generate_proto.pyを利用し、SOPプラグインのコード内で、ノードのパラメータを定義している文字列(theDsFile)の記述をもとに、パラメータへのアクセスを簡単にしてくれるprotoヘッダファイルを自動生成しておきます。

hython %HH%/python2.7libs/generate_proto.py SOP_Star.C SOP_Star.proto.h

・hcustomでビルドを実行します

hcustom SOP_Star.C

・ビルドの成功を確認

成功していたら、以下のフォルダにビルドで生成されたファイルができているはずです

%USERPROFILE%\Documents\houdini18.0\dso

SOP_Star.dll
SOP_Star.exp
SOP_Star.lib
SOP_Star.pdb

・Houdiniでプラグインの動作を確認する

・Houdiniを起動
・Geometryを内でTABメニューから[star]と検索し[Star]ノードを作成
・無事ビューポート内に星型のジオメトリが現れればOKです。


注意点


・protoヘッダファイルに関して

古い文献を探すと、protoヘッダファイル不使用の解説が見つかったります。
また、18.0.532 では、protoヘッダファイルを作らずにいきなり

hcustom SOP_Star.C

を実行すると、protoヘッダファイルが見つからずにビルドが失敗するようでした。

現時点では、protoヘッダファイルを使うことでプラグインのパラメータアクセスが簡単になるので、必ず用意するものと考えて良さそうだと考えています。

※2020/08/30 追記
サンプルのソースコードを覗くと、もともとprotoヘッダファイルをincludeするように指定されていました。
protoヘッダファイルを作らないとビルドがコケるよね、というオチ。

恐らくprotoヘッダファイルを使うやり方は新しいやり方なのだと想像できるし、何より便利な方法なので、積極的に利用するのが良さそうという見方は変わらず。

protoヘッダファイルの作成と、ソースコードでincludeする、ということをお作法としておけば間違いないのではないかと思いました。

Refactoring Houdini Node Network – メンテナンス性の高いノードネットワーク構築のために

■はじめに

 この記事は、「Houdini Advent Calendar 2018 – 8日目」の記事です。

 既存のノードネットワークを変更する際、変更する対象が巨大であるためにどこを変更すべきかわかりにくくなってしまっていたり、ある箇所への変更が他の箇所に影響してしまい、メンテナンスしづらい状況を経験したことは誰にでもあると思います。

 この記事では、そのような状況を改善・予防するため「リファクタリング」と呼ばれる手法に焦点を当て、筆者の主観をもとに基本的な手法を紹介したいと思います。

■対象読者

・Houdini初級~中級者
・メンテナンスしにくいノードネットワークに日々苦しんでいる方
・メンテナンスしやすい設計でノードネットワークを構築したい方
・プログラミング初心者で、読みやすいコードを書くための作法を知りたい方


■リファクタリングとはなにか?

 リファクタリング (refactoring) とは、コンピュータプログラミングにおいて、プログラムの外部から見た動作を変えずソースコードの内部構造を整理することである。また、いくつかのリファクタリング手法の総称としても使われる。ただし、十分に確立された技術とはいえず、また「リファクタリング」という言葉に厳密な定義があるわけではない。(Wikipediaより抜粋)

※ここでいう「プログラムの外部から見た動作を変えず」というのは、リファクタリング前後で、リファクタリングする対象が行う処理の結果を変えないという意味です。


■Houdiniでのリファクタリング

 Houdiniでの作業はプログラミング色が強く、ノードネットワークを組み立てることはプログラミングすることそのものと言えます。
 ノードネットワークは、ある種ソースコードのようなものです。
 更に、HoudiniではVEX/Wrangle/Pythonなど、プログラミングそのものを行う要素も含んでいます。

 そのため「リファクタリング」手法のいくつかをHoudiniでも比較的素直に取り入れることができます。


■リファクタリングのメリット

 リファクタリングにより、ノードネットワークの構造を整理することができ、結果として以下のようなメリットが得られます。

・ノードネットワークを局所的/全体的に理解しやすくなる
・ノードネットワークの修正(保守)が簡単になる
・ノードネットワークの拡張が簡単になる
・理解しやすく整理された形で新たなノードネットワークを作れるようになる


■手法ごとの具体的な方法

□名前の変更

 ノード名、パラメータ名、アトリビュート名、Wrangleの変数名など、各種「名前付きの要素」を、誰が見てもわかりやすい形にリネームします。

 これにより、その要素の役割が判断しやすくなり、時間が経ってから見直したときや、他人へデータを渡したときに処理の内容を理解する助けになります。

・名前のプリフィクス(接頭辞)について

set_, del_ などの部分だけでノードごとの基本的な動作が伝わります

 その要素が何を行うものであるか判断できるよう、名前の先頭に目的に応じたプリフィクスを追加します。
 ルールに則ったプリフィクスを利用すると、ひと目でその要素が大雑把にどのような動作をするものか判断しやすくなり、メンテナンス性が向上します。

 例えばノード名はそのノードの動作に適した動詞をプリフィクスにします。
 変数名の場合も同様に、変数の役割がわかるようなプリフィクスをつけます。

 このようにしておけば、ノードリストなどでノードを検索する際のヒントにもなります。

目的の例プリフィクスの例
何かを追加するadd_
何かを削除するdel_
何かを計算するcalc_
何かを移動するmove_
何かをセットするset_
何かのテストにつかうtest_

・意味のある名前について

aaaaaaaaaaaは最終的に必要?目的は?
1年後に思い出せる気がしません・・・

 プログラミング学び初めの頃によくやってしまいがちなことの一つに、実験用の変数のような「瞬間的にほしい要素」に対し、一見して意味のない名前をつけるということがあります。

 これは、実験中はいいのですが、実験終了後にこの要素が不要となったにもかかわらず、要素を消し忘れたまま時間が経ってしまった時に問題を引き起こします。

 このような要素は本来不要であるにもかかわらず、なんとなくまだ必要そうな気がしてしまい、出来上がった仕組みを壊してしまうことに対する恐れも手伝い、消せないまま放置してしまったことがある方は多いのではないでしょうか。

 また、実験用に作った要素が最終的に採用され、利用されることになるケースもあります。
 このような場合も、はじめから意味のある名前をつけておけば、名前を修正する手間が省けて一石二鳥です。

意味のない名前の例
a b c
aaa bbb ccc
gngingaio miewaaaaaa

※ループカウンターで使われる[i,j,k]や、座標を表現する際に使われる[x,y,z][u,v,w]などは、それ単体では意味のないアルファベットですが、一般的な名前として広く認知されているので、意味を持っています。
そのため、使用しても何ら問題ありません。

・名前の記法について

各種記法で記述したノード名のサンプル

 プログラミングで使われる名前の記法には いくつか種類があります。
 よく目にする主な記法はだいたい以下の3通りだと思います。

スネーク記法
全部小文字
単語の区切りをアンダーバーで区切る
プログラミングでは主に変数名で使用
calc_cut_distance
point_num
prim_area
add_two_point
ローワーキャメル記法
名前の先頭は必ず小文字
単語の区切りごとに頭文字を大文字にする
主に変数名で使用
calcCutDistance
pointNum
primArea
addTwoPoints
アッパーキャメル記法
すべての単語の区切りごとに頭文字を大文字にする
プログラミングでは主にクラス名で使用
CalcCutDistance
PointNum
PrimArea
AddTwoPoints

 筆者は最近、Pythonのコード規約であるPEP8にならうことが多いです。
 具体的に言うと以下のようなルールに従っています。

・ノード名やプログラムの変数名はローワーキャメルケースで記述
・Pythonコード中のクラス名はアッパーキャメルケースで記述

・略称について

略しすぎると、そのノードの役割が全くわからなくなります

 名前付き要素に略称を使うことは可読性を損なう一因となります。
 メンテナンス性を高めるためには、極力名前のパーツに略称を使わないことが望ましいといえます。

 例えば、あるノードを「calc_center_position」という具体的な名前にする場合を考えます。
 このとき、「position」という言葉が長すぎると感じるかもしれません。
 そのような場合、略称を使いたくなります。

 しかし、ここで「position」を「p」と極端に略した場合、その「p」がどのような意味合いで選択された名前なのか第三者には瞬時に理解できません。(もちろん前後の文脈から想像はできますが、瞬時に理解するのは難しいでしょう)
 もしかしたら、数日後の自分ですらその「p」が何なのか即答できないかもしれません。

 そこで、この「position」という文字列を、一般的によく使われる「pos」という略称に置き換えるのは悪くない考えです。
 ただし、前後の文脈によっては「pos」から「positive」など、別の言葉を連想する可能性もあり得るので、意味をはっきり伝えるという意味では少し確実性に欠けます。

 とはいえ名前が長くなりすぎるのも困りものです。
 実際のところ、若干の読みやすさを犠牲にして、明らかに一般的な共通認識として定着している略称のみを必要最小限の範囲で使用するのが良い落とし所となるでしょう。

元の名前の例略称名略称名(悪い例)
positionposps, p
pointptp
attributeattra, at,
numbernumm, nm,

・長すぎる名前について

長過ぎる名前は、詳細はわかりますが不便です
適度に略称を取り入れながら、ほどほどの長さに収めましょう

 名前の文字数は長くても20文字~30文字までといった意見をよく見かけます。
 確かに長い名前はコードが複雑化すると全体が見づらくなる原因になります。
 ちょっとした文章のような長さの名前はおすすめできません。

 ですが、省略しすぎて意味が全くわからない名前よりは遥かに良いです。
 短すぎる名前を使うくらいなら、意味のわかる長い名前を使いましょう。


 VEXやPythonの場合、Visual Studio CodeやSublimeなどに、対応する言語のプラグインをインストールして外部エディタとして利用すると、インテリセンス(コード補完機能)が使えるようになります。
 Houdini内ではノードパスなどでインテリセンスが利用できます。

 そのため、多少長い名前を使用していても間違いなく簡単に入力できるうえに、いざ名前が長すぎたと感じる場合でも、エディタの機能で特定の対象だけ簡単にリネームできるので、さほど問題になりません。

・名前付けの具体例

 上記を踏まえた上で、具体的な名付けの例を挙げてみます。

要素の目的や動作名前の例
ポイントを追加するwrangle名add_point
primにsizeアトリビュートを追加するwrangle名add_size_attr_to_prim
三角ポリゴンを削除するwrangle名del_triangle_prims
ループ数を格納する変数名loop_num
ポイント数を格納する変数名point_num
ベクトルAとBの内積を格納する変数名
dot_A_B

□アルゴリズムの更新とテスト

compare_geometryでunittestを行いながら処理を分解

 リファクタリングの重要なポイントに、処理の内容を変えずに構造を整理するということを挙げました。
 そのためには、リファクタリングの前後で結果に差がないことを確認しながら作業をすることが重要です。

 通常のプログラミングでのリファクタリングは以下のように進めます。

1リファクタリング対象を複製し、もとのロジックをとっておきます。
2リファクタリング後の処理がどうなっていれば正解なのか判断できるデータを作ります。
このデータを、リファクタリング後の処理結果と常時比較しながら、結果が異なる場合に即座に検知するために使います。
この比較は、一般的にユニットテストと呼ばれます。
3リファクタリング語の処理結果が、リファクタリング前と同じであることを確認しながら構造の修正を行います。
4リファクタリングが完了し、もとの処理が必要なくなったら削除

 Houdiniの場合もこれによく似ていて、以下のように進めます

1リファクタリング対象のノードや一連のノードチェーンを複製、分流。
2Switch SOPを作成し、分流したノードの出力を接続します。
このSwitch SOPでリファクタリング前後の結果を簡単にスイッチして確認しやすくします。
ジオメトリのアトリビュートを比較するユニットテスト用HDAを作成してもいいでしょう。
3リファクタリング前後で結果が同じであることを確認しながら構造の修正を行います。
4リファクタリングが完了し、もとの処理が必要なくなったら削除

□関心の分離

1つのWrangleに3種類の処理が含まれていたので分解した例

 1つのノードでは、1度に1種類の処理のみを行うようにします。
 例えば、色を設定するWrangle SOPでは色を設定することのみを行うようにします。
 このWrangle SOPでは、色を設定すると同時に法線を設定するように複数種類の処理をさせることはしません。
 色の設定と別に法線を設定する必要がある場合、2つの処理を切り分けて別々のノードを作成し、それぞれで処理を行います。

 処理を切り分けることでその処理が影響する範囲が小さくなります。
 これにより、この処理に対する何らかの変更が必要な場合に気を配る必要にある範囲が小さくなります。
 これが「関心を分離する」ということです。

 関心を分離した結果、それぞれの処理に変更を加えたい場合や、ある処理の前後に新たな処理を追加する場合に、変更すべき箇所がわかりやすくなります。

 また、ノードを切り分ける場合は、処理のステップが複数のノードに分かれるので、各ノードのVisibilityフラグを切り替えながら、各処理ごとの結果が確認しやすくなります。

 Wrangleの場合、コード中の特定の行で処理を止めて途中経過を確認するようなデバッグ機能がないので、Wrangleコードとそのコードで使われるパラメータを機能単位のWrangleに切り分けて関心を分離することになります。


□処理の集約

整理された5つの処理を、1つのsubnetに集約した

 Houdiniに限らず一般的なプログラミングでは、複数の小さな処理を積み重ねて大きな処理を組み立てていきます。

 Houdiniでは、複数のノードをSubnetノードにパックしてまとめることができます。
 複数の小さな処理で成り立つ大きな処理をパックすることで、処理のくくりが明確になり、ノードネットワークの見通しが良くなります。

 これは一見すると、上で挙げた「関心の分離」に反するように見えます。
 たしかに、何も考えずにSubnetに複数のノードをまとめてしまうと、むしろノードネットワークが俯瞰しづらくなり、混乱の原因になります。

 そのため、処理を集約する際は、必ず集約する処理に対し関心の分離を適用します。
 複数の処理を一つのSubnetにまとめるタイミングは、関心の分離を適用する前でも後でも問題ありません。
 関心の分離を適用するとノードが増えます。
 すでにノードネットワーク全体が膨大なノード数で構成されていて、これ以上ノードを増やすと視覚的に全体を俯瞰しづらくなる場合などは、先に関心の分離を適用する処理の範囲をSubnetにまとめておき、そのSubnet内で適用することで、その他の箇所に気を取られずに作業できるようになります。

 これもまた、ノードネットワーク全体を巨大な処理と見立てた関心の分離とも呼べます。


□処理の再利用

 一心不乱にノードネットワークを作成していると、途中で行ったコピー&ペーストの影響なども手伝い、全く同じ処理を随所で繰り返している事態に陥ることがあります。

 全く同じ処理が複数箇所にあり、それぞれの処理に同じ変更を加えたい場合、それぞれに対し個別に同じ変更を加えるのは現実的とは言えません。

 このような場合、処理を切り出して再利用できるようにします。
 その後、切り出した再利用可能な処理で各所の重複部分を置き換えることで、その後の処理変更が1箇所で行えるようになります。

・HDA

 Subnetにまとめた仕組みは、デジタルアセットに変換することで再利用が簡単になります。(この方法については、多くの方が言及されているので、ここでは解説しません)

・Compiled Block/Invoke Compiled Block

同じ処理の一つCompiled Blockにまとめ
Invoke Compiled Blockによって呼び出しながら再利用

 Compiled Blockに対応しているノードだけで処理を構成する必要がありますが、Compiled Blockを使って一連の処理をひとくくりにし、Invoke Compiled Blockを通して、一連の処理を再利用できます。


 他にも多くのリファクタリングテクニックがあるのですが、ここでは基本的なものに絞って紹介させていただきました。
 タイムリミットも迫り記事も長くなってしまったので、より実践的なリファクタリングの実例紹介は別の機会に・・・

 この記事について、なにかご質問や間違いがありましたら遠慮なくツッコミをいただけると助かります。


 最後に、個人的にリファクタリング関連で参考になったと感じる書籍をいくつか紹介します。

 Houdiniはそもそもプログラミングツールではないため、これらの書籍で紹介されるすべてのテクニックが適用できるわけではありませんが、多くの点で役立ちます。(今回ご紹介したリファクタリングや、Wrangle、Pythonでコーディングする際など)

 特に「レガシーコード改善ガイド」の方は、古いコードのメンテナンスに際し起こりうる様々な問題ごとに適用できる、リファクタリングとテストを使うコード改善テクニックが紹介されています。
 今回紹介したユニットテストを使う安全な開発方法(テスト駆動開発)も、こちらの書籍から着想を得ています。

 興味のある方はぜひ読んでみてください。


 

Houdini – Python(HOM)によるパラメータ操作

 前回は、HOMによりノードを選択する操作に関する記事を書きました。
 ノードを探して選択するだけではあまりにも寂しいので、今回はそれに引き続き、ノードのパラメータを操作する部分に関するメモを書き残したいと思います。
 Houdiniでは、ノードパラメータへの操作パスが幾通りも存在しており、とても柔軟な作りになっていますが、今回は、自分がよくやる方法を取り上げます。
「もっと便利な方法があるよー」などの情報があればぜひ教えてください。
 ここで紹介する各種メソッドはあくまでも一例で、実際には更に多くのメソッドが用意されているので、ぜひマニュアルも参照してください。
http://www.sidefx.com/docs/houdini/hom/hou/Node.html
http://www.sidefx.com/docs/houdini/hom/hou/Parm.html
http://www.sidefx.com/docs/houdini/hom/hou/ParmTuple.html


パラメータ名の確認

 まず最初に、パラメータへアクセスする際はパラメータ名が重要になるので、名前の確認方法から。

Parameter Spread Sheetで確認

 Parameter Spread Sheetで、ノードとパラメータをツリー表示で確認できる。
 各項目名の右端にある、カッコで囲まれた名前が実際にアクセスする際に使用するパラメータ名。パラメータにはUniform Scaleのような単一の値を持つパラメータと、位置や回転など、複数の値をひとまとめにして持つ配列パラメータがある。
 下図を例にすると、Axis Divisionsという「ラベル」が付けられたパラメータは、実際の名前が「divrate」であり、3つの子要素(divratex/y/z)を持っている配列パラメータである事がわかる。

ドラッグ&ドロップで確認


 Python Source Editorに、パラメータラベルをドラッグ&ドロップすることで正しい配列パラメータのパスと名前が確認できる。

ポップアップウインドウで確認

 Parametersパネルなどでパラメータ名ラベルの上にマウスカーソルを置き、少し待つと、パラメータ情報がポップアップで表示される。この中の、Parametersの部分にある文字列が、このノードにおけるパラメータの正式な名前になる。

↑↑↑
 この場合、tx ty tz がパラメータ名であると確認できるが、あくまでも配列要素の単一パラメータ名のみがわかる。
 正確な親の配列パラメータ名が知りたければ、Parameter Spread Sheetを確認するなど一手間必要。(大体の場合、配列要素パラメータ名の末尾を削ったものが配列パラメータ名になっているっぽい)


おおまかなパラメータアクセスの方法

パラメータへのアクセス方法

  1. パスを指定して直接パラメータオブジェクト(hou.Parm)へアクセス
  2. 任意のノードのパラメータオブジェクト(hou.Parm)へ、名前を指定してアクセス

パラメータの操作方法

  1. ノードオブジェクト(hou.Node)を直接操作
  2. パラメータオブジェクト(hou.Parm)を通して操作

単一パラメータオブジェクトの取得

import hou

# パラメータオブジェクトを直接取得
parm_direct = hou.parm('parm_path')

# ノードオブジェクトからパラメータ名を使用してパラメータオブジェクトを取得 
node = hou.node("node_path")
parm_from_node = node.parm('parm_name')

配列パラメータオブジェクトの取得

 translateやrotateのような複数要素で構成されるパラメータは、配列パラメータとしてまとめて各要素へアクセスすることができる。
 基本的に、これは単一のパラメータへのアクセスと同じように行うが、その際は、parmTupleやevalParmTupleといった配列パラメータを扱う専用のメソッドを使う。

import hou

# 配列パラメータオブジェクトの子要素配列を取得
tupleParm_direct = hou.parmTuple('tupleParm_path')

# 配列パラメータの値を取得
# ノードオブジェクトをつかまえておく
node = hou.node("node_path")
tupleParm_from_node = node.parmTuple('tupleParm_name')

# 子要素へは、tupleParmの配列要素へアクセスして行う
tupleParm_x = tupleParm_from_node[0]
tupleParm_y = tupleParm_from_node[1]
tupleParm_z = tupleParm_from_node[2]

単一パラメータの値を取得する

 eval~と名づけられたメソッドを使う。
 型を指定して型変換しながら値を取得するメソッドや、時間指定で値を取得するメソッド、それらを組み合わせて取得するメソッドなどもある。

import hou

# 単一パラメータオブジェクトから現在の値を取得
parm = hou.parm("parm_path")
parmValue = parm.eval()

# 型を指定ながら現在の値を取得
parmIntValue = parm.evalAsInt()
parmFloatValue = parm.evalAsFloat()
parmNodeValue = parm.evalAsNode()

# 指定時間での値を取得
parmAtFrameValue = parm.evalAtFrame( FRAME_NUMBER )

# 型指定と時間指定の組み合わせ
parmIntAtFrameValue = parm.evalAsIntAtFrame( FRAME_NUMBER )
parmFloatAtFrameValue = parm.evalAsFloatAtFrame( FRAME_NUMBER )

配列パラメータの値を取得する

 配列パラメータの値取得も、単一パラメータとほぼ同様。

import hou

# 配列パラメータオブジェクトから現在の値を取得
tupleParm = hou.parmTuple("parm_path")
tupleParmValue = tupleParm.eval()

# 型を指定ながら現在の値を取得
parmIntValues = tupleParm.evalAsInts()
parmFloatValues = tupleParm.evalAsFloats()
parmNodeValues = tupleParm.evalAsNodes()

# 指定時間での値を取得
parmAtTimeValue = parm.evalAtTime( TIME )
parmAtFrameValue = parm.evalAtFrame( FRAME_NUMBER )

# 型指定と時間指定の組み合わせ
parmIntAtFrameValues = parm.evalAsIntsAtFrame( FRAME_NUMBER )
parmFloatAtFrameValues = parm.evalAsFloatsAtFrame( FRAME_NUMBER )

パラメータをセットする

 値のセットは、set系メソッドを使う。
 事前に組み立てたパラメータ辞書をsetParmsメソッドに与え、一括で値をセットするのがとても楽なのでおすすめ。
 その際、setParmsメソッドでは配列パラメータ名は認識できないので、各要素を個別の単一パラメータとして辞書に値を用意します。

import hou

# 単一パラメータに値をセットする
parm = hou.parm('parm_path')
parm.set( value )

# 配列パラメータにシンプルな値の配列をセットする
tupleParm = hou.parmTuple('parm_path')
tupleParm.set( (value1, value2, value3, ...) )

# ノードオブジェクトを使い、複数のパラメータをまとめてセットする
# セットしたいパラメータを辞書に溜め込み、setParms()に与える
parmDict = { 'parm_name1':value1, 'parm_name2':value2, ... }
node = hou.node('node_path')
node.setParms(parmDict)

 以上、何か不明点などあれば気軽にご質問ください。
 間違いがあればツッコミも大歓迎です。

Houdini – Python(HOM)によるノード選択(改題)

 あるシーンを開いた時、膨大なオブジェクト数とグループ数により階層が深く、なおかつすべてのノードに命名規則が全く見当たらないという、ツール作成者視点でシーンを眺めた時、ついつい汚い床の上をのたうち回りたくなるような状況は往々にしてあることなのですが、そのような状況下でのHoudiniの選択操作は、他のDCCツールよりも遅れを取っている気がします。

 例えば、ビューポートで選択しているすべてのノードの親を簡単にまとめて再選択したかったり、同様に、選択アイテムのすべての下流ノードをまとめて選択したかったりと言った状況です。

 ノードを右クリックして表示されるポップアップメニューから、Inputs/Outputsサブメニューを駆使してみるも、単一の選択アイテムのみがノード検索の起点になるので、複数のノードツリーをまとめて選択できなかったりします。

 このように、意外とHoudiniデフォルトの選択機能に痒いところが多かったので、選択補助スクリプトを書いてみました。

 ついでと言ってしまうと何だか申し訳なく感じてしまうのですが、簡単なメモを書き残したいと思います。


基本的なノード検索

import hou
nodeObject = hou.node("node_path")
import hou
selectedItems = hou.selectedItems()

ノードの親子関係

import hou
node = hou.node('node_path')

# parent()は自身を含む外側のノードの取得
outerNode = node.parent()
print( outerNode )

# children()は自身が含む内側のノードリストを取得
innerNodes = node.children()
print( innerNodes )
import hou
node = hou.node('node_path')

# inputs()は自身へ入力している直接の上流ノードリストの取得
inputNodes = node.inputs()
print( inputNodes )

# outputs()は自身が直接出力しているノードリストを取得
outputNodes = node.outputs()
print( outputNodes )

# inputAncestors()は直系の祖先をまとめて取得
ansectorNodes = node.inputAncestors()
print( ansectorNodes )

かなり基本的なところではこんな感じ。
他にもたくさんあるので、その他のメソッドは要マニュアル参照。

出力の全子孫を取得するメソッドがパット見見つからない感じだったので、再帰的に子孫をたどる関数を作ってみる。

import hou

def getDescendents(node, *args, **kwargs):
    """
    DESCRIPTION : 引数で与えたノードから再帰的に子孫を辿って返す
      ARGUMENTS : node : 探索を開始するノード
         RETURN : descendents : 見つかった子孫ノードリスト
    """
    descendents = []

    direct_outputs = node.outputs()
    if direct_outputs:
        for direct_output in direct_outputs:
            descendents += [direct_output]
            descendents += getDescendents(direct_output)
   
    return descendents
    
node = hou.node('node_path')
descendents = getDescendents(node)
for descendent in descendents:
    print( descendent )

選択操作

import hou
node = hou.node("node_path")

# 選択 setSelectedメソッドにブール値をセット 1で選択0で非選択
node.setSelected(1)

# 選択解除
node.setSelected(0)

 上記を組み合わせて、現在のノードから1つ上流のノードを探し、再度全下流ノードを探して全選択を行うなどの便利なコマンドを作成できます。

CGWORLD v.230 に寄稿させていただきました

久しぶりの更新が宣伝というのもアレですが・・・

2017/09/08発売 の CGWORLD v.230 に掲載の特集記事「すぐに役立つTIPSとアプローチ ワンランク上のキャラクターリギング」に、株式会社コロッサス名義で「ダイナミックコントロールリグのためのツール活用術」というタイトルの記事を寄稿させていただきました。

地味に手間のかかる馬の手綱セットアップを例として、ダイナミックリグの作成方法と、ツールによって作業を簡単化する方法を紹介しています。

また、スクリプトは書いたことがあるけれど、APIまでは手を出したことがないという方向けに、Maya Python API 2.0によるOpenMayaの基本的な使い方の解説と、メッシュ上の最近接点の取得や、カーブ上の一点が持つ各ベクトルからのマトリクス組み立てといった、覚えておくと色々な場面で役に立つ内容も盛り込んでみました。

また、現在在籍している「株式会社コロッサス」のブログにて、ツールの配布等もしておりますので、ぜひ本誌を手に取っていただけると幸いです。

<株式会社 コロッサス:ブログ CGWORLD v.230
<CGWORLD SHOP:CGWORLD v.230

Interactive Houdini

Houdini Advent Calendar 2016 18日目に投稿させていただいた記事です


■はじめに

Houdiniには外部デバイスからインタラクティブにデータを入力する機能があります。

今回は、その機能を利用して外部に接続した各種フィジカルデバイスの操作から、Houdiniへデータを入力する方法を色々と書いてみたいと思います。

手頃に試せそうな例として、ここでは以下のデバイスからの入力を試してみます。

・マウス
・ペンタブレット

・キーボード
・MIDIコントローラ


■環境

・Windows10 64bit
・Houdini Indie 15.5.673


■まずは今回取り上げるCHOPに共通する予備知識

今回取り上げるCHOPは以下の通りです

Mouse CHOP
Keyboard CHOP
MIDI In CHOP

・CHOPデータの在り処について

CHOPのデータは、「CHOPチャンネル」が持っています。
CHOPチャンネルのデータへアクセスする際は、CHOPノードだけではなく、CHOPノード内にあるCHOPチャンネル名まで指定する必要があります。

・CHOPデータの詳細確認

CHOPノードを中ボタンでクリックするとCHOP内のチャンネル数や、開始/終了フレーム、サンプルレートなどの詳細情報が表示されます。

赤く囲んだ部分には、このCHOPに含まれるチャンネル名と値が表示されています。
この例の場合、ステレオのオーディオファイルを読み込んでいるので、このCHOPには左右2チャンネルの波形データが含まれていることがわかります。
そして、チャンネル名は左右でそれぞれ chan0 chan1 が割り当てられています。

・CHOPチャンネルへのパス

CHOPチャンネルへのパスは、CHOPノードへのパス+CHOPチャンネル名で指定します

~/chop_name/channel_name

上記の例で言うと、WAV_FILE(File CHOP) の chan0 チャンネルへのフルパスは以下のようになります

/obj/driver_chopnet/WAV_FILE/chan0

・CHOPチャンネルへのアクセス

CHOPチャンネルの各情報は、chop系エクスプレッション関数を使って取得します。
これらの詳細はマニュアルを参照してください。

  • chop : 現在時間でCHOPチャンネルの値を取得
  • chope : CHOPチャンネルの終了インデクスを取得
  • chopf : 指定フレームでCHOPチャンネルの値を取得
  • chopi : 指定サンプルポイントでCHOPチャンネルの値を取得
  • chopl : CHOPチャンネルの長さをサンプル数で取得
  • chopn : CHOP内のチャンネル数を取得
  • chopr : CHOPのサンプルレートを取得
  • chops : CHOPチャンネルの開始インデクスを取得
  • chopt : 指定した時間でのCHOPチャンネルの値を取得
  • chopcf : 指定フレーム、指定チャンネルインデクスでCHOPチャンネルの値を取得
  • chopci : 指定サンプルポイント、指定チャンネルインデクスでCHOPチャンネルの値を取得
  • chopct : 指定時間、指定チャンネルインデクスでCHOPチャンネルの値を取得
  • chopstr : 現在時間でのCHOPチャンネルの文字列データを取得

先の例で登場したCHOPチャンネルが持つ現在時間のデータが欲しい場合は、データを呼び込むパラメータボックス内で以下のエクスプレッションを使用します。

chop( “/obj/driver_chopnet/WAV_FILE/chan0” )

・CHOPチャンネルの波形データを確認する

CHOPの波形データは、CHOPノードの右端にある[Graphフラグ]をオンにすることで、Motion FX Viewに表示されます。

Motion FX View

・CHOPデータのサンプルレート

CHOPでは様々な波形データを扱うことができます。
波形データは自由に再生時のサンプルレート(一秒あたりのデータ数)を指定できるようになっています。

サンプルレートの高いオーディオデータを30fps設定のシーンでアニメーションカーブとして使う場合、サンプルレートを30にリサンプルしてから使用するのが負荷軽減につながって良いのではないかと思います。

サンプルレートは、File CHOPのChannelタブ内またはResample CHOPにあるSample Rateパラメータで指定します。

・上で読み込んだWAVデータの波形を30fps化したところ

・外部から入力されたデータのレコーディング

外部から入力されたデータを記録しておき、再生することができます。
MIDIデータを外部から入力するMIDI In CHOPなどは、入力されたMIDIデータを自分自身に記録する事ができるようになっていますが、Record CHOPを下流に接続してそちらで記録するほうがデータの取り回しの面で良いと思います。

レコーディングは、データ入力CHOPの下流に Record CHOPを接続し、Record パラメータをオンにした状態で行います。


■というわけで、早速やってみよう

CHOP入力→レコーディング→再生の流れは、今回紹介するどのCHOPでも変わらないので、まずはMouse CHOPの簡単なチュートリアルで作業の流れを掴んでみます。


■Mouse CHOPチュートリアル

1・CHOPコンテキストにCHOP Networkを作成します

2・CHOP Network の中に Mouse CHOPを作ります

3・Mouse CHOPのGraphフラグをオンにしたあと、Motion FX Viewを表示します

4・Mouse CHOPの下にRecord CHOPを接続します

5・Record CHOPのRecordパラメータをOnにし、シーンを再生します

この時、シーンのリアルタイム再生モードをオンにしておくと実際のフレームレートでレコーディングできます。

また、再生モードを Play Onceにしておくことでリピート再生をオフにし、うっかり開始フレーム付近を書き換えてしまうのを防げます。

6・マウスカーソルを自由に動かし、グラフが描かれていくのを確認します


各カーブの上には、対応するカラーでチャンネル名が表示されています。(geo1:txgeo1:ty

7・記録できたら、Record CHOPのRecordをOffにします

8・/obj/に新たにBoxオブジェクトを作ります

9・boxオブジェクトのTranslateX/Yにエクスプレッションを設定します

・TranslateX
chop(“../../ch/ch1/record1/geo1:tx”)

・TranslateY
chop(“../../ch/ch1/record1/geo1:ty”)

10・シーンを再生して結果を確認します

boxオブジェクトが、マウスが動いたとおりに移動するのが確認できます。

11・ペンタブレットをお持ちの場合

Mouse CHOPのUse Tabletをオンにして、同様の操作をすることで、筆圧やペンの傾きなどを検知し、記録できる事がわかると思います。
Pressure CHOPチャンネルを boxオブジェクトのUniform Scaleパラメータにアサインすると楽しいかもしれません。


■データ入力手順のまとめ

これが外部入力系のCHOPを使うワークフローの基本的な手順です。
手順をまとめると以下のようになります。

1・外部入力を受け付けるCHOPを作成
2・CHOPにデータの窓口となるCHOPチャンネルを作成
3・任意のパラメータからchop関連のエクスプレッション関数でCHOPチャンネルのデータを参照する

これはその他のデータ入力CHOPを使った場合も同様です。
これだけ理解できれば、あとは応用して色々できるはず。


■Keyboard CHOPチュートリアル

Mouse CHOPに続いて、Keyboard CHOPチュートリアルです

1・CHOPコンテキストにCHOP Networkを作成します

2・CHOP Network内にKeyboard CHOPを作成します

3・Keyboard CHOPの設定をします

Name 1

どんな名前でもいいのですが、ここでは [key_a] と記入します。

Type 1

そのままにします。

Type 1の右側にあるプルダウンメニュー

 [A] を選択します。

同様に、Name 2~Name 4まで、それぞれ同様に s,d,w キーを割り当てます。


4・Interceptモードをオンにします

キーボード上にあるScroll Lockキーを押し、Interceptモードをオンにします。

現在時間がオレンジ色になります。

5・キーを押して反応を確かめます

 a,d,wを同時押しした様子

あとは、Mouse CHOPのチュートリアルと同じ方法で、下流にRecord CHOPを繋いでレコーディングできます。

Interceptモードではキーボード入力が無視されるのでマウスでシーンの再生ボタンを押してください。

chopエクスプレッション関数による値の取得も同様に行えます。


■MIDI In CHOPチュートリアル

最後に、MIDI In CHOPを使用してMIDIコントローラから入力するチュートリアルです

1・CHOPコンテキストにCHOP Networkを作成します
2・CHOP Network内にMIDI In CHOPを作成します

3・MIDI In CHOPの設定をします

・Sourceタブ

MIDI Source : MIDIIN2 (Launchpad Pro)
MIDI Channels : 1

※MIDI Sourceは、各々がお持ちのMIDIデバイス名を選択してください。

・Noteタブ

Note Scope : 0-127
Aftertouch Name : af

4・鍵盤を叩き、反応を確かめます

・ch1n60 (音階で言うとど真ん中の[ド])を押したところ

今回使用したLaunchpad Proはアフタータッチ対応のMIDIコントローラなので、打鍵後に鍵盤を更に押しこむ事でafチャンネルを変化させることができます。

あとは、Mouse CHOPのチュートリアルと同じ方法で、下流にRecord CHOPを繋いでレコーディングできます。

chopエクスプレッション関数による値の取得も同様に行えます。


■おわりに

今回ご紹介したテクニックを使うことで、直感的なデータ入力ができるようになります。

例えば、特定のキーを押したタイミングでパーティクルを発生させたり、ジオメトリの頂点カラーを変化させたり、キーボードを叩くたびに乱数のSeed値を変化させて、次々と予想だにしないビジュアルを作り出すこともできるでしょう。

また、キーを押す強さが強いほどパーティクルの発生量を多くしたり、色を濃くしたりと言った、複雑な表現もできるようになります。

Joy To Keyのようなツールを併用することで、手に馴染んだゲームコントローラを操作してHoudiniへのデータ入力を行うことも簡単にできます。

また、今回はNetwork CHOP や Pipe In CHOPは使用しませんでしたが、これらも使いこなせばなかなかに楽しいことができそうなCHOPなので、いずれ折を見て記事にしたいと考えています。

ここまで読んでいただき、ありがとうございました。
何か不明点や間違いがあれば、記事へのコメントやTwitterなどで質問、ツッコミください。


■おまけ

以降は、今回使用したCHOPのマニュアルみたいなものです。


■マウスからの入力 : Mouse CHOP

マウスのカーソル位置を取得することができます。
タブレットを使用している場合は、筆圧やペンの傾きなども取得できます。

・PositionX/Y

ここで指定した文字列が、それぞれに対応するCHOPチャンネル名になります。
画面左下から右上に向かって値が増えていきます。
Xの範囲は-1~1、Yの範囲は-0.8~0.8

・Use Tablet

オンにするとPressureやAngleなど、タブレット向けパラメータが有効になります。
PositionX/Yと同様、ここで入力した各文字列が、それぞれに対応するCHOPチャンネル名になります。


■キーボードからの入力 : Keyboard CHOP

指定したキーが押されたとき、Typeで指定した方法で値を入力します。

このノードを動作させるためには Interceptモード をオンにする必要があります。
Interceptモードをオンにするには、Scroll Lockキーを押しScroll Lockを有効化します。

Interceptモードが有効になると現在フレームがオレンジ色に着色されます。
この状態でキーイベントを取得するよう設定したキーを押すことで、値が入力されます。

・Modifier Keys

使用する修飾キーを指定します。

上記画像の例では、[A]を押している間だけCHOPチャンネル[a1]の値が1になります。

・Name

対応するキーが押されたときにオンになるCHOPチャンネル名を指定します。

・Type

キーを押したときの動作

Momentaly:押しているときだけ1を送出
Toggle:押すたびに0と1を切り替え
Count:押すたびに1ずつ値が増える
Pulse:押した瞬間だけ1を送出
Time:シーン再生中にキーが押され続けた時間

・Key

このチャンネルに値を入力するキーを選択


■MIDIデバイスからの入力:MIDI In CHOP

MIDIキーボードやフェーダーコントローラなどを使用して、Houdiniに外部から直接MIDIデータを入力することができます。
また、MIDIファイルを直接読み込む事もできます。

・Sourceタブ

MIDI Source

MIDI信号の入力ソースを指定します。
MIDIファイルやMIDIデバイスを選択できます。
インタラクティブな入力を行いたいなら、接続済みのMIDIデバイス名を選択します。
すでに作られた楽曲などを入力したいならMIDI Fileを選択します。

MIDI Channels

入力するMIDIチャンネルの番号を指定します。

入力するMIDIチャンネル数が多いと入力データの転送に時間がかかります。
例えば、使用するノート番号の範囲が0-127の場合、使用するMIDIチャンネル1つごとに128個のデータを解釈することになります。
そこでアフタータッチをポリフォニックモードで解釈させるとなると、さらに128倍の負荷がかかります。
そのため、インタラクティブに操作したい場合は入力するMIDIチャンネルを一つに絞ったほうがいいと思います。
複数のMIDIチャンネルを入力するのは、MIDIファイルを入力する時のみで良いでしょう。

入力を許可するMIDIチャンネル番号は以下のように指定できます

・スペース区切り(個別指定)

1 2 10 11

・ハイフンでつなぐ(範囲指定)

1-10

Channel Prefix

入力するMIDIチャンネル番号を識別するために付加される接頭辞を指定します。
ここで指定した文字列のあと、入力されたMIDIチャンネル番号が付加されます。
この値が[ch]の時、CHOPチャンネル名は以下のような書式になります。

ch1
ch2

Echo Messages to Textport

オンにすると、受信したMIDIメッセージの内容がHoudini Consoleに表示されます。
デバッグに便利なので必要に応じてオンにします。

・Recordタブ

レコーディングには、MIDI In CHOPの下流に接続するRecord CHOPを使用するので、ここでは何も変更しません。

・Noteタブ

主にMIDIコントローラの鍵盤部分とピッチベンドコントローラからの入力信号の解釈方法を決定するタブです。

・チャンネル名パラメータ

チャンネル名パラメータは、対応するMIDI信号を受けとるCHOPチャンネルを作成します。

Note Name : ノートナンバー
Velocity Name : ノートのベロシティ
Aftertouch Name : ポリフォニックキープレッシャー
Pressure Name : チャンネルプレッシャー
Pitch Wheel Name : ピッチベンド

ここで指定した文字列が、MIDIチャンネルを示す文字列のあとに続きます。
例えば、Note Nameの値が[n]なら、MIDIチャンネル1のノート番号60の値を受け取るCHOPチャンネル名は以下になります。

ch1n60

これらのCHOPチャンネル名パラメータに何か文字列が入力されると、その時点でCHOPチャンネルが作成され、データの入力待ちが開始されます。
使用しないMIDI信号の入力については負荷軽減のため何も入力しないのがベターです。

Note Scope

入力を受け付けるMIDIノートナンバーの範囲を指定します。
0-127の範囲が使えます。
Sourceタブの MIDI Channels と同様の書式で指定できます。

Note Output

・One Multiplexed Channel

ノート信号を番号ごとに分けず、一つのチャンネル内で押されたノート信号をすべてまとめて使用します。

この時、CHOPチャンネル名にノート番号は付かず、以下のような名前になります。

ch1n : チャンネル1のノートすべて

・Separate Channels

ノート信号をノート番号ごとに個別のチャンネルとして入力します。
この時、CHOPチャンネル名は以下のようになります。

ch1n60 : チャンネル1のノート番号60番
ch1n127 : チャンネル1のノート番号127番

Velocity

MIDI Note信号のVelocityをどのように受け取るか指定します。

・Off

Velocityを入力しません
ノートを入力するCHOPチャンネルの値はオンオフの2値になります。

・Note Amplitude

ノートを入力するCHOPチャンネルの値が、Velocityの値になります。

・Separate Channels

Note信号の値はオンオフの2値になります。
同時に、Velocityは次のVelocity Nameで指定された接頭辞とノート番号で表されるCHOPチャンネルの値として取得されます。

Normalize

入力されるVelocityデータの値の範囲を指定します。

・None

値は 0-127 の範囲で入力されます。

・0-1

値が 0-127 を 0-1 にマッピングした状態で入力されます。

・Controlタブ

MIDI CCメッセージに関する解釈方法を決定するタブです。
MIDIキーボードにスライダやツマミが付属している場合がありますが、そのような鍵盤以外のコントロールから送信されるデータに関する入力設定です。

・チャンネル名パラメータ

チャンネル名パラメータは、対応するMIDI信号を受けとるCHOPチャンネルを作成します。

Controller Name : CCメッセージ
Program Change : プログラムチェンジメッセージ

Controller Type

一般的なMIDI音源やDAWなどで共通してMIDI CCメッセージへ割り振られているコントロールを、わかりやすくプルダウンメニューから指定できます。

Controller Index

取り扱うMIDI CCメッセージのコントロールナンバーを直接指定します。
0-127の範囲が使えます。
Sourceタブの MIDI Channels と同様の書式で指定できます。

Controller Format

・7 bit Controllers

扱うCCメッセージがLSB/MSBに対応していない場合はこちらを選択します。

・14 bit Controllers

扱うCCメッセージがLSB/MSBに対応している場合はこちらを選択します。

Normalize

入力された値の範囲をリマップします。

・None

リマップしません

・0 to 1

0~1にリマップします

・-1 to 1

-1~1にリマップします

・On / Off

ブール値化します

Unwrap

これはちょっとよくわかりませんでした。
ラベルから察するに、ターンテーブルのような値をインクリメント/デクリメントするコントローラ向けに、値が0-127の範囲外にセットされたときに値をループさせるか否かを決めるオプションのような気がします。

 ・Sysタブ

MIDIクロックメッセージやシステムメッセージに関する解釈方法を決定するタブです。
今回は、手元で検証できる環境がないので端折りますが、この辺をちゃんと設定すれば外部のDAWとHoudiniの間で内部時間や、再生操作や停止操作などを同期できるはず。