TV前回ジョイント数を調べるツールを作りました。選択したジョイントの数を表示するツールだったので、アーティストがジョイントを一つ一つ選択してからツールを実行して数を表示するという、何とも微妙なツールになってしまいました。今回はその不満点を解消するべくツールを改良してみましょう。ツールで直すべきか、事前操作を行ってもらうべきか前回同様順々に考えながらツールを改良してみます。問題が発生しているのは、アーティストがジョイントを選択するところです。一つ一つ選択するから手間がかかりますし、ヒューマンエラーも起こりやすくなります。一発でジョイントを選択できればいいわけです。いえば選択しているオブジェクト以下の階層をすべて選択するコマンドがあります。アーティストにはキャラクターのルートを選択した後にこれを実行してもらって、階層内のジョイントを選択してもらいます。それからツールを実行すれば無事にスケルトン全体のジョイント数が出ます。33と表示されています。この「階層の選択」という操作をやってもらってからツールを実行してもらう。これも一つの方法です。毎度やってもらうのも大変ですし、何より事前に階層を選択しておかないとツールが正しく使えない、というのでは直感的とは言えません。階層の選択をスクリプトに含めてツールにしましょう。すればアーティストの手間が少なくて済みます。いう手間が一つでも多かったり、ツールを実行する前準備が必要だったり分かりにくかったりするとツールは使われなくなります。いうわけでツールで直してしまいましょう。階層の選択はなんていうコマンドなのでしょうか。メニューのコマンドを調べる方法いくつかの方法がありますので、試してみます。ホットキーエディタを開きます。表示されるメニューのコマンドを見れば、何が実行されているかわかります。-hierarchyが実行されているようです。・スクリプトエディタの履歴で調べる何か実行するごとにスクリプトエディタに履歴が出ますので、それを利用します。普通はこの方法を利用していると思います。まれに何も表示されないことがあります。いう時はUndoしてみましょう。何が実行されていたのか表示されます。「階層の選択」を実行すると、SelectHierarchyが実行されていたようです。-hierarchyが実行されます。どちらを実行しても構いません。実行されているあらゆるコマンドが表示されるようになります。情報が多すぎるので、必要な時だけオンにして使います。いうわけで、階層の選択はSelectHierarchyで行うことにしましょう。スクリプトに追加してみます。);選択しているオブジェクト以下にあるジョイント数がわかるようになりました!これで完成です!!新たな問題こんなに簡単に完璧なツールができてよいのか、自分の能力の高さを内心自慢したい思いに駆られつつ、アーティストにツールを試してもらいましょう。「ジョイント一つ一つ選択しなくてもいいの?ルートのオブジェクトだけ選択しておけばいいの?すごい便利になったー。「でも、実行するとジョイントがすべて選択されるんだけど...。選択は変わってほしくないなー。」なんと、テクニカルアーティストを神様のように褒め称えていたのが一変、便利さが当たり前になるとより要求が膨らんでいくものです。ツールを作る側からしたら、階層の選択を行っているのでジョイントが選択されるのは当たり前です。それはツール開発側の【ツールの想像図】であって、使用者の【ツールの想像図】とは異なります。使用者は、ジョイント数が表示されるツールであって、選択を変更するツールとは思っていません。この【ツールの想像図】が開発者と使用者で一致していなければ、ツールは非直感的で使いにくいものとなります。ツールを改良していくうえでいつの間にかこういう問題が起きます。ツールの改善部分が使用者の【ツールの想像図】を徐々に壊してしまうのです。この現象はとっても重要なので別の例で説明します。誰のためのデザイン?例えばどのゲーム会社でも起きる問題としてエアコン問題があります...。悲しいかな、暑すぎたり寒すぎたりというアレです。エアコンが二つあるとします。操作盤も二つあります。右側のチームが暑いというので、設定温度を18度に下げてみました。温度が全然下がりません。いうわけでビルメンテナンスの人に聞いてみることにします。チームの人たちがアーティストで、メンテの人がテクニカルアーティストだと思ってください。メンテの人が聞けばなぜ温度が下がらないか一目瞭然なのです。実は右側のエアコンは去年増設したもので、その際内部構造はこんな風にしたのです。左側のエアコンの風を右側のエアコンに流用しているので、左側のエアコンの温度以下にはならないのです。チームの人が想像していたのはこういう内部構造です。これではまったく話が通じ合わないわけです。これが【ツールの想像図】に当てはまります。使用者と開発者の考えが一致してこそ良いツールとなり、使われ続けていきます。一致していないとすぐに使われないツールになってしまいます。意外とこれは盲点なので常に心がけておく必要があります。いったインターフェースの問題というものは研究が行われており、今回紹介した例は「誰のためのデザイン?」(D.A.ノーマン著)という本に基づく話です。ツールの実行方法、結果、そういったもろもろは「ヒューマンインターフェースデザイン」が関わってきます。この分野の知識を総動員してツールを作ることになります。通常のテクニカルアーティストはこれを経験則で行っているところに一つの価値を見出しています。プログラマは学術的に勉強することで、テクニカルアーティストに負けない力を得ることができます。Mayaでは一つのことを達成するのに様々方法が選べるようになっています。その中から最も「合うもの」を見つけることも、テクニカルアーティストの資質として重要です。アーティスト主体のツール作成というわけでツールを作る上での考え方を紹介しました。いった記事は見かけないので新鮮かもしれませんが、欧米では盛んに研究されている分野です。アーティスト主体のツールを作れることにテクニカルアーティストの真価があります。複雑で高機能なツールが作れることよりも重要なことです。複雑で高機能なツールは、本職のプログラマに任せてしまえばよいのです。30日間無償で体験できます。30日間無償で体験できます。製品のご購入に関してご連絡を希望される場合は、こちらからお問い合わせください。