Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷 に行ってきました #gotandaunity

五反田で開催されないと定評のある『Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷』に行ってきたので雑なメモと、拾えただけのスライドを貼っておきます。

gotanda-unity.connpass.com

LT #1 シンプルStateMachine

@k-wth さん

docs.google.com

• ステートマシン"1号"、シンプルなうちはよかったが、Stateの入れ子など複雑化し、バグの温床に
• シンプルな"2号"を作った

LT #2 シェーダー芸・入門から1ヶ月の道のり

@nimu026 さん

docs.google.com

• 8月のJAPANLAND花火大会＠VRChatに触発されてシェーダ芸を
• Shurikenでなく、GPUパーティクル？　シェーダ芸？
• Compute ShaderはVRChatに持ち込めない
• phiさんのシェーダ芸
• Vertex Shaderでもなく、Fragment Shaderでもなく、Geometry Shader
• Geometry Shaderで動かしてFragment Shaderで塗る
• ひたすら写経したり改変したり

LT #3 NCMBでオートログインとセーブデータのバックアップ

@azumagoro さん

docs.google.com

• 個人開発ゲーム。v1はローカル保存、v2からNCMB
• JsonUtilityでシリアライズ。EasySaveではList<>を保存できない
• masterから取得できるデータはkeyだけ持っておく（節約）
• NCMBの課金体系が変更されて痛い

LT #4 ObservableパターンからはじめるUniRx

@torisoup さん

niconare.nicovideo.jp

• Observerパターン
• ObserverとSubject、印象が逆なので注意。Subject側が管理してる。Observerは監視・管理はしていない

LT #5 PUN2触ってみた

@otyugen59 さん

speakerdeck.com

• Photon Unity Networking
• PUN2が8/25リリース
• PhotonRx（とりすーぷさん作）
• コールバックが変更されているのが一番影響大きい

PUN は 開発者の Tobias はパンと発音してたけど、日本ではピーユーエヌって読む人が多い気がする

— やまさん(S.Yama) (@syyama_net) 2018年9月26日

LT #6 ここが楽しい/しんどいLive2D CubismSDK for Unity

@traitam さん

docs.google.com

• v2.1とv3.0で互換性がない
• "うちの子・推しを動かせる"のが一番楽しいところ
• ドキュメント、情報発信者が少ない（Editorの話はあるけど）
• 畑を耕さないと

LT #7 Tilemapのアップデートについて

@RyotaMurohoshi さん

speakerdeck.com

早速ブログ記事も

mrstar-logs.hatenablog.com

• 2018.2から、Hexagonal Tile
  • Point top/Flat topがある
  • コンポーネントは同じもので、propertyで切り替えられる
• Isometric Tile
  • クォータービュー
  • まだベータ
  • オクルージョンできる。高さがある

こういうのやりたくないですか！#gotandaunity pic.twitter.com/1H6NBl5qH8

— むろほし (@RyotaMurohoshi) 2018年9月26日

• Let's 人柱！

LT #8 スコープファンクションでコードの見通しを改善する

@yashims85 さん

speakerdeck.com

• 関数に切り出すほどでもないもの*1
• Kotlinの文脈で出てくる
• 引数にselfを渡して、Lambdaの中でプロパティをセットするなどして、selfを返す
  • Also(that => {that.x=0;... return that} とか
• 一時変数が減ってコードの見通しが良くなる
• Null安全

LT #9 4画面出力とレシート印刷で作る体験型デジタルサイネージ

@ksk1030 さん

speakerdeck.com

• マルチディスプレイ
  • ディスプレイごとの設定、リフレッシュレート、アス比
  • UnityのindexとOS上の番号が一以しない。ケーブル挿す順で変わる？
• レシートプリンタ
• Windowsタッチパネルのエッジスワイプを抑止したい→物理的に抑止した

LT #10 Scene操作系のエディター拡張Util2セット

@takumi_hanzawa さん

Scene操作系のエディター拡張Util2セット from Takumi Hanzawa

www.slideshare.net

• マルチシーンエディティングで、アクティブを切り替えるのを2クリック→1クリックに
• シーンの読み込み履歴。ヒストリーウィンドウで1クリックでロード

所感

LT10本、Unityの扱う領域の広さをあらわすように、幅広く、話の被りもなく、とても面白い回でした。

聞いた話が役に立つ日が来るのか？と言われると、まず無い、と言い切れるトークが多かったのですが、それはそれ。役に立つ話を聞くばかりが勉強会ではないと思っているので、このノリは引っ張ってほしいところです。

なかでも、マイノリティな技術の孤立無援っぽい話は共感するところもあり、それでも「畑を耕さないと」「Let's 人柱！」といった前向きな言葉がよかった。

また次回は2ヶ月後ということで、何かネタがあればまた登壇も検討しようかという気持ちになったと同時に、前々回のフォローアップ記事をまだ書いてないことを思い出したり…

関連資料

Unityゲーム プログラミング・バイブル

*1:個人的には「関数に切り出すほどでもないもの」は関数に切り出すほうが好きです。テスト書きやすいし

フォトグラメトリでバ美肉(1.5) Qlone

フォトグラメトリツールの紹介・比較をしていくつもりはないのですが、例外としてひとつだけ。iOSおよびAndroidで動作するQloneというアプリについて。

www.qlone.pro

対象は小さい物体に限りますが、ガイドに従ってスキャニングし、クラウド上で3Dモデル生成までやってくれるアプリです。アプリ自体は無料で使えますが、生成された3Dモデルをobjなどの形式にエクスポートするのに課金が必要です。

フォトグラメトリについてや注意事項などについては、前回の記事を参照してください。

スキャニング

撮影には、専用のマットの印刷が必要です。これはアプリから直接AirPrintか、pdfファイルを取得して自分で印刷します。被写体をマット上に置いて撮影するのですが、A4サイズのマットで高さ10cmくらいのフィギュアが限度です。

A3サイズで今回の被写体（高さ17cm）がなんとか収まりましたが、それでも上部のえんぺらあたりがキレイにスキャンできませんでした。

また、被写体の向きを変えて（フィギュアを倒して）もう一度スキャンすることが推奨されていますが、A3マットの場合スキャン中に数回（恐らくメモリ不足で）アプリが落ちたので、今回は1回だけスキャンしています。

これで、148,343頂点、581,760ポリゴン、テクスチャは2048x2048が1枚です。

エクスポート

エクスポートは、スキャンしたモデル単位にアンロック権を購入する形式で、1モデル¥120から無制限¥2,400まで。obj, stlのほか、iOS 12から使えるUSDZ形式*1にも対応しています。

なお、アンロックはモデル単位ですが、アプリ内でモデルの複製を行なうと権利もコピーされます。

また、Sketchfabへのエクスポートも可能です。アンロックしていないとダウンロードできない設定、アンロックしているとダウンロード可能設定でアップロード・公開されるので注意。 SketchfabのProアカウントでは試していないので、privateにできるかは未検証です。

エクスポートしたモデルをBlenderで見るとこんな感じ。テクスチャは余りキレイではないものの（これは撮影環境の問題も大きい）、メッシュはそれなりに取れています（うまく辻褄を合わせている、が正しい気もしますが）。

胴（頭足類なので）の上のほう、えんぺら周辺のメッシュが荒いのは、恐らくA3サイズマットでの限界なのだと思います。

リサイズツール

Qloneにはある程度の加工ができるツールも実装されています。例えば、編集 - RESIZE - Simplifyでポリゴン数の削減もできます。

削減前1（148k頂点、582kポリゴン）

削減後1（62k頂点、174kポリゴン）

かなりメッシュの大きさにばらつきがありますが、自動でやってくれます。3DF Zephyrのリトポロジー機能と違って触手の先などのエッジはキープされるようです。

削減前2（148k頂点、582kポリゴンのはずですが表示がおかしい）

削減後2（34k頂点、100kポリゴンくらいのはずですが表示がおかしい）

その他のツール

テクスチャのペイント、スカルプティング機能もありますが、やはりスマートフォンでの操作には限界があると思いますので、素直にPCのツールでやるほうがいいでしょう。

ほかに、ボクセル化の機能もあります。

所感

意外とメッシュは取れていて驚きました。モデル単位の課金というのも使いやすいですね。PCでのリトポロジーやレタッチ前提で、メッシュのアタリが取れるクオリティでいいといった条件では十分実用的ではないでしょうか。

ただ、大きめの被写体にはそれなりのサイズのマットを印刷して用意する必要があることと、大きくなるほどアプリが落ちやすい*2のが難点です。

参考

いかレスラー

*1:SafariでリンクするだけでAR表示もできるアレ

*2:スキャンを試したのは数週間前なので、すでに改善されているかも知れませんが

フォトグラメトリでバ美肉(1) 3DF Zephyr

たくさんの写真から3Dモデルを作り出すフォトグラメトリ(Photogrammetry)があれば、モデリングができなくても絵心がなくても、フィギュアからVRChatやVRM向けのアバターを作ってバ美肉*1できるのでは？ ……などと甘い考えのもと、試してみた結果を晒します。

結論と注意事項

いきなりですが、結論として、2つの理由からフィギュアからフォトグラメトリしたモデルをアバターに使うことはないでしょう。理由は、クオリティ（コスト）の問題と、権利的なものです。

クオリティ（コスト）面

前提として、今回の作例は、かなり雑なライティング・雑な撮影・ろくにレタッチしない、という三重苦のもので、正直ソフトメーカーさんに申し訳ないレベルのものです。

少し頑張れば、背景オブジェクトやプロップ的なものには十分使えるものが私にも作れるとは思います。が、アバターとなるとさらにリギングして動かすための工数もかかるので、もう「素直にモデリングを頑張るべきでは」という気持ちになりました。

誤解してほしくないのは、フォトグラメトリがクオリティ低いのでないということです。今回くらい雑に作ってもこのレベルの成果物が得られるというのはすごいことなので。

権利面

フィギュアはほぼ間違いなく誰かの著作物です。使いかたによっては、単にキャラクターのIPだけでなく、そのフィギュアを作ったメーカーの権利をも侵害することになります。

特撮界隈では改造怪獣とか昔からあるわけですが*2、同じノリでフォトグラメトリで得たモデルを素体として改造してーというのも、イラストにおけるトレースと似たようなものですし、やはり避けるべきでしょう。

結論は結論として、以下、作例として進めていきます。

3DF Zephyr

3DF Zephyrにはいくつかエディションがありますが、Lite Steam Editionをサマーセールで購入しました。解析できる写真枚数に500枚という制限がありますが、建造物や空撮などしなければ十分でしょう。フィギュア程度なら、Free版の50枚でも十分なはず。

store.steampowered.com

チュートリアルやマニュアルはこちらに。

https://www.3dflow.net/technology/documents/3df-zephyr-tutorials/

バージョン4.009をインストール後、こちらのブログにある、座標系をY Upにする設定だけ行ないました。初期値については、Zephyr 4.xでは英単語になっていました。

manabuokajima.hatenablog.com

写真を撮る

写真は、フィギュアを台に固定して、その周囲を回りながら細かく撮影していきます*3。一般的な室内では足元に影ができてしまうため、曇天の屋外での撮影が良いようです。

Zephyrのマニュアルによると、撮影は以下の要件を満たすことが好ましいみたい。

• ISO感度: 低め
• 絞り: 高め (f/8 - F/16)。広い被写界深度が得られる
• 焦点距離は固定
• 各写真の間に重複があること (70-80%)
• 各写真の角度をできるだけ保つ

本作例は、室内の蛍光灯ひとつの下という劣悪な環境で、iPhone Xで撮影しています。カメラアプリは"Adobe Lightroom CC"のマニュアルモードで、Sec: 1/10, ISO: 40, WB: 蛍光灯 の設定。

また、簡易なレフ板（段ボール板にアルミホイルを貼ったもの）を使用しましたが、フィギュアを丸テーブルに載せていることもあってあまり有効に使えていません。

低密度点群生成

3DF Zephyrを起動し、ワークフロー > 新規プロジェクト で写真を取り込み、低密度点群を生成します。デフォルト設定で2〜3分。

下方にある茶色の点群はフィギュアを置いた丸テーブル、中央付近に、ほとんど見えませんがフィギュアがいます。上方に円形に散らばっている青い四角錐は写真の撮影位置を示しています。

この点群を生成したときの写真は94枚、うち63枚が有効でした。1/3ほどの無効写真はランダムに点在したのではなく、ダメな方向からの写真は複数枚まとめて無効となることが多いです*4*5。結果、その角度のディティールは大幅に損なわれます。

この段階で、周囲の不要な点群は処理対象から外すことができます。グレーの立方体が処理対象となる「境界ボックス」で、この外にある点群は無視されます。また、もっと柔軟に、不要な点群を選択して削除していくこともできます。

高密度点群生成

続いて、ワークフロー > 高密度点群生成 を実行します。デフォルト設定で10〜15分くらい。

前掲の岡島さんブログによると、高密度点群の時点では何も触らないほうがいいようです。

メッシュ抽出

ワークフロー > メッシュ抽出。2〜3分。

背景（部屋の壁や家具）が丸テーブルの周囲にバリ*6のようにメッシュ化されてしまったので、これを削除します。

近づくとこんな感じ。うちに美少女フィギュアがなかったので、被写体には"美味しそうなイカ"フィギュアを使用ました。バーチャル美味しそうなイカ肉！（タイトル回収）

この時点で、頂点: 39,084、三角ポリゴン: 77,823

これを削減します。手段はZephyr上でも複数、外部ツールもいくつかありますが、それらは改めて検証したいので、今回はZephyrのリトポロジーツールを使います。

ツール > メッシュフィルター > リトポロジー を、factor: 5.00、repert: 10 で適用*7。

結果、頂点: 8,933、三角ポリゴン: 17,497 まで削減できました。VRChatアバターの制限が20,000ポリゴンなので、パスできるはず。

見比べると、触手の先やえんぺらなどのエッジが欠けて（丸くなって）しまいましたが、今日のところはこのまま進みます。なお、テクスチャのぼやっとした感じは後工程でほぼ気にならなくなります。

ポリゴンメッシュはこんな感じ。

リトポロジー前

リトポロジー後

テクスチャ付メッシュ作成

ワークフロー > テクスチャ付メッシュ作成 でテクスチャが貼られます。本例では、最大テクスチャサイズ: 2048、最大数:1 としました。

スケール/回転/平行移動

ツール > ワークスペース > オブジェクトのスケール/回転/平行移動 という機能があるのですが、スケールは単位が、平行移動（原点座標）は、そもそもの基準点がわからないため、Zephyrで調整するのはあきらめました*8。

ここでは回転だけ行ない、Y+を上方向、Z+を正面方向に設定します。テーブルの面を使って、ツール > ワークスペース > 平面を選択して上向きベクトルを定義 で上方向を指定すると楽です。

テクスチャ付メッシュを出力

出力 > テクスチャ付メッシュを出力 で、.objもしくは.fbx*9ファイルにエクスポートします。

エクスポート時のオプションに"ローカル表示基準システム”(local rendering reference system)がありますが、これは、

• off: ワークスペース上のスケールと座標がモデルに反映される。ただしスケールの単位が何かわからないし、原点がどこかもわからないので、人類にはコントロールは難しい
• on: ワークスペースのスケールと座標が無視される。サイズはすごく大きい（xyz各100倍くらい）、座標はモデルの中心になる

3DF ZephyrのWebサイトには

if you are using geographical coordinates, you may need also to check “Local Rendering Reference System” as well.

とだけありました。空撮でないのでgeographicalな座標がないから上記の振る舞いになってる？のでしょうか。

リギングするならBlender等で調整しますし、今回はUnity直送ですがUnityで調整すればいいので*10、どちらでも構いません。

Unityにインポート

エクスポートしたfbxをUnityにドラッグ＆ドロップ。試しにVRChatのHome Kitにある部屋に配置してみました。

いかレスラーの身長を設定*11に忠実に242cmとしたのですが、胴が（頭足類なので頭部の上は胴です）天井を突き破ってしまいました。本編および本物のぬいぐるみ（着ぐるみ）を見た感じ、もう少し小さくていいような気がします。

なお、向かって左はスマートフォンアプリ"Qlone"で作ったモデル、右は野良犬祭2でDiGINELさんが持ち込んでいた撮影ブースで撮影してもらったリアルアバター（60,000ポリゴン・テクスチャ8192）。

Qloneについてはこちらを参照。

とりあえず今回はここまで。次回以降、リギングとかリトポロジーとかディライティングとかやっていく予定です。飽きなければ。

補足

以下、おまけ。

フィギュア撮影の難点

これまでに掲載したスクリーンショットからも、触手の間、下側、また足元などのクオリティが低いことが見て取れたはずです。これらは撮影環境の悪さが大きいのですが、フィギュア相手ではよほどライティングを頑張らないと足元の影の影響は残るでしょう。

今回はそれだけでなく、右後方はメッシュもテクスチャもおかしくなっていました。この方向からの有効な写真が無かったことが主な原因でしょう。

またアオリ（ローアングル）で撮れていないため、下側のメッシュには穴が空いていたりします。

上下逆にして撮ってみる

回避策として、被写体を上下逆に置いて撮影、フォトグラメトリ処理したモデルを結合させるのがいいのかな、と思っています。試しに撮ってみた例が以下。

吸盤のモールドまでバッチリですね。

なお、被写体を三脚の上に立てての撮影も試みましたが、いかと部屋の壁の色が近いこともあって、肝心の被写体が壁に溶け込んでしまいました。上例の丸テーブルのような拠り所も必要なのではないかと。

その他の作例

先日、小石川後楽園の円月橋を片面だけ撮影してきたものをSketchfabに上げています。片面だけなので少し角度を変えると破綻しますが。これで元写真67枚です。

Engetsukyo bridge by nowsprinting on Sketchfab

参考

manabuokajima.hatenablog.com

いかレスラー

*1:バーチャル美少女受肉の略。またたく間に広義から狭義までゆらぎのある言葉になったが、発祥についてはこちらの記事が詳しい https://www.vtuber-housou.com/babiniku/

*2:それが無ければジラースとかミレニアムファルコンとか存在しなかったわけですが…

*3:フィギュアを手に持ったり、台を回転させたりしての撮影したものは使えません。背景も含め特徴点を取るので、動かないことが要件なのです

*4:上のスクリーンショットでも、円形に並んでいる青い撮影点が二箇所途切れているのがわかるはず

*5:原因は恐らく、背景に特徴点が少なかったり、明度によるものだと思われます

*6:バリって英語のBurr、バリ取りはDeburringなんですね

*7:ちなみに［フィルターを適用］ボタンは編集対象のメッシュを上書き、［フィルタを有効にする］ボタンはコピーを作って適用してくれます。わかりにくい！

*8:スケールはZephyr Pro/Aerialなら設定できるようです

*9:マニュアルにはPro/Aerealのみと書かれていましたがLiteでもできました

*10:Transform - Scaleは、ライティングや物理を入れるときには1（等倍）であることが望ましいのですが、今はまだ置いてみるだけなので

*11:劇場公開時のパンフレットより「242cm（アンドレ・ザ・ジャイアントより大きい）」

Unity #Zenject完全に理解した に行ってきました

株式会社ミクシィさんで開催された『Unity Zenject完全に理解した』に行ってきたメモ。

connpass.com

配信アーカイブもあります。すばらしい。はじめ機材トラブル等ありますが解消します（ネタバレ

www.youtube.com

Zenjectとは、オープンソースのUnity向けDI(Dependency Injection)フレームワークです。 Zenject以前に「DIをよく知らない」という方は、まず、とりすーぷさんの『インタフェースの使い方』から見るのがいいでしょう。ここで、DIというものがなぜ必要か、なにを解決してくれるものか、がわかるはずです。

もし『インタフェースの使い方』が何を言っているのかわからないのであれば、今日のところはUnity仙人さんの『Zenjectはじめの一歩：ゲームデータをScriptableObjectでInject！』だけにしておくのがいいのではないでしょうか。

この手のツール・フレームワークは、手段から入ってしまうとマズロー*1の言う

ハンマーを持つ人にはすべてが釘に見える

状態に陥りがちです。

Zenjectのような強力な手段を乱用すると、結果的にそのデメリットだけがプロジェクトに残ってしまうことになりかねません。（完全に、とは言わないまでも）ある程度は理解した上で導入していくことをおすすめします。

ほんこれ #Zenject完全に理解した pic.twitter.com/rHE8trh2br

— デコシ (@Ash_Yin) 2018年9月6日

ゲーム案件にZenject導入した経験を語る

かせ(@KaseliaePenguin)さん

実際のプロダクトにZenjectを導入した経緯（目的）、試行錯誤したこと、どの範囲に適用すべきか、適用する上での注意点など盛りだくさん。

• SceneContextを4階層（System, Data, Env, Logic）にしてそれぞれの扱う範囲を明確化し、切り替え（本番とデバッグの置き換え等）を制御
• Bind時のAsSingle(), AsCached(), AsTransient()の違い
• [Inject]を書いたフィールドのバインドはnew()の後に行なわれる
• SceneContextの理解が大事
• InjectするものにはInterfaceを切り、InterfaceをInjectすること
• Bindはリフレクションを使うので遅い
• 真価は運営フェーズに入ってからのはず

speakerdeck.com

文脈を操る 美しきZenjectプロジェクトからの眺め 〜Contextの扱い方と活用方法〜

Mikito Yoshiya(@mikito0521)さん

4種類あるContextの階層構造と、またそれを入れ子にできる話、実際にリリース版とデバッグ用のContextを切り替える例など。

• Contextを意味のある単位に分割して切り替える
• ProjectContext, SceneContext, SceneDecoratorContext, GameObjectContext
• それぞれ入れ子にできる
• IDisposableを実装すると、Contextが破棄されたタイミングでDispose ()を呼んでくれる
• 大事なのはInstallerの設計。Contextとの組み合わせ
• 依存がわかりにくくなるので、SceneContextは二階層くらいにしておく。小さいものはGameObjectContextにまわす

文脈を操る美しきZenjectプロジェクトからの眺め 〜Contextの扱い方と活用方法〜 from Mikito Yoshiya

www.slideshare.net

インタフェース完全に理解した

とりすーぷ(@toRisouP)さん

C#のInterfaceの話。設計の話のほか、拡張メソッド、明示的な実装を書けるといった話。

• Interfaceには必ず利用者がいる。利用者側のPackageに置く。利用者側でコントロールできる
• 拡張メソッドに実装を書くことができる。traitっぽく使える
• structにInterfaceをかぶせる（実装する）ことができる
  • IEquatable<T>を実装すると、Equals()の振る舞いを自分で書ける
• 明示的な実装。InterfaceName.MethodName()と書ける。すると、Interfaceにキャストしないと呼べない

niconare.nicovideo.jp

Zenject完全には理解できなかった〜実運用におけるアンチパターンとその回避策〜

のたぐす(@notargs)さん

実運用で問題となるアンチパターンの話。Zenject自体への依存を下げるMethod injectionや、処理負荷を考慮した適用範囲の話など。

• ZenAutoInjecter
• Method injection: フィールドでなく初期化メソッドに[Inject]を指定できる
• MonoBehaviorをInjectするとき、FromComponentInNewPrefab()でなくFactory経由で行なう
• 頻繁に使うものはプールする、そもそもDIしない
• pure C# classにのみ適用するほうがいい
• Zenjectはハイリスク、ハイリターン

docs.google.com

Zenjectの機能をご紹介　〜テストの巻〜

@nozomin770 さん

Zenjectを適用したプロジェクトのEdit mode testで使うZenjectUnitTestFixtureおよび、Play mode testで使うZenjectIntegrationTestFixtureの話。

※スライドupされたら貼ります

Zenjectはじめの一歩：ゲームデータをScriptableObjectでInject！

Unity仙人(@lucifuges)さん

クラス設計など行なう前提でなく、データをScriptableObjectで持ち、それをScriptableObjectInstallerで切り替える話。

docs.google.com

所感

実際のプロダクトにZenjectを導入した経験談なども語られ、とても勉強になりました。皆さん、ただ「便利だよ」でなくデメリットにも言及されており、とても地に足の着いた内容だと感じました。 また、ContextやInterface、テストなど、それぞれフォーカスされた箇所が異なるセッションで構成されていたのもよかった。

自分ではまだ、DIが生きるほどの規模のものを作っていないのですが、今回の知見を取り入れて良い設計を目指していきたい。

参考

みなさんご参加ありがとうございましたー。Zenjectは中々国内記事が少なくこうやって知見が溜まるのは大変ありがたいので、どんどん公開して集合知集めていきたいですね。
僕もUNIBOOK10にZenject書いたのでよかったらどうぞ(宣伝)https://t.co/VZNB1IMUBA
#Zenject完全に理解した

— いも@efb~相手は死ぬ~ (@adarapata) 2018年9月6日

Unityゲーム プログラミング・バイブル

*1:心理学者のアブラハム・ハロルド・マズロー。欲求5段階説の人

Drecom Tech Espresso #6 "おなかソフトのDontDestroyOnLoad" に行ってきました #おなかソフトのドンデス

ドリコムさんで開催された『Drecom Tech Espresso #6 "おなかソフトのDontDestroyOnLoad"』に行ってきたので雑なメモ。

drecom.connpass.com

伊藤周さん、@toru_inoueさん、女子大生のとりすーぷさん、西村拓也さんのパネルディスカッション形式で進行されました。写真撮ってなかったけどこんな感じで進行。

#おなかソフトのドンデス
ヤバい絵面 pic.twitter.com/ELfbVz1WrA

— izm (@izm) 2018年7月30日

とりすーぷさんは若干遅延のある系？女子大生でした。すばらしい。

https://t.co/h1OaEdp3iv

そういやボイチェンこれね
#おなかソフトのドンデス

— とりすーぷ (@toRisouP) 2018年7月30日

西村さんの新刊

ダービースタリオン マスターズで学ぶ ゲームUI/UX制作 実践ガイド Unity対応版

Singletonについて

• 捨てるコードとか、逃げ場があるところだと使うけど、テスト書きにくいのでまともなコードでは使わない（井上さん）
• SceneManagerとか、もともとUnityでstaticなものをラップしたSingletonは使う（とりすーぷさん）
  • 急ぐときは仕方ないときもある
• Sigletonなしで作ってみたら、めんどくさい（西村さん）
• シーンをまたいで引き継ぐとき、サウンド、オーディオには使う
• Zenjectの機能でSingletonなオブジェクトを持てるので、いわゆるSingletonMonoBehaviour的なものは使わない
  • [8/1 追記] 問題なのはSingletonなオブジェクトそのものではなくstatic変数による参照保持なので（テストが書けない原因）、Zenjectを使えばテストではモックに差し替えることも容易で問題ない、という話。とりすーぷさんから補足いただいて追記。
• MainThreadDispatcherみたいなものとか、よくあるパターン
• .NET 4.6ではLazy<T>が使える。C# in Depthに書いてあるパターン
• テストしなければよい（暴論）
• ステートを持たせなければよい、シーンをまたいで引き継がなければよい
• Singleton自体は悪くないが、他の人に色々追加されてしまう

Sceneを切り替えるか否か

• オブジェクトの引き継ぎ、管理コストを減らしたいので、1シーンで実装しよう、という本になってる（西村さん）
  • DontDestroyOnLoadしたオブジェクトの管理がたいへん
  • チーム開発だが、Sceneのヒエラルキーは触らないのでコンフリクトは発生しない
  • prefabで切り替ている
  • テストプレイのための工夫をしないと常に最初から実行になる
• MultiSceneを使っている。ViewのシーンとModelのシーンを分けて重ねる（とりすーぷさん）
• Zenject便利

MVP, MVC

• チームによる（井上さん）
• MとVが密結合になると壊れやすい。今はMVPに統一している（とりすーぷさん）
  • 個人開発であってもルールがあると迷いがなくなる
• コンシューマーから来たので馴染みがない考え方だったが、気づいたらMVPになってた（西村さん）
  • アウトゲームはPassive ViewのMVP
  • インゲームはSupervising Controller
• uGUIはMVP、インゲームはそうでなくイベントをReactiveXで扱っている（とりすーぷさん）

画面に写ってたのたぶんこれ

qiita.com

サウンド系

• Singletonで作って呼び出す形、もっといい方法はないか
• CRI ADX2 LE 個人開発で使える。UnityのAudioMixerは馴染まなかった（とりすーぷさん）
• 自作するならSingleton、どうせテストしない（井上さん）
• ボタンを押したときに必ず通る処理があるので、そこでデフォルトの音を鳴らすようにして漏れをなくしている（西村さん）
• 鳴らすサウンドの指定はenum。stringは事故が怖い

ネットワークライブラリ

• UNETの話はしたくない
• 選択肢は、Photon Cloud、モノビットエンジン
• PhotonRx作った（とりすーぷさん）
• もしくは自作する

niconare.nicovideo.jp

所感

かなりUnityを使い込んでいる方々による生々しい話が聞けて、とても有意義な勉強会でした。 すでに第2回開催の話も出ているようで、期待しています！

今日から始めるVTuberワークショップ#01 でTAをしてきた話 #vtuberjustdoit

7/21に開催された『アナタもなろう！ 今日から始めるVTuberワークショップ #01（PANORA×デジタルハリウッド大学大学院）』にて、Unity班のTAをしてきた所感など。

vtuberjustdoit.peatix.com

VTuber(Virtual YouTuber)については、つい昨日も『Vカツ』や『バーチャルキャスト』、『カスタムキャスト』といったサービスについての発表があったりと、はじめるためのハードルが日々取り払われているような状況ですが、このイベントは

• Blenderでの3Dモデル作成
• Unity + HTC VIVEでのモデルの動かしかた
• Perception Neuronによるモーションキャプチャ

という、3つの「つくる」側にフォーカスした*1ワークショップで構成されていました。

私がお手伝いしたのは、Unity上に3Dモデルを置き、HTC VIVEで頭部と両手をトラッキング＋IKでモデルの姿勢制御をする、という、『バーチャルキャスト』の原型のようなものを作れる（少なくとも仕組みがわかる）ものでした。 演者として「なる」のが目的であれば素直にバーチャルキャストを使えばよくて、「似たようなものを作りたい」「仕組みを知りたい」という人向けのもの。

数名づつのグループに別れ、講師のようてんさん作の"YVTuber"をまず体験、続いて操作する3Dモデルを差し替える演習を行いました。

github.com

※演習を終えた状態が、ブランチvrm-aliciaにあります（たぶん）

ワークショップの課題（のレベル等）設定については下記ようてんさんのエントリにも書かれていますが、準備時間の不足、受講者ターゲット設定の曖昧さなどあり、期待していたものと違った、という方が多々いらしたのではないかと思います。

VTuberワークショップで アバターシステムUnity講座らしきものをしてきました #vtuberjustdoit - ReDo

進行も、基調講演後にPCとVIVEのセットアップとなり*2受講者の方々をお待たせしてしまった上、演習のほうも資料の不備と私の予習不足が重なってしまい初回に時間がかかって二回転しかできず、申し訳ない限りです。

ただ、初回が終わったあとは課題に限らない（雑談に近い）質疑応答を受講者の方々とする余裕がありました。3Dモデラーの方、実写系VRを制作している方など、普段自分の周りにいない職種の方々と、VTuberというものを接点にお話する機会を得られたのはよかったです。

補足

ワークショップでは無償で利用できるXR Mecanim IK Plusベースでしたが、有償のものもUnity Asset Storeにあります。またIKに限らずより便利に、よりリッチな表現をするためのアセットもあります。

気になるアセットを試してみたい（試してから購入したい）という方のために、『Unityアセットお試し会@Future Tech Hub with Unity』が度々開催されています。次回開催は未定ですが、下記ページに案内が出るはずです。

peatix.com

また、7月中に$30以上のアセットを購入すると、Bio IKがもらえるキャンペーンが開催されています。

https://assetstore.unity.com/g/july-promo-activation-jp

*1:これを書いていて気づいたのですが、『なろう』というタイトルから来る演者向けな印象と、ワークショップの内容がアンマッチなのが色々な迷いや不幸を生んでしまった元凶のような…

*2:贅沢を言えばPC+VIVEのセットがたくさんあればとかキリがないのですが

Unityアプリを受託開発するときのライセンスとディレクトリ構成について

Unite Tokyo 2018のユニティ・テクノロジーズ・ジャパンさんブースで聞いたことのメモ。勘違いしていたので聞いてよかった。

受託開発の場合、受託開発する側は当然Unityライセンス必要として、顧客が納品されたアプリをApp Store等でリリースするケースで、顧客に何を買ってもらえばいいかの話。

Unityライセンス

原則は

「Unityライセンス（サブスクリプション）は、エディタを開いたりビルドしたりするのに必要」

とのことなので、

• 受託側がビルドしたアプリを受け取って公開するだけなら、顧客（パブリッシャー）はUnityライセンス購入は不要
• 受託側からソース（Unityプロジェクト一式）を受け取るとしても、Unityエディタで開いて検収・ビルドしないのであれば、Unityライセンス購入は不要
• ソースをUnityエディタで開いて検収・ビルドする場合でも、エディタを使う期間だけサブスクリプションしていればよく*1、サブスクリプションが切れてからもApp Storeに公開し続けて構わない

Asset Storeで購入したアセット

• 納品物にソースとして購入したアセットを含めるのは再配布として扱う。再配布の扱いは各アセットのライセンスによる
• 購入したアセットは除外して納品したとして、納品後、顧客側で個々のアセットを購入するタイミングでアセットがバージョンアップされている場合がある。Asset Storeから過去のバージョンのものはダウンロードできない点には注意

ディレクトリ構成の例

Asset Storeで購入したアセットを隔離する必要は感じていたので、以下のようにしています、という設定例です。以降はUnityさん推奨というわけではないのでご注意ください。また、後述しますが完全なものではないので、いいアイデアがあればぜひ教えてください！

Unityプロジェクトのディレクトリ構成

まず、プロジェクトのAssetsディレクトリ下に自社開発分を隔離するディレクトリを切ります（以下MY_PROJECT）。この下に、Editor, Prefabs, Scenes, Scripts, Tests*2など必要に応じて配置していきます。

Asset Storeや.unitypackageファイルをインポートしたものは、Assets/直下に配置ます。ディレクトリ名で別れてくれるものが大半ですが、EditorやPluginsの下に置かれるものもあるのでまとめて除外するためです。

.gitignore

.gitignoreファイルのベースを取得します。

$ curl -o .gitignore https://raw.githubusercontent.com/github/gitignore/master/Unity.gitignore

これに以下を追加します。

# PlayMode testing cache（たぶん）を除外
Assets/InitTestScene*.unity*

# 公開 or 納品するものであれば、自身のプロジェクト以外のAssetsを除外
/Assets/*
!/Assets/MY_PROJECT*

MY_PROJECTの後ろに/をつけてしまうと.metaファイルが漏れるので注意。

またもし、Assets/Editor/下やAssets/Plugins/下に置いているファイルがあれば、個別に除外指定（!ではじまる行）を追加してください。

課題

この方式では、以下の課題が未解決です。

• リモートリポジトリをcloneしてそのままビルドできない。これはCI(continuous integration)を使用するときに致命的です。
• Asset Storeからインポートしたアセットに独自の修正を加える場合。MY_PROJECT下に複製して修正するなどできますが、ライセンスを考えると問題ですし、差分に気づかない恐れもあります。
• Assetの設定を自身のフォルダ下に格納するタイプの場合。EasySave2とか、Cross-platform Native Pluginsとか。これも差分に気づきにくいのがつらい。

このうちCIについては、開発機にあるフルセットのプロジェクトをUnity Collaborateに上げて、Unity Cloud Buildでビルドする方式を取っています。一人でやっているので大丈夫なのですが、チーム開発だと厳しい運用だと思います。

*1:とは言え最短1年ですが

*2:EditMode Testsだとprivateメソッドを直接呼べなくてストレスなのでPlayMode Testsを使っています