KLabGames Creative Blog

KLabは、多くのスマートフォン向けゲームを開発・提供しています。このブログでは、KLabのクリエイターがスマートフォン向けのゲームを制作・運営していく中で培った様々な技術や挑戦とそのノウハウについて紹介していきます。

Merry Christmas!! KLab Creative Advent Calendar 2019 の最終日は、
2019年に新卒入社した3DArtistのHASEが執筆させていただきます。

今回は私が普段有志の方達と一緒に行っている、
「60分スカルプト」についてご紹介したいと思います。

よろしくお願いします。

60分スカルプトについて

「60分スカルプト」とは、文字通り制限時間60分でスカルプト(ZBrush等で造形)する事です。

スケッチやクロッキーのように限られた時間の中でスカルプトすることで、細かい情報をそぎ落として対象物の重要な部分に注力するような癖が付き、モノを的確に捉える訓練になります。

そして、訓練を続けることでモノの本質に近づけるスピードが上がり、同じ時間で出来ることの幅が増えるため結果的に造形力の向上に繋がると考えています。

今回はそんな「60分スカルプト」をどなたでも効果的に実施できるようにルールを整えたので、どうぞご覧ください。

ルール説明

全体の流れ

60分スカルプトは以下のような流れで進行します。

①メンバー集め

②お題決め

③スカルプト

④発表・好評

続いてそれぞれの内容とポイントの説明です。

①メンバー集め

内容

  • 一緒に「60分スカルプト」を実施するメンバーを集めます。
  • 推奨人数は2人~6人です。

ポイント

  • 1人で実施することもできますが、複数人で実施したほうがマンネリ化防止になり、
    なによりも楽しいためモチベーションが継続します。出来れば複数人でやりましょう。

②お題決め

内容

  • お題が無いまま制作を開始してしまうと何を作るか悩んでるだけで時間が過ぎてしまうので、必ず開始前にお題を決めます。

  • お題は自由です。

    • 「ぶよぶよ」、「ゴリゴリ」のように擬音から連想されるもの
    • 「魚」、「鳥」のようなジャンルのみ決めて種類などは自由
    • 「オードリーヘップバーン」、「バッハ」のような固有名詞 等
  • 複数人で同じリファレンスを見ながら同じモノを作り、成果物を比較するのも面白いと思います。

ポイント

  • 得意なお題を選んでもいいのですが、せっかくなので苦手なジャンルに挑戦してみましょう。弱点を克服するチャンスになります。

  • 複数人で実施する場合はお題を考える担当を毎回変えることでお題に多様性が生まれるのでおススメです。

③スカルプト

内容

  • いよいよスカルプトに入ります。
  • 制限時間はもちろん60分です。
  • 時間の使い方は自由。リファレンス集めやシンキングタイムも含みます。

ポイント

  • スカルプトでのポイントは前述の「60分スカルプトについて」で説明したように細かい情報を省いて重要なポイントを押さえ、制限時間いっぱいまでモノを的確に捉えよう、伝えようと意識することです。

  • 慣れてきて制作スピードが上がってきたら、徐々に細かい情報を足していき作品のクオリティを上げていきましょう。

ちなみに

  • 余談になりますが、私はシンキングタイムを長めにとるタイプです。
  • 「お題に関連する知識があるか?」「お題を聞いて真っ先に思い浮かんだものは?」等と思考したのち、あえてまったく関係のないワードで検索をかけて面白いシェイプを探します。
  • ”火星人”というお題の時はなんとなく「ワイン」で検索をかけてみて、偶然見つけたコルク抜きの形状をもとに作りました(下のギャラリー参照)。

④発表・講評

内容

  • 出来上がった成果物について、なぜこのモチーフにしたのか、ワークフローの工夫等自由に発表します。

ポイント

  • 発表・講評のポイントは、せっかくのコミュニケーションの機会なので色々と楽しくおしゃべりしてください。
  • 私が仲間内でやっているときは作品のプレゼンテーションのほかに、お互い褒めあったり、アドバイスしあったり、時に雑談をしたりしています。
  • この時間が次のモチベーションに繋がったり、新しいアイデアが生まれたりするため、意外と有意義だったりします。

以上、ルール説明でした。

必ずしもこの通りに実践する必要はありませんが、重要なのは「気張らずとにかく楽しむ」ことです。

ZBrush Tips

ここからはスカルプト作業でよく使う機能のうち、存在に気づきにくく認知度が低いものを紹介します。60分スカルプトでもよく使う便利な機能ですのでぜひ活用してみて下さい。

  • オブジェクトに沿わせて伸ばす。SnakeHookブラシでAlt押しながらドラッグ。植物の根や、髪の毛、触手等、使いどころは様々。image9

  • BrushタブのDepth→Gravity Strengthの数値を上げることで、ブラシ効果が重力方向にかかる。溶けるような造形や皮膚のたるみ、しわ等に便利。簡単に説得力を出せます。image8


  • Zリメッシャーの機能でAlt押しながらリメッシャーかけるとシンメトリ方向が変わる。真ん中に集中頂点ができてしまうのを回避したり、編集しやすい方を選んで使う。image7


まとめ

「60分スカルプト」は私自身もまだ始めて間もない取り組みではありますが、

造形スピードの向上や作品のレパートリー増加などちょっとずつ効果が出てきたように思います。興味のある方は是非お試しください。

また、本日はKLab Creative Advent Calendar 2019の最終日です。

ブログ記事を担当するのは今回が初めてで、しかも最終日ということで心配でしたが、いかがでしたでしょうか?来年もまた機会があればなにか情報発信出来るように頑張ります!

ここまでお付き合いいただきありがとうございました!

それでは皆様、良いお年を。




おまけ:ギャラリー

ここからは私が実際に「60分スカルプト」で制作した作品になります。

良ければご覧ください。

お題:火星人

image6


お題:ファンタジー映画に出てきそうなやつ。

image1

お題:ネズミの騎士

image3

お題:龍

image4

お題:ファーブル

image5

はじめに

この記事は KLab Creative Advent Calendar 2019 の 24日目の記事になります。

こんにちは。クリエイティブR&Dグループ所属、みにーと申します。
私は現在、駆け出しTA(テクニカルアーティスト)としてシェーダー開発を行ったり、グループ内の開発環境整備などを行っております。

まず、「駆け出し」TAというところや、記事のタイトルから予測できるように、私はベースが完全アーティスト出身のTAとなります。
ジェネラリストとして、2D・3D両方とも幅広くやってきたことから、一つの技術に特化した踏み込んだ内容は書けないため、今回どのような内容の記事を書いたら一番興味深い内容になるのか、しばし悩みました。

思い返すと、私自身TAにジョブチェンジする際に、あまりアーティスト目線での参考資料が見当たらず苦労した記憶があったため、今回はそのような「アーティストだけど、ちょっとテクニカルなことに興味ある」方向けに、私がどのようにシェーダーについて勉強したかを、近年様々な箇所で活用されて来ているノードベースのビジュアルシェーダーエディタの紹介を交えてご紹介させていただければと思います。
(エンジニア出身でないがゆえに、フローがスマートではなかったり、主観的なところや我流の理解もあると思いますが、温かい目で見守っていただけますと幸いです…!)

こんな人にオススメ

  • アーティストだけど、ちょっとテクニカルなことに興味ある

  • ノードベースのビジュアルシェーダーエディタを触ってみたい

  • Unity上でシェーダーを作ってみたいが、コーディングできない

  • エンジニアさんの手を通さずとも、気軽にルックデブしたい

ビジュアルシェーダーエディタって?

ビジュアルシェーダーエディタは、コードを書く必要なくエディタ上でノードを作成し、コネクションを作ることで視覚的にシェーダーを構築できるツールのことを指します。

今回はUnityベースで解説したいと思っているので、

Unity公式のShader Graph

image2

AssetStoreで購入できるAmplify Shader Editor

image12

上記の2つのツールを使ってご説明させていただきます。

どこから始めればいいの?

image9

勉強を始めた当初の私は「とりあえずツールをインストールして触ってみたら分かるかも!」と安易な考えを持っていました。しかし、実際に触ってみたところ、概念も用語も何も知らない状態だと、やはり作業途中で躓く回数が非常に多く、ものづくりがスムーズにできるような形でツールを触りきれませんでした。

ビジュアルシェーダーエディタも結局のところ、シェーダーのコードをノード(Node)構造で作っているツールです。なので、最低限のUnity上でのシェーダーの仕組みは知っておかないと上手くノードを扱えなくなると感じました。

そこで、Unityのシェーダーについて解説されている、先人の方々の初心者向け資料を一通り読ませていただきました。

元々私がコーディング経験皆無という点から、上記の資料を読むだけではすぐさま「シェーダー作れるぞ!」というような理解まで追いつくことはもちろんなかったのですが、これだけは頑張って理解したいと思い集中的に読ませていただいたのは、「シェーダーの中身はどのような構造になっているのか?」です。

ざっくり説明すると、シェーダーについて全く何も知らない私が、一番知りたかった部分は以下のようなものでした。

  • どこが実際自分がシェーダーを書く部分なのか?

  • どこをいじれば、シェーダーの見た目に影響がでるのか?

  • 作られているシェーダーのプロパティはどこにあって、 パラメータは

    どのような風に入れ込まれているのか?

なぜ上記を知りたかったかと言うと、

  • どこが実際自分がシェーダーを書く部分なのか?

    • → 既存のシェーダー類をある程度参考できるようになれる

  • どこをいじれば、シェーダーの見た目に影響がでるのか?

    • → アーティストとして、一番シェーダーに求めていることは、

      どういう「絵」を表現しているかである

  • 作られているシェーダーのプロパティはどこにあって、 パラメータは

    どのような風に入れ込まれているのか?

    • → アーティストが実際与えられたシェーダーをマテリアルにアサイン

      した際に、一番触ることになる部分である(UI/UX的な影響)

image8

上記がある程度認知ぐらいはできる!というレベルまで来たら、
実際にビジュアルシェーダーエディタで、どのような「値」「命名」「形」でシェーダーを作れば良いのかイメージが湧いてきました。

早速ビジュアルシェーダーエディタを使ってみよう!

先述したように、私はこの時点ではまだシェーダー仕組みに関して100%理解がついて来ていません。しかし、ビジュアルシェーダーエディタの思想が「視認できる形でシェーダーを作る」という点から、ある程度のシェーダーに対する最低限の知識がついてきたこのタイミングだと作れるイメージが浮かんできたため、一旦SRP環境であれば無償で使える、UnityのShader Graphから試すことにしました。


image5

しかし私はまた躓くことになります。

image1

\\\ノードの挙動が文字とコードでしか説明されていない…!///

image4

そうです。数学とおさらばして数年…
いつの間にか私の脳は、図面がないと理解度が絶望的に進まないようになっていたのです。

また、Shader Graph自体、SRPという環境下でしか使えない分、当時参考にできるチュートリアルもそこまで見当たらず、このツールを使用しながらノードについても慣れて行く…そうするためには思った以上に時間がかかりそうだと感じました。

ビジュアルシェーダーエディタの思想と同じように、「視覚的」に各ノードの挙動が分かるようなマニュアル…挙動を可視化させている資料を私は探し求めるようになってきました。

その時、私はAmplify Shader Editor(ASE)と出会います。

  • 親切なチュートリアル動画!

image1

  • 親切な図面(Gif)+活用例付きのマニュアル!

image1

\\\これだー!!!///

image6

これこそが私が望んでた可視化されたマニュアル!
公式のチュートリアル、マニュアル、そして公式コミュニティでのサポートバフのおかげで、私はASEを使い始めてわずか3日目で、自作トゥーンシェーダーを組めるようになってました。

image13

ツールの仕様や、ノードの挙動を一つずつ熟知していったら、あとは簡単で、トゥーンシェーダーのみならずエフェクトにも使えそうなシェーダーとかもみるみると作れるようになってきてました。

Shader Graph?Amplify Shader Editor?

ここまでいうと、「ではShader GraphよりASEを使ったほうが良いの?」「ASEが優れているの?」というと疑問が出ると思うのですが、シェーダーを一から勉強している立場としてはリファレンスが充実していたASEの方が有り難かったというだけで、最終的には使用者のスキルセット・開発環境によってもどちらがマッチしているかが変わってくると思ってます。

私も現在は、プロジェクト環境や都合などを配慮して最終的にShader Graphを使用していますが、ASEの可視化されたマニュアルに触れたことによってノードたちの挙動の知見が得られ、今は特にツール自体につまずくことなくShaderGraphでも問題なくシェーダーが作れるようになりました。

ただ、現段階でどちらも使用したことがあるイチユーザーとしての感想は、Shader Graph自体、比較新しいツールのため、最適化部分や、使い勝手面でASEと比べてまだまだ改善できる点が多くあると感じました。

締めくくりとして、自分が使用して感じたShader GraphとASEの差や、
良かったところを簡単にご紹介させていただければと思います。

Amplify Shader Editorの利点

  • チュートリアル資料など初心者がすんなり入れるような参考資料が豊富。

  • 操作が快適。

    • 色分けされたグルーピングやメモなど、視認性良くノード類を整理しやすい。

    • Property Name(ShaderGraphで言うReference)もノード名を変えるだけで

      自動的に合わせて変換してくれる。(ShaderGraphは手動)

    • レガシーでもSRPでも特に劇的な差を感じることなく、コンパイル時間に

      とらわれずストレスフリーに作業できる。

  • レガシー環境・SRP環境関係なく使用することが可能。

    • レガシー環境で作ったシェーダーをそのままSRP環境に持っていき、ちょっと

      ノード調整してあげるだけである程度流用できるようになる(互換性がある)

  • ASEで作成されたシェーダーはコードの状態で出力され、かつ出力されたコードは

    その状態のままASEエディタ上で開ける仕様になっているため、コードが分かる人

    にレビューしてもらったあとにそのまま調整することも可能。

    • ShaderGraphの場合、MasterNodeでShow Generated Code押して変換して

      あげないと、コードの状態が見れない。かつ一度コードにしたファイルでは、

      エディタに戻れない。

Shader Graphの利点

  • Unity自体に入っているため、無料で誰でも使用できる。

    • ASEは有料 : $60

    • チーム内でUnityを持っているエンジニアさんとかにデータなどを直接渡して

      質問・レビューしてもらうことも可能(ASEの場合、基本1Seat 1Licenseの

      ため、使用する人数により購入が必要)

  • UnityのSRP環境下であれば、どのUnityバージョンでも使用できる。

    • ASEはUnityで公式リリースしたバージョンでしかサポートしていない。

  • Unity公式で出ているツールなので、今後に期待できる。

    • Unity新バージョンに追加される機能面とつながるノードなど、一番早く

      対応してもらえる。

    • サードパーティツールと比べて、公式ツールなのでサポート体制に関する

      リスクが低い。

これからビジュアルエディタでシェーダーに触れる

アーティストの方々に是非オススメしたいこと

自分用の作業ログを残しておく

image7

私は自分の記憶力を基本的にあまり信じてません。なので、なにか新しいものに触れる際は後から読み返しても分かるような形でとにかくメモ・ログを取っておくようにしてます。そうすることで、「以前この問題をどう解決したっけ?」と思い出せない時に、すぐ検索して遡ることができるからです。
また、このログを適度に社内の技術交流が活発なグループチャットなどで上げたりすることで、興味を持ってくれている方々のアドバイスも頂戴することができ、もっと勉強が捗りました。

一度自分が作ったシェーダーのグラフ画像をレファレンス化しておく

image1

以前作成したシェーダーのグラフ全体図のスクショを撮り、一つのレファレンスファイルとして扱うようにしてます。一度組んだことある仕組みを思い出す時にすごく助かっています。(私はPureRefと言うレファレンスツールをよく使ってます。)

最後に

TAは割と技術的な面に対してスポットライトが当たることが多いですが、

個人的にTAの本質的な役目は、いかにアーティストが居心地良く作業してもらえる環境を作れるかだと感じております。

シェーダー開発時にも、アーティストが追求したい表現に対して、デザイナー目線で物事を理解し提示できることが、アーティスト出身TAの強みだなと再認識するきっかけにも繋がりました。

今回の記事は、技術的な内容にフォーカスしているのではなく、結構長めの個人ログみたいな記事となってしまったため、あまり参考にならなかったかも知れません。
ですが、私のようにシェーダー作ってみたいけど、なかなかハードルが高くて挑戦できなかったアーティスト方々に少しでも役立てたのなら何よりです。

最後まで読んでいただきありがとうございました。

はじめに

この記事は KLab Creative Advent Calendar 2019 の23日目の記事になります。

こんにちは、KLabでサウンドを担当しています カトゥーン です。

近年、360°映像やVRの普及によりAmbisonics(アンビソニックス)を使用した立体音響がとても注目を集めています。そこで、サウンドチームでもAmbisonicsを使用した立体音響のあれこれを検証してみました!!

Ambisonicsの検証用に『ZOOM H3-VR』を導入。

今回はAmbisonicsを収録し、本体でそのまま再生することができ、
そして、専用のソフトウェアを使用すれば、ステレオやバイノーラル、5.1chサラウンドに変換してしまえる! ...と噂のZOOM社から発売されている『H3-VR』を 導入してみました!

このH3-VRは、4つのVRマイクを搭載して 360°全方位の録音が可能になっています。image15image14

従来であれば、Ambisonicsを収録後、様々な変換作業の後にようやく立体的な音響が聴けるようになるようなのですが、H3-VRは録音してすぐに本体から直接Ambisonicsの再生ができるので、録りたての立体音響を聴くことが出来とのこと!

そんな便利で高性能なH3-VRを使用して、以下の3つの事に挑戦してみました!!

~挑戦してみた~

  • H3-VRで実際にAmbisonicsを収録してみた。

  • ZOOM Ambisonics Playerを使用したAmbisonicsの再生と編集をしてみた。

  • H3-VRを使用したAmbisonicsデータのゲーム導入検証をしてみた。

挑戦 - 1 -

H3-VRで実際にAmbisonicsを収録してみた。

さっそく、H3-VRを使用して実際にAmbisonicsで音を取ってきました。image17image19

機材は、こんな感じで一脚にH3-VRを固定したバージョンと、映像用としてのカメラの上にH3-VRを装着したバージョンの2つで検証。

H3-VRは、収録する際に角度を設定できるので、マイク部分を下にしても問題なく録音出来ます。

録音時は、マイク端子から直接音を聴くことが出来ますが、ステレオ/バイノーラルでのリファレンスとなってしまうため、Ambisonicsで聴く際はデータ保存後に聴くのがお勧めです。

録音後に再生するとしっかりと立体的な音が録れており、感動しました!
また、このH3-VRを回したり、傾けたりすると…なんと、音の定位が変わっていきます!!

本体をクルクルと回転させると、まるで自分の周りで音が回転しているかのような感覚に…

image16image18

このH3-VRには、『電子水準器』が内蔵されている為、この様な面白い再生方法が実現出来ました! 他にも水平方向に対してマイクの定位確認が出来てとても便利でした。

挑戦 - 2 -

ZOOM Ambisonics Playerを使用したAmbisonicsの再生と編集をしてみた。

収録した後は、取り込む作業!…という事で、ここからはH3-VRで録音したAmbisonicsやバイノーラルデータをパソコンに取り込み、確認・編集の工程に進みたいと思います。

H3-VRをUSBモードにし、PCへ録音データを移したら Zoom がサポートしている『ZOOM Ambisonics Player』を起動し、取り込んだAmbisonicsデータを呼び出します。

image12

Ambisonicsデータを呼び出すと、この様な画面が出てくるので大きく表示されている球体を見ると、Ambisonicsを実感する事ができます。
ステレオだけではなく、バイノーラルや5.1chへの対応もされているのがとても興味深いです…。

色々録ったけど…ここだけ使いたいな!となった場合でもAmbisonicsPlayerの中で使いたい場所だけを選択してカットすることが出来るので、編集作業も簡単にできました。

編集を終え、使用したい場所を選択し、『EXPORT』からAmbisonicsを書き出すことが出来きるので、書き出してみました。

次に、書き出しを行ったデータがAmbisonicsから各フォーマットへ変換されAmbisonics以外で面白いことが出来ないか検証したいと思い、一緒に撮影した映像と合わせてみようと思います!

まず、バイノーラルの設定で書き出したAmbisonicsのデータを映像ソフト上で、確認しタイミングを合わせます。
image13

波形が挿入されたのを確認出来たので、カットなど編集作業の後、書き出しを行います。

レンダリングされた映像を聴いてみると、しっかりとバイノーラルの臨場感があり、その場にいる様なサウンドで聴くことが出来ました!!

今後は、5.1chサラウンドの設定などで動画を作り、5つのスピーカーからより臨場感を演出するサウンドと映像を作ってみたいと思います。

また、上記で制作した動画はこちらです!!

挑戦 - 3 -

H3-VRを使用したAmbisonicsデータのゲーム導入検証をしてみた。

さて、Ambisonicsのゲーム内実装を想定した検証もしてみましょう。
WwiseにAmbisonicsを実装する場合、FuMaまたは、AmbiXという録音モードで録音したデータを使用します。

インポートは、通常のオーディオファイルと同じように行います…。
新しくインポートしたAmbisonicsデータを Source Editor 上で確認すると波形がL / R / SL / SR と4つになっており、4ch Ambisonicsデータとしてインポートされたことが確認できました!!

image7

従来のこういった録音の場合、Ambisonics録音の多くはフォーマット「Ambisonics A」となっており、Wwiseやその他のゲームエンジンには対応しておらず…。

その為、DAWやソフトウェアなどを使用し Ambisonics B もしくは、FuMa に変換する必要がありました。

しかし、H3-VRを使用して録音すれば、録音の段階でWwiseやゲームエンジンに対応したAmbiXフォーマット、FuMaフォーマットに設定できるので、変換をする手間が大幅に省く事ができる事が大きな利点だと感じました。

~まとめ~

H3-VRを使用することで、今までとても大変で技術のいると思っていたAmbisonicsによる立体音響がより身近に感じられるようになりました。

とてもスムーズに収録ができ、収録したファイルの取り扱いも時間をかけずに管理することが出来るので、立体音響の研究機材として導入がし易く、扱いやすいです。

今後、こういった商品が普及することで商業だけではなくインディーズや教育の現場でもVRサウンドや立体音響が身近に作成、触れられる環境が出来れば良いなと感じました。

私も今後、H3-VRを使用した面白い事を沢山試していきたいです。

そしてゆくゆくは、旅行をした場所でAmbisonicsを録音し、VRサウンドとしてOculusやVIVEといったVRヘッドセット上で仮想的に音響旅行が出来る仕組みを構築して、ビデオブログではなく、VRサウンドブログなる物を開設してみたいです!

皆さんもAmbisonicsを使用した立体音響を是非試してみて下さいね!!

こんにちわ。UIUXグループのcoomaです。

デザインは分析可能?

image2

さっそくですが、こんな疑問を感じたことはないですか?

「デザインの良し悪しや、売り上げへの影響を数値で分析することってできる?」

アートは感覚的なものなので、それを数値にすることは難しいです。そのため、何が良いか、何を作るかは、好みだったり、声の一番大きな人の意見に左右されがちです。会社組織に在籍するアーティストなら、何度も自分の信念を曲げる悔しさを味わったことがあるに違いありません。

そこでロジカルにデザインの回答を導き出すための「デザインを分析する」という、過去の経験を踏まえ、これから注力していこうとしている取り組みとその可能性について話したいと思います。

デザインの良し悪しの指標として、まず「クオリティ」が挙げられます。じゃあクオリティって一体なんなんだ?まず、ここで躓きます。クオリティの定義が「丁寧さ」「ファン受け」「技術力」など、複合的かつ曖昧なので、これを数値化する術はありません。

2018のアドベントカレンダーでは「クオリティ」を成果物の分析という切り口ではなく、「技術力×時間」によって割り出されるものと定義し、労働環境改善の話として取り上げました。技術力を高め、効率化によって制作の時間を増やすことで、クオリティの量を増やすことができるという話しです。

今年は、この「クオリティ」そのものを科学的に改善する方法について取り上げます。なので、感覚的な話ではなく、アウトプットの成果物と、その結果の数値変化のみを材料とした取り組みの紹介です。その取り組みがどのようなものか、意味があるのかどうかも含め、ヒントになればと思います。

仮説の重要性

私はデータの専門家ではないので、分析の手法については説明しません。デザイナーとしてデータとどう向き合うかという話しになります。分析方法には色々な手法があります。視線解析のアイトラッキングや、二つのデータを比べるABテスト、ユーザーの遷移などを分析するプレイサイクル解析、いずれも専門的知識が必要であったり、ビックデータを扱う難しさがあります。ただ、それらの専門家に会って、話を聞くうちに分ったことがあります。それは「データだけでは意味をなさない」ということです。

配信された二つのデザインを比べて、一方の結果がデータとして良かったとします。デザイナーはそこから何を得るでしょうか?良い方のデザインを作った人が全部AさんならAさんが良いデザイナーだということでしょうか。デザイナーは時折、結果の良かった施策に対して「あれはデザインが良かったからだ」と内心で一喜一憂したりします。しかし、もしかしたら、商品のパラメーターが良かっただけかもしれません。

データは計測しただけでは、ただの事実でしかありません。ましてや一回ではなにも明らかにはなりません。「アイトラッキングをしても、あまり成果がなかった」というのを何度か聞いたことがあります。問題は、その結果に対して、どのような仮説を立て、次のアクションをどうするか、です。その結果、どの仮説が正しかったかが分かります。ただ、ここで強調したいのはこのPDCAではなく、仮説を立てるのはコンテンツの文脈(コンテキスト)を知る人にしかできないということです。つまりデザイナーだけが立てられる仮説があるということです。

image4

科学的デザインの効用

過去の事例ですが、ある球団のコンテンツを制作していた時、どのようなコンテンツがユーザーに人気なのか調査することにしました。そこで待ち受けを作成し、無料で配布しました。その時、待ち受けのタイプを、いくつかの言葉に分類し、4タイプを3人のデザイナーそれぞれ作成し、計12枚を配信しユーザーセグメントごとにダウンロード数をとりました。結果、一つのタイプに人気が集中しました。

そこで調査終了にせず、そのデザインタイプの何が良さなのか、調査することにしました。人気タイプのデザインをさらに言葉で分解し、モチーフとパレット、テイストに分け、組み合わせて12種類のデザインを配信しました。そこから明らかになったのは人気のモチーフや、パレット、テイストがあることでした。

その結果を踏まえたコンテンツを配信したところ、売り上げが3倍以上になりました。その理由は、販売数だけではなく、費用対効果が上がったことにあります。作るべきではないコンテンツに無駄なコストをかけなくて良くなり、ディレクションコストも減少しました。何を作るかが一目瞭然なためデザイナーが迷うことがなくなったのです。根拠のあるデザインの利点を考える時、このことは大事なポイントです。

実のところデータで導き出したデザインは予想の範囲内でした。しかし、もしデータ分析だけならこの答えにはたどり着かなかったかもしれません。コンテンツを知るデザイナーだからこそ立てられた仮説とアクションではないかと思います。

データ分析に必要な環境

上の事例のように、テストを繰り返すことができれば良いのですが、実情はそんなに簡単ではありません。同じ条件ですべてがKPIという結果に落とし込めるわけでもありません。例えばデザインのカラーパレットという要素だけを切り離して分析するのはデザイナーだけでは難しいでしょう。データの分析に詳しいエンジニアが社内で仕事を探してフラフラしている確率となると絶望的です。

現在はGoogleアナリティクスなど、手軽にデザイナーでも扱えるような分析ツールが用意されていて、いちいちツールを再発明する必要はありません。それに、一時期は500万円超えと言われていたアイトラッカー調査も現在では10万円もあれば機材が手に入るようになりました。脳波を調べるEEGやfMRIも企業単位で手の届くところまできています。

何よりGoogleScholaで検索すれば、専門家による、アートの分析に関する多くの論文を手に入れることができます。認知科学の分野の進化はめざましく、多くのデザイン関連に関するメタ分析論文が出回っています。何も、一企業が高価な機材を使い専門家を雇いデータを分析する必要はないのです。手軽にちゃんとしたエビデンスを手に入れることができます。課題は、論文を元に「こうなんです」という仮説を受け入れる企業文化があるかというところかもしれません。

デザイナーは変われるか?

時に分析の結果がデザイナーにとって衝撃的なことがあります。これまで良いとされて来たデザインのセオリーと反したりするのです。例えば、文字の可読性に関しては、「非流暢性」と言って、読みにくい文字が使われているほど、視聴時間が長くなり、ユーザーの記憶に残ると言われています(Diemand-Yauman,2011)。

image3

それから、広告効果が高いのは、画像中心で余白がある美麗なデザインよりも、文字の方が重要であることが調査により明らかになっています。科学的な広告の先駆者でもある、ジョン・ケープルズは「広告をデザインする時は芸術性を捨てなければいけない」と言っています。

もちろん、ブランディングには美麗なポスターの方が効果があるかもしれません。しかし、訴求バナーのような、広告商材の場合、通常のデザインセオリーが通用しないことが多いようです。その時、デザイナーがそれを受け入れられるかが問われます。

過去にデザイン分析をした時「デザインはデータ化できない」という意見により、分析結果が破棄されることがありました。これから検証方法がさらに進化していく中で、デザイナーは何を信じるのか、その在り方自体が問われていると感じます。

現状のKPI重視の傾向では、売り上げと、アートの良し悪しを切り離して、考えることが難しいでしょう。企画の良し悪しを切り離すのも同様に難しいのですが、大元を作成する企画に売り上げの責任がのしかかるため、アートの方向性に関しては企画に頼らざるを得なくなります。そのため、必然的に、企画側がアートへの影響力を強めることになります。

アートは正解がなく誰でも意見が言うことができます。時には、好みでの判断が、アウトプットに大きな影響を与えることがあります。デザインのデータ分析は、企画と制作の関係の図式を変える力を持っています。アーティストのロジックにエビデンスが与えられ、大きな交渉力を持つようになるでしょう。

これまでは感性やセンスがデザインにおいて覇権を握ってきました。クオリティ重視思考ですね。しかし、アウトプットされた細かい変数の変化で捉えれば、デザインもデータありきで考えることはできます。例えばKPIは、様々な要因が寄り集まった結果にすぎません。しかし、その結果に至る数多くの要因の中に情報が埋もれているだけです。アートが影響を及ぼしているパラメーターがどこかに潜んでいるはずです。

KPIからOKRに

image1

大切なのは仮説です。

「より良いUXにすれば、ユーザーのアプリの滞在時間が変化するはず」

例えば、これを元に、ユーザーのプレイサイクルを可視化を計画します。トータル滞在時間と、ページごとの滞在時間、どのページに遷移しているか、その割合。これをユーザーセグメントごとに取得し、可視化してみます。

アプリがリニューアルに失敗して炎上したというニュースを時々耳にします。理由は実態に即した改善ではなく、こうすると良いんじゃないかという一方的なお節介があったと推理できます。作り手のバイアスに陥っているのだと思います。しかし、リニューアルに対してユーザーはこう感じているかもしれません。「いつものボタンどこやった?」

想像とセンスだけではどうしても、運頼みになってしまいます。実際にどんな風に遊ばれているのかを調べるだけで、それは想像から仮説になります。可視化された図をみて、実際に使われていない遷移、本当にいて欲しいページでの滞在時間などを他と比較して見ることができます。

データは答えなのではなくて、事実を元に、仮説を立て、検証するための地図と言えます。その図から色々なことを読み取ることができます。楽しいのはここからです。つまり、どう感じさせたいのかをデザインするのです。その図から、現在のUXを知り、どのように改善するか具体策を考えればよいのです。

「このボタンはいらないんじゃないか」「デザインをこう変えればもっと押されるようになるのでは?」。その時OKR的な捉え方で「より良いUXにする」という定性的な目標に対して、特定の変数を鍵にして、アクションを組み立てます。そのボタンの押下率が増えるか否か。ゲームコアの滞在時間の比率が増えたかどうか。そこでPDCAを回せば改善への道筋ができます。

image5

データの可視化はクリエイティブ!(まとめ)

データ分析というと、専門家のみのものでひどく難しいような印象が初めはありました。しかし、やってみると実はとてもクリエイティブなものだと感じました。コンテキストを前提とした仮説の検証や、データの可視化など、むしろデザインのデータ分析において、デザイナーの領分だと感じました。データは答えではなく、物語のように色々な解釈を許します。仮説からデザインを組立てる能力は、デザイナーにとっての新しいクリエイティブスキルになってくるでしょう。

その中で大きな鍵となるのはデータの可視化ではないかと思います。デザイナーがみて、そこに解釈を入れられる図ができれば、もっと多くのデザイナーが分析に参加できるようになるはずです。それ自体をデザイナーがデザインすれば、データはデザイナーのミューズになるでしょう。根拠と目標をもってデザインを決定することができるのです。

「デザインには答えがない」と言われています。そのため、デザインは多方向からの感覚的な意見に振り回さることになります。しかし、これからは、多くのデザインに科学的な根拠を与えることができるようになるでしょう。データ・ドリブンデザインは、その理論に実体を与え、マスと対話するための強力なツールの一つになるでしょう。

はじめに

こちらの記事は KLab Creative Advent Calendar 2019 の 21日目の記事になります。

こんにちは。KLab株式会社クリエイティブR&Dグループ所属、kotuと申します。
R&Dグループではリギング&モーション周りのR&Dを担当しています。

KLab歴が浅くまだまだ新参者ですが、社内社外問わず、業界での交流をどんどん広めていきたいと、思い切ってAdvent Calendarの執筆に挑戦させて頂きました!

普段リギングに関する業務は主にAutodesk Mayaで行っているので、今回はMayaでのフェイシャルリグのキャプチャ対応に関する知見を掲載させて頂きたいと思います。

フェイシャルリグ伝統芸 Blend Shape (Morph)

image1

3Dソフトウェア(DCCツール、ゲームエンジンなど)で、キャラクターの顔の動きを作る手法の一つとして、「BlendShape」がよく用いられます。
頂点数などの構造は同じで、形が違うモデルを複数用意しておき、それぞれの形をブレンドして新しい形を作り出す機能になります。
この手法は、変形精度の高いアニメーションを作り出せるメリットを持つ反面、用意されたモデルパターンへの変形にしか対応出来ない、モデルの形状修正コストが高いことや、形状変化の過程はリニア補完でしか作れないなどのデメリットも挙げられます。

Blend Pose とは?

Blend Poseとは名前から伺えるように、コントローラーを操作して作った様々なポーズをブレンドし、最終的な動きを作り出す手法です。BlendShapeはバーテックス移動のブレンドに対し、Blend Poseはコントローラーの移動値や回転値、そしてスケール値、言わばTransformのブレンドです。
同じDCCツールの「Houdini」では、「Blend Pose」という名のノードが存在していますが、Autodesk Mayaでは機能として存在しないため、色々と試行錯誤を重ねた結果、類似性を持つノードを使って自力で構築することに挑戦しました。

今回のR&Dのプロジェクトではより豊かな表情を表現するために、自由度が高い、且つフェイシャルキャプチャに対応できるリグに挑戦するという目標がありました。BlendShape の持つデメリットを回避すると同時に自由度を向上させるため、ジョイント+コントローラーの構造でベースリグを制作しました。
フェイシャルキャプチャ対応では、Blend Poseに近い仕組みの実装に挑戦しました。

作ってみた

ここから、実際にBlend Poseらしき仕組みをMayaで実装する流れをフランクな感じでお伝えしていきたいと思います。

状況は?

今回のプロジェクトで採用したのは、Apple社のARKitを使ったFaceID搭載iOSデバイスによるFace Trackingソリューションです。顔の表情を52個のBlendShapeに細分化し、捕捉した変化量で相応のBlendShapeを駆動する仕組みです。

リグ側では自由度重視で、コントロールポイントはARKitのBlendShapeより更に細分化されているため、事前にコントローラーを使って各BlendShapeの変形を再現し、Transformの値をキャッシュとして保存しました。

その後、キャプチャで記録した各BlendShapeのウェイト値を元に、該当コントローラーのTransform値をブレンドすることになります。

発見!blendWeighted ノード

目標達成のために、MayaのノードエディターでひたすらTabキーで使えるノードをさがしていました。そこで目に留まったのは「blendWeighted」ノードでした。

image2

一見使えるプラグは割と少ない印象でしたが、アトリビュートを全表示させると

image3

色々と出てきました!
InputにWeight!しかも動的に増減可能なリスト型!これはもしや!?と試しに値を投げ込んてみたところ

image16

という内部処理を確認出来ました。

コイツは使えるぞ!

詳しく見ていきましょう~

実はこのblendWeightedノード、Mayaで1つのアトリビュートに対して複数ドライバーを持つドリブンキーを作成する時に自動で生成されるUtilityノードです。下図のように、複数入力を加算するだけだったため、Inputプラグしか使われていません。

image4

少し残念だったのは扱えるInputとOutputのデータタイプは単一なFloat型(浮動小数点数)で、TranslateXYZ、RotateXYZ、ScaleXYZのようなFloat3型(3つの浮動小数点数の配列)ではないため、組み込みに少し工夫が必要になります。

つないでみた!

説明のために簡単なシーンで動作確認をしていきます。

image5

シーン内のオブジェクト(すべてworld空間):
locator_og(コントロールされるロケーター)
locator_A(目標キャッシュA)
locator_B(目標キャッシュB)
locator_C(目標キャッシュC)
ctl(アトリビュートコントローラー)
ctl
にExtra Attribute として、各目標キャッシュへlocator_ogのTransformをブレンドさせる度合い(weight)をコントロールするアトリビュートを追加。

image6

ここからblendWeightedノードを使って構築していきます。

  • locator_ogのtranslateの3軸にblendWeightedノードを3つ用意し、それぞれのOutputとつなぎます。

  • locator_A、B、C、それぞれのtranslateを軸相応なblendWeightedノードのInputとつなぎます。

  • 最後に仕上げとして、各blendWeightedノードのウェイトリストに、ctlにある事前用意したweight調整用アトリビュートをInputリスト順につなげて完成!

image7

ctlのパラメータを調整してくと、想定通りの動きを確認できました!

image8

expression使ってsphrand()を送ってみると~

image9

動く動く~!
これでテスト完了です!

本番はどうだった?

本番リグのニーズ上、各コントローラーのTranslateX、Y、Z、RotateX、Y、Z、6つのアトリビュートをブレンドする必要があるため、下図のように各アトリビュートにblendWeightedノード1個を使って構築しました。

image10

コントローラーの多さにより、ノード数やコネクション数が膨大なため、Pythonスクリプトでバッチ処理を行い、上図の内容を各コントローラーに施し、そして各blendWeightedノードに52のWeight入力(下図)を構築しました。。。。この場においてはスクリプトの内容は割愛させて頂きます。

image11

最後に修正や加味用の手付コントローラーも加わりますと

image12

複雑なグラフになりました。。。汗

Blend Shapeのデメリットとして挙げた、変形過程のリニア補完は、下図のように、コントローラーの目標キャッシュの代わりに、アニメーションカーブをblendWeightedに入力することでリニア補完を解消出来ました。

image13

この作りにひと工夫加わえると、骨格に沿った変形など、細かいニュアンスもこれでできちゃいます!

image15

そんなにノードを使って性能面は大丈夫?

今回の運用ではコントローラー1個にアトリビュート6つ、そしてコントローラー総数69個で、合計414個のblendWeightedノードを使いました。
更に52のWeight入力を合算するとコネクション数40000超えになりましたが、社内のクリエイターPCではアニメーション再生時100fps以上と十分な動きをみせました。(アニメーションキャッシュOFF、再生設定は:Play Every Frame,Free)

オプティマイズとして顔各部分の可動域を絞った後、BlendShapeを掛け持ちしないコントローラーに対するコネクションを削ることができました。

ノードの自作も視野に

ニーズに応えるために、試行錯誤しながらの実装でしたが、この先もっと洗練された形として、Houdini の Blend Poseノードのようなわかりやすい、そして使いやすいノードを自作していきたいと思いました。

終わりに

ここまで Maya でのフェイシャルリグのキャプチャ対応に関する知見を紹介させて頂きました。

仕組みの肝となったblendWeightedノードに限らず、Mayaには様々なUtilityノードが用意されています。使い方の工夫次第で色んなことが出来ますので、興味のある方はぜひ試してみて下さい!

最後までご覧いただきありがとうございました!

この記事は KLab Creative Advent Calendar 2019 の20日目の記事になります。

こんにちは。KLab株式会社クリエイティブ部TA(テクニカルアーティスト)グループのmasahideと申します。

今年の5月には新人TAの業務内容についてブログを書かせていただきました。
今回は携帯端末ごとの描画スペックについてお話ししたいと思います。

概要

近年多くの種類のモバイル端末が世に出回っていますが、各モバイル端末がどれほどの描画能力(画面にモデルやエフェクトを表示する力)を持っているのかご存知の方は少ないと思います。

この記事では各モバイル端末ごとに、実際どの程度のモデルやエフェクトを描画する能力があるのか紹介し、どのような視点でリソースの削減をしていけば良いのか書いてゆきます。

今回はクリエイティブブログですので、デザイナー / アーティストさん向けにできる限り分かりやすく記載しています。

プログラマーの方から見たら省略しすぎていると感じる点があるかもしれませんが、ご了承ください。

「デザイナーだから端末の描画スペックを知ってもしょうがない」と思った方もいらっしゃると思いますがそんなことはありません

ゲームの処理負荷軽減のためにモデル、エフェクトの作り直し・調整をした経験のあるデザイナーさんも少なくないと思います。

端末ごとの描画スペックを事前に把握しておくことで、例えばモデルやエフェクトを制作する際にポリゴンの限界数やボーンの最大インフルエンス数(1つの頂点あたりに影響するボーンの数のこと)などがなんとなく分かるようになり、アセットの作り直しによる工数を一定削減することができるようになります。

テスト環境詳細

ゲームエンジン:Unity 2018.4.2f1
グラフィックスAPI:OpenGL ES2.0

テスト端末紹介

今回は下記の3種類の端末にて検証を行いました。
左から、GALAXY S3, GALAXY S5 Active, Google Pixel 3 です。

image7

端末名 チップ 発売年 備考
GALAXY S3 Snapdragon S4 2012年 Lowスペック代表
GALAXY S5 Active Snapdragon 801 2014年 Middleスペック代表
Google Pixel3 Snapdragon 845 2018年 Highスペック代表

モデル

1.ポリゴン数(トライアングル)

それでは、まず各端末でどれほどのポリゴンを描画する能力があるのか検証してゆきます。

image5

今回は画像のような1本の円柱を、UnityのStandardシェーダで表示するだけのプロジェクトで計測しました。

端末名/球体のポリゴン数 20万 35万 60万 150万 350万 500万 800万 1,500万
GALAXY S3 60FPS 56FPS 30FPS 19FPS 測定不能 測定不能 測定不能 測定不能
GALAXY S5 Active 60FPS 60FPS 60FPS 50FPS 30FPS 15FPS 測定不能 測定不能
Google Pixel3 60FPS 60FPS 60FPS 60FPS 60FPS 60FPS 54FPS 30FPS

図1.端末ごとの表示ポリゴン数とFPSの対応表(最大1,500万ポリゴン)

image2

図2.端末ごとの表示ポリゴン数とFPSの対応表(最大800万ポリゴン)

image1

図の1と2はどちらも端末ごとの表示ポリゴン数とFPSの関係をグラフ化したものです。

図1はGoogle Pixel 3を、図2はGALAXY S3とGALAXY S5の確認をしやすいように、表示する最大値の調整をしております。

上記の計測結果から端末ごとに表示できるポリゴン数に大きな開きがあることが分かります。仮に30FPSで動作するゲームを作成する場合、GALAXY S3は60万ポリゴン、GALAXY S5 Activeは350万ポリゴン、Google Pixel3は1500万ポリゴンを最大で表示できるが分かります。

実際のゲーム制作では、テスト環境よりも複雑な描画計算を行うことが多いため、大抵は使えるポリゴン数が大幅に減ってしまいます。

仮に、検証時の10倍処理負荷が重いGPU処理を行っている場合には、Google Pixel3であれば150万ポリゴンの描画までが30FPSで動作することができるという計算になります。

2.ボーンアニメーション

次はボーンアニメーションと処理負荷の関係について検証してゆきます。

今回はテスト用に円柱モデル(ポリゴン数4万)を8本準備し、インフルエンス数やボーンの構造が違うものをいくつか用意して検証を進めました。

このようなポリゴン数で検証を行ったのには理由があります。

  • 今回ローエンド端末として設定したGALAXY S3

    • 60FPSを安定して描画することができるポリゴン数が総合計32万ポリゴンであること
  • 今回ハイエンド端末として設定したGoogle Pixel 3

    • ボーンアニメーションを行った際に60FPSを割り始めるラインが総合計32万ポリゴンであること

つまり、上記の検証結果からハイエンド端末であってもボーンアニメーションの負荷によって60FPSを安定して描画できなくなる値として、一定の指標になることを証明するためです。



インフルエンス数2の場合

端末名/円柱一本のボーン数 0 50 400 1,000 5,000 9,000
GALAXY S3 60FPS 57FPS 52FPS 30FPS 10FPS 測定不能
GALAXY S5 Active 60FPS 60FPS 60FPS 55FPS 29FPS 15FPS
Google Pixel3 60FPS 60FPS 60FPS 59FPS 52FPS 32FPS

インフルエンス数4の場合

端末名/円柱一本のボーン数 0 50 400 1,000 5,000 9,000
GALAXY S3 60FPS 56FPS 51FPS 28FPS 8FPS 測定不能
GALAXY S5 Active 60FPS 60FPS 60FPS 55FPS 27FPS 12FPS
Google Pixel3 60FPS 60FPS 60FPS 59FPS 49FPS 30FPS

今回の計測では、GALAXY S3が1000本、GALAXY S5が5,000本、Google Pixel3が9,000本まで30FPSを維持することができました。

ゲーム開発において一つのモデルに1000本以上のボーンを使用することはほとんどないかもしれませんが、現行のハイエンド端末でも1000本以上のボーンを使用したアニメーションを8回おこなえば、60FPSを安定して描画できなくなることが分かりました。

※髪の毛やスカートなど、ボーンオブジェクト自体をリアルタイムにシミュレーションして揺らす、いわゆる「揺れ物」などはボーンの負荷がもっと上がります。

3.モデルまとめ

今回の検証では、ポリゴン数 / ボーン数 / インフルエンス数の3項目について検証し、
ポリゴン数 > ボーン数 > インフルエンス数の順に処理負荷に影響がありました。

しかし上記の結果だけで、「ポリゴン数だけ気にして作れば問題は起こらない」と結論を急いではいけません。

なぜなら、ゲームの要件・描画技法などの要因によってこれらの処理負荷は大きく変化してしまうためです。

デザイナーの方はプロジェクトのできるだけ早い段階で、そのゲームで表現したいことを明らかにし、そのうえで実現するための最適なレギュレーションをプログラマーやTAの方と策定してゆくのが良いと思います。

エフェクト

次はエフェクトの処理負荷について検証しました。

今回はUnityのパーティクルシステム(shurikenのCPUパーティクル)を使用して、
大量のパーティクルエフェクトを作成し、計測を進めてゆきます。

端末名/パーティクル数 5,000 8,000 10,000 50,000 100,000 500,000
GALAXY S3 59FPS 45FPS 40FPS 10FPS 測定不能 測定不能
GALAXY S5 Active 60FPS 60FPS 60FPS 30FPS 10FPS 測定不能
Google Pixel3 60FPS 60FPS 60FPS 60FPS 50FPS 8FPS

図1. 端末ごとの表示パーティクル数とFPSの対応表

image3

1.エフェクトまとめ

上記の計測結果から、30FPSで動作するゲームを作成する場合、GALAXY S3は2万、GALAXY S5 Activeは4.5万、Google Pixel3は30万粒のパーティクルを表示できることが分かりました。

モデルのポリゴン表示数について触れたところと同様に、あくまでこれらは最大数のため、実際にゲームを制作する際にこれほどの数は表示できないと思います。

ゲーム内で使用できる現実的な数に関しては、できるだけ早い段階でプログラマーやTAの方に相談をするようにしましょう。

まとめ

今回の記事を読んでいただいた方の多くは、端末ごとのスペックの大きな開きに驚かれたのではないでしょうか?今回の検証を通じて、私も驚くことが多かったです。

端末の種類によっては簡単にFPSが落ちてしまうため、下記4点を意識して制作を進めてゆけるといいと思います。

1.プロジェクトの早い段階で、プランナーとゲームの表現や端末を選定する。

2.やりたい表現を実現するため、プログラマーやTAの方と一緒にレギュレーションを選定する。

3.プログラマーやTAの方に処理負荷の計測を定期的に行ってもらう。
・レギュレーション違反をしているリソースデータがないか確認するため。
・想定よりも重いリソースデータ(ボトルネック)がないか確認するため。

4.ボトルネックになっているリソースデータの修正方法を、プログラマーやTAの方と決定する。
・必要以上にリソースデータの削減をしてしまわないために、必ずプログラマーや TAの方に相談をするようにしましょう。

最後までご覧いただきありがとうございました。