前回ジョイント数を調べるツールを作りました。が、選択したジョイントの数を表示するツールだったので、アーティストがジョイントを一つ一つ選択してからツールを実行して数を表示するという、何とも微妙なツールになってしまいました。

今回はその不満点を解消するべくツールを改良してみましょう。

ツールで直すべきか、事前操作を行ってもらうべきか

前回同様順々に考えながらツールを改良してみます。

問題が発生しているのは、アーティストがジョイントを選択するところです。一つ一つ選択するから手間がかかりますし、ヒューマンエラーも起こりやすくなります。一発でジョイントを選択できればいいわけです。

そういえば選択しているオブジェクト以下の階層をすべて選択するコマンドがあります。
編集(Edit) > 階層の選択(Select Hierarchy)　です。アーティストにはキャラクターのルートを選択した後にこれを実行してもらって、階層内のジョイントを選択してもらいます。



それからツールを実行すれば無事にスケルトン全体のジョイント数が出ます。



33と表示されています。

この「階層の選択」という操作をやってもらってからツールを実行してもらう。これも一つの方法です。ただし毎度やってもらうのも大変ですし、何より事前に階層を選択しておかないとツールが正しく使えない、というのでは直感的とは言えません。階層の選択をスクリプトに含めてツールにしましょう。そうすればアーティストの手間が少なくて済みます。こういう手間が一つでも多かったり、ツールを実行する前準備が必要だったり分かりにくかったりするとツールは使われなくなります。

というわけでツールで直してしまいましょう。階層の選択はなんていうコマンドなのでしょうか。調べてみます。

メニューのコマンドを調べる方法

いくつかの方法がありますので、試してみます。

・ホットキーエディタで調べる
ウィンドウ(Window) > 設定/プリファレンス(Settings/Preferences) > ホットキー エディタ(Hotkey Editor) 　でホットキーエディタを開きます。表示されるメニューのコマンドを見れば、何が実行されているかわかります。



どうやら
select -hierarchy
が実行されているようです。

・スクリプトエディタの履歴で調べる
何か実行するごとにスクリプトエディタに履歴が出ますので、それを利用します。普通はこの方法を利用していると思います。まれに何も表示されないことがあります。そういう時はUndoしてみましょう。何が実行されていたのか表示されます。



どうやら「階層の選択」を実行すると、
SelectHierarchy
が実行されていたようです。これはメニューのコマンドで、実行すると先ほどホットキーエディタで見つけた
select -hierarchy
が実行されます。どちらを実行しても構いません。

もっとスクリプトエディタに情報を表示したい場合は、スクリプトエディタのメニューの、ヒストリ(History) > すべてのコマンドのエコー(Echo all commands)　をオンにします。実行されているあらゆるコマンドが表示されるようになります。情報が多すぎるので、必要な時だけオンにして使います。

というわけで、階層の選択は
SelectHierarchy
で行うことにしましょう。スクリプトに追加してみます。

選択しているオブジェクト以下にあるジョイント数がわかるようになりました！これで完成です！！

新たな問題

こんなに簡単に完璧なツールができてよいのか、自分の能力の高さを内心自慢したい思いに駆られつつ、アーティストにツールを試してもらいましょう。

「ジョイント一つ一つ選択しなくてもいいの？ルートのオブジェクトだけ選択しておけばいいの？すごい便利になったー。」

「でも、実行するとジョイントがすべて選択されるんだけど…。選択は変わってほしくないなー。」

なんと、テクニカルアーティストを神様のように褒め称えていたのが一変、便利さが当たり前になるとより要求が膨らんでいくものです。

ツールを作る側からしたら、階層の選択を行っているのでジョイントが選択されるのは当たり前です。しかしそれはツール開発側の【ツールの想像図】であって、使用者の【ツールの想像図】とは異なります。使用者は、ジョイント数が表示されるツールであって、選択を変更するツールとは思っていません。

この【ツールの想像図】が開発者と使用者で一致していなければ、ツールは非直感的で使いにくいものとなります。ツールを改良していくうえでいつの間にかこういう問題が起きます。つまりツールの改善部分が使用者の【ツールの想像図】を徐々に壊してしまうのです。

この現象はとっても重要なので別の例で説明します。

誰のためのデザイン？

例えばどのゲーム会社でも起きる問題としてエアコン問題があります…。悲しいかな、暑すぎたり寒すぎたりというアレです。

エアコンが二つあるとします。もちろん操作盤も二つあります。



右側のチームが暑いというので、設定温度を１８度に下げてみました。が、温度が全然下がりません。というわけでビルメンテナンスの人に聞いてみることにします。チームの人たちがアーティストで、メンテの人がテクニカルアーティストだと思ってください。

メンテの人が聞けばなぜ温度が下がらないか一目瞭然なのです。実は右側のエアコンは去年増設したもので、その際内部構造はこんな風にしたのです。



つまり左側のエアコンの風を右側のエアコンに流用しているので、左側のエアコンの温度以下にはならないのです。
一方、チームの人が想像していたのはこういう内部構造です。



これではまったく話が通じ合わないわけです。これが【ツールの想像図】に当てはまります。使用者と開発者の考えが一致してこそ良いツールとなり、使われ続けていきます。一致していないとすぐに使われないツールになってしまいます。意外とこれは盲点なので常に心がけておく必要があります。

こういったインターフェースの問題というものは研究が行われており、今回紹介した例は「誰のためのデザイン？」（D.A.ノーマン著）という本に基づく話です。

ツールの実行方法、結果、そういったもろもろは「ヒューマンインターフェースデザイン」が関わってきます。この分野の知識を総動員してツールを作ることになります。通常のテクニカルアーティストはこれを経験則で行っているところに一つの価値を見出しています。プログラマは学術的に勉強することで、テクニカルアーティストに負けない力を得ることができます。

Mayaでは一つのことを達成するのに様々方法が選べるようになっています。その中から最も「合うもの」を見つけることも、テクニカルアーティストの資質として重要です。

アーティスト主体のツール作成

というわけでツールを作る上での考え方を紹介しました。あまりこういった記事は見かけないので新鮮かもしれませんが、欧米では盛んに研究されている分野です。アーティスト主体のツールを作れることにテクニカルアーティストの真価があります。複雑で高機能なツールが作れることよりも重要なことです。複雑で高機能なツールは、本職のプログラマに任せてしまえばよいのです。

次回はこの考え方を踏まえて本当に完璧な「ジョイント数を調べるツール」を作ってみましょう！