【CEDEC2016】テクニカルアーティストにおすすめのスライド

テクニカルアーティスト

CEDECに初参加してきました。
TAに関係がありそうなセッションとスライドのまとめです。

多文化のテクニカルアーティストチームの力の発揮の仕方

「国の文化の違い」、「プログラマーとアーティストの文化の違い」、「ゲームと映画の映像制作の文化の違い」をテーマにしたセッションです。
直接聴講したTAに関わるセッションの中では一番参考になったセッションでした。
TAという複数の職種の間に立つ職種として意識すべき「違い」が紹介されています。
それらの違いを理解した上で、TAとしては改めて以下のようなことを意識することが重要そうです。

  • プログラマー、アーティストの双方の作業や問題点を理解し、溝を埋める
  • アーティストの要望は真意を探り、プロジェクトで使えるものに落としこむ

CEDiLのセッション情報
スライド

世界で戦うソフトウェアエンジニア　～アカデミー賞受賞ツールMARIの開発現場から～

まだスライドが公開されてないんですけども。
3DペインティングツールのMARIを開発したエンジニアさんによるセッション。
MARI | 3D Texture Painting Software | The Foundry

エンジニアって新技術を使ってみたくなりがちだと思うんですけども、それがどんなに素晴らしいものであっても使ってもらえるものでないと意味がなくて、問題解決のツールとして落とし込むことが重要といったお話がありました。
また、エンジニアがユーザー（TAとしてはアーティストさん）と話すときは以下のようなことを意識するとよいとのことでした。

  • 要点を絞る
  • 技術的に細かいことは話さない
  • 問題の解決法を明確にする
  • ソフトを使ってくれることに感謝する
  • 情報を共有してくれることに感謝する

今世代向けプロダクションにおけるアセット製作のための、Mayaへのエンジン組み込み

MayaのViewport2.0をカスタマイズする話。
同内容に関して連載も始まってるみたいです。
area.autodesk.jp

また、サンプルプロジェクトもGithubで公開されています。
github.com

CEDiLのセッション情報
スライド

増やせ！アーティストＭＥＬスクリプター

スライドはまだ公開されてないんですが、タイトルの通りMELを書けるアーティストを増やしてみたよというセッション。
MELの学習を推奨したものの、個人（独学）だとうまくいかなかったので、講習会を開いたようです。
また、この講習会では一旦命名規則やファイルのディレクトリ構成、制御構文といったとっつきづらいところには触れず、まずドキュメントの読み方を教えた上で（特に実装例を見てみるなど）、Maya上で実行することで結果がすぐ見える形で進めたとのことでした。
学習→課題→評価という小さいサイクルを繰り返し、できたという感覚をつけてもらうのは初心者にとってはモチベーションが保ててよさそうです。
また、forといった制御構文を後回しにし、こちらはコードを書いてボタンを押すと勝手にシーン上のオブジェクトに繰り返し処理するMaya上で動くツールを提供した、というのはなるほどなと思いました。

この講習を終えたあと、希望者だけ次のステップに進み、最初飛ばした各種規則や制御構文に関しても講習を行い、あわせてサイクルを計画→作成→検証→改善のように変えることでツール制作が出来るような形に変えていったとのことでした。

Technical Artist Bootcamp 2016 vol.1

「プロジェクト配属型TAとしての働き方、組織活動の実例とツール開発のヒント」と「自作Mayaレンダラーの作り方 」についてのセッション。

CEDiLのセッション情報
スライド

Technical Artist Bootcamp 2016 vol.2

「Unityゲーム開発パイプライン事例紹介」と「続・Pythonを中心としたチーム開発」についてのセッション。

CEDiLのセッション情報
スライド

ゲームにおけるインタラクションのための音楽技術「MAGI」～瞬間、波形、重ねて～

インタラクティブミュージックと、それを柔軟に実現するためのMAGIというシステムに関するセッション。
直接的にTAと関係があるわけではないんですが、インタラクティブミュージックという制約がかかりがちなクリエイターによっては難色を示すような形態の音楽を、クリエイターの視点に立ってその制約を取っ払うような柔軟な設定ができるシステムの提供によって実現するという点は多分に学ぶところがあるなあと思いました。

CEDiLのセッション情報
スライド

まとめ

初日の基調講演も含めて、今回のCEDECでは以下のようなことを改めて意識しないとなーと思わされました。

  • 「違い」を理解すること
    • アーティストとエンジニアの感覚の違いなど
  • ツールのユーザーを理解すること
    • 一度ユーザーの立場で仕事をした方がより求められているものを求められる形で提供できる
  • 適切にコミュニケーションをとること
    • お互いの理解や、適切な分業をもたらし、それぞれが集中できる時間を増やすことにも繋がる
  • 重要な部分を兼任にせず専任にすること
    • 必要に応じて横軸の組織にすることでナレッジを生かしやすい
  • 新しいことに価値があるのではなく、役立つことに価値がある

【Unity】エディタ拡張でパフォーマンスを落とさずにScrollViewに大量の要素を表示させる

Unity エディタ拡張

f:id:tm8r:20160713192115p:plain
特定の条件に合致するアセットのリストをEditorWindowに表示させてごにょごにょする系の拡張を作ることがちらほらあるんですけど、アセットはまあ運用すればするほど増えていくわけで、その数が数千数万になっていくと単純に表示するだけだとUnityが悲鳴を上げます。

実際、まさか一気にそこまで増えると思ってなかったとあるツールで表示はできてこそいるものの、スクロールがまるで動かんみたいな状況に陥ったので、自前でカリングする方法を考えてみます。

ようは表示領域にいない要素は描画しなければいいわけです。

まずは表示領域の高さを取得したいところですが、GUILayoutのBeginHorizontal（BeginVerticalも同様）は戻り値がvoidなので、Rectが返ってくるEditorGUILayoutの同名メソッドを使います。
次にその中に表示されるリストの各要素の高さを定義し、その時点のスクロール量に応じたリストの先頭と末尾のindexを算出できれば、あとは表示領域の高さが変わらないように、要素を描画しない領域に本来描画されるはずの高さを確保してあげれば要件が満たせそうです。

f:id:tm8r:20160713193745p:plain
実際はこんな表示になっちゃだめですが、表示領域の上下の見えない部分にこんな感じで表示領域の高さを保つためのスペースがあるイメージです。

というわけで実装した結果が以下のような感じ。

これで表示領域だけに要素が描画される形になったので、リストの要素が増えても大きくパフォーマンスが損なわれることはなくなりました。
めでたしめでたし。

【Unity】Sceneビューやカメラのレイヤー表示を切り替える

Unity

普通にGUI上からいじれますが、どうしてもスクリプトでやりたいでござる…！というときのために。

以下のようにTools.visibleLayersを編集することで実現できます。

// UIレイヤーを非表示
Tools.visibleLayers &= ~(1 << LayerMask.NameToLayer ("UI"));

// UIレイヤーを非表示にして他は表示
Tools.visibleLayers = ~(1 << LayerMask.NameToLayer ("UI"));

// UIレイヤーを表示
Tools.visibleLayers |= (1 << LayerMask.NameToLayer ("UI"));

// UIレイヤーのみ表示
Tools.visibleLayers = (1 << LayerMask.NameToLayer ("UI"));

GameViewのカメラのcullingMaskも同じように操作可能なので、その場合はTools.visibleLayersをCamera.main.cullingMaskなどに読み替えてください。

また、上のコードではLayerMask.NameToLayerを用いてレイヤーのindexを取得してますが、勿論自分でindexを指定してもよいので、その場合はレイヤーのInspectorを開けば操作対象のindexが分かります。
（「UI」でいうと「Builtin Layer 5」になっているので5を指定する形）

Everything（全レイヤーを表示）に戻したい場合は-1を代入してやればよいです。

Tools.visibleLayers = -1;

【Unity】SceneViewのカメラを特定のオブジェクトに向ける

Unity

Hierarchyでオブジェクトをダブルクリックしたときと同じ挙動をScriptから再現するやつ。

public class FocusSceneViewCamera : MonoBehaviour
{
    [SerializeField]
    GameObject focusTarget;

    void Awake ()
    {
        SceneView.onSceneGUIDelegate += InitializeSceneCamera;
    }

    void InitializeSceneCamera (SceneView sceneView)
    {
        SceneView.onSceneGUIDelegate -= InitializeSceneCamera;
        if (focusTarget != null) {
            Selection.activeGameObject = focusTarget;
            sceneView.FrameSelected ();
        }
    }
}

前述の挙動の実装が、SceneViewのFrameSelectedを叩いてるっぽいんですけど、その中でSelectionからその対象を引っ張ってきているので、SelectionのactiveGameObjectを任意のGameObjectで書き換えた上で同メソッドを叩くことで実現しています。
こちらの例はゲームプレイのタイミングで一回だけ任意のGameObjectにフォーカスしてますが、Awakeで行ってる処理を行うメソッドを用意すれば好きなタイミングで呼び出せるかと思います。

正直あんまり使いどころはないですが、SceneViewのカメラとGameViewのカメラを同期したいケースでは使えなくもなかったりします。
同期は以下のようなメソッドを上と同じようにSceneViewのonSceneGUIDelegateに登録してあげれば実現できます。

void SyncGameViewCamera (SceneView sceneView)
{
    Camera.main.transform.position = sceneView.camera.transform.position;
    Camera.main.transform.rotation = sceneView.camera.transform.rotation;
}

【Maya】作成したツールの設定を保存する

maya python

Mayaのツールを作ったものの、その設定を次回起動時も引き継ぐためにはどうしようか、jsonか、csvか、どこに保存しようか、と思ってたらどうやらoptionVarという便利メソッドがあるようで。

help.autodesk.com

import maya.cmds as cmds

saveKey='myToolWindowWidth'

# 無ければ追加
if cmds.optionVar(exists=saveKey) == False:
    cmds.optionVar(intValue=(saveKey, 300 ))

# 取得
print (cmds.optionVar(q=saveKey))

# 削除
cmds.optionVar(remove=saveKey)

という感じで使えます。
上書きは追加のときと同じ形です。

このメソッドを使って保存した内容はユーザーごとのprefsディレクトリのuserPrefs.melに保存されます。
Macでいうとこのあたり。

/Users/ユーザー名/Library/Preferences/Autodesk/maya/2015-x64/ja_JP/prefs/userPrefs.mel

Mayaがぶっ壊れたときにprefsディレクトリを消すみたいな悲しいオペレーションがあったりするので、そのときは泣いてもらうほかないですが、基本的にはこれで簡単に設定の保存、読み込みができそうです。
べんり。

【Unity】Unityに出力可能なエフェクトエディタ「SPARK GEAR」

Unity

sparkgear.net
UnityとCocos-2Dxに対応しており、大量のテクスチャやエフェクトのバンドル、簡単なモデルの作成、スマホ実機にリアルタイムで変更が反映できる、などが売りの新しいエフェクトエディタ。
ドローコールの削減など、負荷削減に関する対策もされているようで、期待が高まります。

詳細は上記公式サイトと、以下のページ、スライドが参考になります。
jp.gamesindustry.biz

www.slideshare.net

スライドの最後にもある通り、現在機能制限のあるフリー版が無料配布されています。
ダウンロードは以下の公式Facebookページから。
株式会社Spark

起動にはいくつかランタイムが必要なので、zip解凍してReadmeを読みましょう。
（Readme.txtを読む文化をすっかり忘れて一人で「起動しない…！！」ってなってました）

尚、エディタはWindows専用なので、MacユーザーはVirtualBoxとかで試す感じですね。
サンプルがいくつか含まれているので、使い方がわからない場合はサンプルを見て各種設定を確認することが出来ます。

このフリー版にはSDKなどが含まれていないので、Unityでの動作確認はできなさそうです。
サイトによると、

Unity,Cocos2d-xの組み込み再生が可能。逆にUnityなどで制作したものを再利用することも可能。特にUnityではPrefab化したリソースをスクリプトからPlayするだけで組込可能。
（エンジンの依存性なし）
ランタイムを組み込むことでSPARKFXエディターで制作したアセットをiOS,Android,OSX,Windows上で再生できます。
http://sparkfx.jp/main/%E5%B9%85%E5%BA%83%E3%81%84%E4%BA%92%E6%8F%9B%E6%80%A7/

とのことなので導入は容易そうですが、実際のところは使ってみないと分からないのと、初期費用100万円+月額20万円は容易に出せない（白目）ので、一旦は今後利用者が増えてレポートが出るのを待つばかり。

スポンサーリンク