読者です 読者をやめる 読者になる 読者になる

peroon's diary

game programmer

iPhoneの画面を撮影してPremiereに持っていくと音ズレが発生したので対応方法

ハースストーンの新パックであるウンゴロを40パック開封し、それをiPhoneとつないだMacQuickTimeで録画した。録画中は動画サイズを確認することができ、12分で1.74GBだった。録画して保存したmovファイルをPremireに持っていくと、音ズレが発生していて、調べてみるとこれはよく知られていることのようだ。

Premiereのタイムラインで映像とオーディオが紐付いているので、選択して右クリックし「Unlink」でリンクを解除し、動画の始まりの方で音と映像を合わせる。動画の最後の方に行き、そちらもずれているので、映像の速度を101%にしたら、映像と音が一致した。最後に位置合わせにより音の方がタイムライン上ではみ出すので切り捨てて完了。できたのが以下の動画で、音と映像が揃っている。

GoProジンバルをラジコンに取り付けるためにDIYしてきた

f:id:peroon:20170412173347j:plain

トラック型のラジコンにGoProジンバルを取り付けたい。最初は木と釘を買って土台を作るつもりだったが、ホームセンターに行ってみたらちょうどいいサイズの木がなかったし、固い発泡スチロールにしようと思い始めていたところ、ゴムの板を発見。以前、木をのこぎりで切ったとき思った以上に大変だったので、今回ゴムならば刃物でスッと切れるんじゃないかと思い、ゴムの板を使ってみた。黒くてかっこいいし。組み立てるために接着剤も使う予定だったが、釘だけで十分だろうと金の釘を買った。板が350円、釘が110円くらい。買ったものはストア内のDIYコーナーで道具を借りて工作できる。

最初ゴムの板をのこぎりで切ろうとしたけれど、摩擦が大きすぎて引けなかった。カッターで切ろうとして、同じく摩擦が大きかった。そこで思いついたのが、切れ目を開きながらカッターで切っていく方法。傷口を開きながら切っていく感じ。こうすると摩擦はなく、刃を通すたびに切れ目が大きくなっていく。これで切った後、カッターや、やすりで成型すれば、欲しいサイズの板が手に入る。あとは釘で固定して完成。ピッタリに作れたので、後で動かすときにガタガタになって分解することがなさそうで良い。工作の様子は撮影して動画にしてみた。今回の工夫点は、字幕を多く入れて、同時に効果音も入れた。いつも通りPremiereでやったが、この作業はタイムラインにドロップするだけなのでかなり楽だが効果は大きい。ほとんどの箇所を10倍速にした。作業中、店員に間違われた。次はラジコントラックの運転である。

顔の映る実況プレイ動画が作れることを確認した

道具はMac, iPhone, デジカメ, Premiere, QuickTime.

f:id:peroon:20170412002915p:plain

撮影には、iPhoneMacにつなぎ、QuickTimeを起動し、File > New Movie Recordingで動画撮影モードにし、赤くて丸い録画ボタンの右を押して、QuickTimeへの入力をPCからiPhoneに画面とマイクの両方を変更する。録画を開始するとiPhoneの画面と音が撮影できる状態。音がQuickTimeに取られてスマホからは聞こえなくなるので、PCにイヤフォンを挿せば聞くことができる。録画ボタンを押すのと近い時間に、デジカメ側で顔を写して録画開始する。

f:id:peroon:20170412002930p:plain

録画が終了したら、2つの動画をPremiereで重ねる。プロジェクトに読み込んだら、背景となる側を先にタイムラインにDrag & Dropし、次に乗っかる側もDrag & Dropする。タイムライン上で音ずれを合わせたら、次は画面の位置を調整する。Window > Workspace > Effectを選んでエフェクト編集画面にしたら、位置を変更したい動画をタイムライン上で選択した後、Video Effects > Motion > Position, Scaleで変更する。あとは出力して完了。

編集はこれでできることを確認した。それ以前に必要なのは、ゲームの知識、そのゲームを楽しんでいるか、思ったことを言葉で出力できるか、笑顔を絶やさないか、などだろうけど、それはまた、別の話。

Unityでよくある10の間違いを避ける方法

https://www.toptal.com/unity-unity3d/top-unity-development-mistakes

こちらを咀嚼した上で自分の体験から書く。

#1 現実を見ようということ。どこよりも綺麗なグラフィックとFPSスマホを超える体験を作ろうとしても、それでは最新のハイエンド端末でしか動かない。Unityで作るとiOSよりAndroidの方がfpsが出ないことが多いので、最新のiPhoneでしか動作確認していないと、モデルを量産した後にどうしようもなくなる。正しい進め方は、リリース日が決まり、その時の最低動作端末が決まり、その最低動作端末で最低限満たしたいfpsが出るようにモデルを作ること。それではテンションが上がらないというのは別の問題としてある。

#2 モデルをImportして使うときにScale = (1, 1, 1)でそのまま使えるように、モデリングソフトとImport時のscale factorで調整する。シーンに置いたモデルのスケールをいじらない。モデルのマテリアルはできるだけ少なく。

#3 Unityはコードに参照を持たせてInspectorで紐づければ簡単に参照できるが、絡み合う構造になりやすいとも言える。どこから状態が変更されたか分からなくなることを防ぐために、状態を変更する役割を誰が持つのか分離する。

#4 基本だが、UpdateでFindしないでStartでキャッシュすること。エフェクトなど何度もInstantiateするものはPoolを使うこと。レンダリングを軽くするためにOcclusion Culling, LODを使い、動的ライトを減らしてベイクすること。Draw Callを減らすためにStatic Batching, Mesh.CombineMeshesでメッシュを合体させるが、このとき合体しすぎてCullingが効かなくならないよう注意する。個別のオブジェクトのマテリアルを共有するためにモデルのTextureをAtlasで共有する。透明テクスチャは避ける。使いたいならalpha blended shaderを使い、alpha test shader, cutout shaderは使わない。シェーダについて、変数の精度を下げたり、複雑な計算はLookup Textureにして負荷を減らす。全体的には、Profiler, Frame Debuggerを使ってボトルネックを見る。Frame Debuggerを使えばマテリアルを分割しすぎて何度もドローしていることなどが発見できる。

#5 Frame RateのスパイクとなってしまうGCを避けること。各フレームで新たなメモリアロケーションをするのは避けるべきであり、コードの書き方で大抵は避けられる。ProfilerでもGC Allocの列で毎フレームAllocateしてしまっているかは確認できる。

#6 100MBを超えるとCellularではダウンロードできなくなりお客を逃してしまうので超えないように収めて、他のリソースはAssetBundleに逃がす。とはいえ、最近は超えちゃってもしかたないと割り切っているアプリ多く見られ、例えばUnityで作られたハースストーンのサイズは2GBである。無駄なリソースが入ってないかは、ビルド後のEditor Logで確認できる。リソースサイズを食うのは主にテクスチャで、圧縮すべきでありTrue Colorはオススメできない。透過のエッジをきれいに見せたい時は、色情報と透過情報を別テクスチャにして色情報の方は圧縮してシェーダで合成し、True Colorよりも軽くする。そのシェーダは有志が公開しているが、UI用のシェーダとしてUnity公式でも出してほしい。

#7 物理エンジンのためにRigidbodyを付けたObjectの動きをコードから操作するときは、Rigidbody.positionやLateUpdate()で状態変化させること。物理エンジンの更新頻度はFixed Timestep setting in Time managerで変更できる。Mesh Colliderは重いので避けたい。物理が重いときはCPU側のボトルネックとなる。

#8 手で動かしてテストすることは徐々に退屈な作業となるし、時間もかかるのでUnit Testで十分な物はそちらでテストする。Play Modeで確認するときの状態設定はボタン1つでできるように自動化しておく。

#9 アセットストアのアセットは万能ではない。プロジェクトと一貫性を持っていることを確認して入れるべきだし、むやみに入れると不要なコードが増えて、コード変更後の再コンパイルに時間がかかるようになる。実装が簡単なら実装した方がコントロールできる。とはいえ例えばTweenなど、実装が簡単でも、アセットとして実績があって最適化もされているコードがあるなら、私はそちらを使った方がいいと思う。

#10 エディタ拡張で開発しやすくする。エディタ拡張は独自の世界があるのでみんなが学ぶべきかという話はあるが、今までツールプログラマだった人が、Unity内でデータを作れるツール作成のためにエディタ拡張を利用するといいと思う。

Google Code Jam Qualification Roundに参加してみた

f:id:peroon:20170409121111p:plain

今回のコンテストのURL https://code.google.com/codejam/contest/3264486/dashboard#s=p0

50/100点だった。A, Bは解けて、C問題はデータサイズが大きいものでTime Limit Error. これは解法が思いつきそうな気がするが、入力データを落としてから8分以内に正解できなかったので閉じられてしまった。問題によっては挑戦回数が1回のものがあるので、そのときは計算量のOrderをクリアしていて、自分で作ったテストケースも通る、自信のある解法ができてから提出するといい。

25000人くらいが参加して、7687位。25点取ればこのラウンドは通るようで、難しいD問題は解かないで去った人も多いようだ。私はDをそもそも解けなかった。1000位以内に入るには65点取る必要があって、Cの最後の問題を解ければそこには行けた。50点だとは5500〜9000位になる。100点だと450位くらいになれるし、早い時間から参加していれば二桁の順位も可能。まずはC問題を最後までしっかり解けることを目指したい。いろんな国から参加しているが、上位を見てみると、アメリカ、中国、韓国が多く、納得感がある。

提出方法については、入力ファイルが与えられて出力ファイルを提出する形式で、コードを送って向こうで実行する形式ではなく、提出データの形式チェックと、正解チェックのみ行っている。手元で実行できるので、様々な入力で通ることを確認してから提出することができ、「なんで通らないんだろう?どんな入力で落ちてるんだろう?」と予測する必要がないのが良い。逆に言えば、サーバ側でコードを実行して、テスト時の入力と出力は公開されていないコンテストは、自分で様々な入出力のケースを考えられるようにしましょうということだろう。それができるようになれば、今回のGCJで感じた、手元でしっかりテストされた自信のある提出がどこでもできるようになるだろう。

1週間後に Online Round 1: Sub-Round A があるので参加する。Onlineで6回の選抜があり、Onsiteで最後の決勝が行われるようだ。今回の復習や、過去問のチェックをしておきたい。

AtCoder Beginner Contestに参加してみた

f:id:peroon:20170408224107p:plain

D問題はこちら http://abc058.contest.atcoder.jp/tasks/arc071_b

Dまで解けて安心。なんらかの提出をしたのが464人、問題Dを解けたのが33名、私は28位。D問題で「累積和か?」「DPか?」とか思っていたけれど、そんなことを考える必要はなく、X軸、Y軸それぞれの長さの和をO(10の8乗)くらいに抑えるために、計算結果の再利用をすれば済んだ。「再利用できるじゃん」というのは図を書いてみて分かったが、基準をどこにするかで図も変わってくるので、いい基準を見つけられれば再利用を利用できて解ける。D問題のメモである下記の画像で言えば、青の面積の和は、緑の面積に少し足したものであると分かる。

f:id:peroon:20170408224836j:plain

D問題に時間を使いすぎてしまったけど全部解けたので、Regular Contestにも参加しようとしたけれど、開始前に参加ボタンを押しておく必要があるようだ。参加者に応じてサーバを増やしたりするのだろう。Beginner Contestとはいえ、解いて得点が入り、レートが付く。次は、Beginner Contestがあるときはそちらでレートを上げ、Regular ContestしかないときはRegularに参加してみよう。BeginnerとRegularは問題が重なる部分があるようなので、Beginnerが全部解けたらRegularに参加してみよう。

f:id:peroon:20170408225228p:plain

鶏そぼろ自作の動画を作ったら編集が大変だった

  • 背景をととのえる
  • 材料を出しておく
  • レシピの分量をノートに書く
  • 動画で撮影する。言葉に詰まってもカットすればいい
  • 料理自体が40分くらい。その間、ゴリラポッドに取り付けたRX100M1で動画撮影。

f:id:peroon:20170408163005j:plain

  • Premiereで編集。空白と言い間違いはカット。肉を切ったりするところは5倍速にしてテンポをよくする
  • 最終的に4分になり、編集時間は2時間かかった。4分というのは、メタップスの調査によると理想の長さらしい http://www.metaps.com/press/ja/blog-jp/299-100-youtuber
  • 10分以上になると広告を2つ以上挿入できる利点とかあるけど、そういうのは良い動画を作れるようになってから

f:id:peroon:20170408163527j:plain

  • 動画のサムネイルをカスタムサムネイルに設定。カスタムサムネイル用動画は、動画サムネイルをクリックして画像保存すれば分かるが、上下に黒枠が付いている。付加する文字は黒枠に入らないようにすること。480x360の縦横比で2MB以内
  • ヒカキンが2016年をふり返る動画によると、ずっと動画編集していて休みの日はなかったそう。編集って大変
  • ここ一ヶ月のYoutube収益は$3でした