2014年12月28日日曜日

Kindle Fire HD8.9のサブディスプレイ化

アマゾンアプリストアにiDisplayがあったので、これを使ってPCのサブディスプレイ化を試してみたメモ。

■概要

iDisplay はAndroid機をPCのサブディスプレイにするアプリ。

基本はWifi接続経由でPCと接続するものだがUSBケーブル経由でも使えるらしい。
今回はUSBケーブル経由で接続。

他にもこの種のAndroidアプリはいくつかあるようだがアマゾンアプリストアではiDisplayしか見つからなかったので。


ホストPC: Windows7x64
(CPU i3-2130 3.4GHz(Sandy Bridge) / RAM 16GB)

ターゲット: Kindle Fire HD8.9




■iDisplayを購入&インストール

iDisplay は有料アプリ。

KindleなのでGooglePlayには接続できない為、アマゾンアプリストアで購入。
価格は392円(為替変動する可能性有)。

以前キャンペーンでもらったアマゾンコインが余っていたのでこれで購入(392コイン)&インストール。



■Kindle側の準備


Kindleはデバッグモードに変更しておく。
(→ 参考記事: Kindle Fire HD8.9 デバッグモードにする

KindleとPCはUSBケーブルで接続しておく。
USBは2.0で接続。



■PC側の準備


PC用のディスレイドライバをダウンロードしてインストール。
  iDisplayのサイト: http://getidisplay.com
  (2014/12時点: v2.4.2.16: iDisplay_setup.exe)。

インストール後再起動要。

※今回はUSB接続「のみ」を試したのでウィンドウズファイアウォールの許可ダイアログは何も許可せずともつながりました。



■Kindle側でiDisplay起動

起動すると画面中央に「USB経由で接続」ボタンがあるので、それをタップ。
PC側で接続の許可ダイアログが出るので、AllowでKindleがサブモニタとして認識される。


認識後、PCの常駐アイコンにあるiDisplayを右クリックして、

Settings > Display Arrangement

で、サブディスプレイの配置を変更できる。
(一般的な外部ディスプレイはコントロールパネルから行うがiDisplayはここで設定する)


■使ってみる

正直重いです。

Kindleの画面上ではマウスカーソルがカクカク動く感じ。

Kindle Fire HD8.9が1920x1200という高解像度なせいもありそうですが。

使えないことはないのですが・・・ちょっとサクサクというわけにはいかないようです。

昔ThinkPadのS20をMaxiVistaでサブモニタにした際は結構サクサクだったので少々ガッカリ。


静止画や資料を見る程度の用途ならつかえないことはないかも?
動画は一応再生できましたが、コマ飛びは多い感じに。


■接続でErrorがでる場合

Kindle画面でErrorがでる時はまず以下を再確認。
  • KindleはPCのからエクスプローラで見えている。 
  • Kindleはデバッグモードになっている。
  • PCから adb 接続もできている。
にもかかわらずPCとつながらない場合がある。



その際の対策(?)として以下をやってみた。

  1. USBケーブル抜き差し直し。
  2. KindleのiDisplayアプリの起動し直し。
  3. PCのiDisplayアプリをタスクバーから終了、スタートメニュー/デスクトップアイコン等から再度起動。

だいたい「3」のPC側アプリを再起動させて、KindleからiDisplayで「USB経由で接続」するとうまくいく様子。

ちなみにPCのデスクトップがAeroだと、接続時強制的にオフになるようだ。
接続が切れるとAeroに戻る。



Kindle Fire HD8.9 デバッグモードにする

Kindle Fire HD8.9 デバッグモードにする手順メモ。


■Kindle Fire HD8.9上での操作手順

Kindleの画面で上から下へスワイプ。その他をタップ。




セキュリティをクリック。
「ADBを有効にする」のオンをタップ。



 ダイアログ内容を確認した上で同意できれば「OK」をタップ。


 オンに変わっていればデバッグモードに切り替え完了。


■PCとの接続確認

テスト環境: Windows7x64。

  1. PCとKindleをUSBケーブルで接続。
     
  2. PC上でコマンドプロンプトを開き、以下のコマンドを入力。
    adb devices
    ※注Android SDK要。パスが通ってない場合はディレクトリを移動してから実行する。
      Android SDKイントール先/sdk/tools あたりにある。
      
  3. 次のようなログが出ればUSB接続状態OK。XXXXXはKindleの固有デバイスID。
    List of devices attached
    XXXXXXXXXXXXXXXX         device。
     
  4. もしも以下のような場合はKindle側のデバッグモードやUSBケーブルを再度確認する。








2014年12月27日土曜日

Google+のタイムラインの画像で!マークが出る

何気なくGoogle+のタイムラインを見ていたら一部の記事の画像が表示されていない。
なぜ~?

■状況確認

Google+のタイムラインに画像が表示されなくなった記事があることに気づく。

もうすこし正確に言いますと
  1. Bloggerに記事を書いて投稿。記事には画像も含む
  2. 投稿時に共有する
  3. Google+のタイムラインにもその記事のダイジェストと画像などが一緒に載る
このタイムライン表示の画像が「!」マークになって消えているということです。

投稿後しばらくは確実に表示されていたのは覚えています。
その後に「!」に変化したのは間違いありません。



■状況調査

なんでだろうと?ちょっと考えてみました。
タイムラインで画像が表示されなくなった記事は2つ。

この2つの記事の大きな共通点は佐藤秀峰氏の漫画 on webの「ブラックジャックによろしく」の画像コンテンツを利用させていただいてる点。
そして「!」で表示されていない画像はその画像コンテンツをGoogle+が表示しているものです。

他の記事ではきちんと画像表示しているし、この2つの記事だけというのは偶然ではない?。

念の為書いておきますが、当方は利用規約をきちんと読み規約通りの手続きを取っております。
二次利用コンテンツ画像にも規約通りの記載(タイトル、著作者名、サイト名)をしています。

2つのブログ記事は現在でも閲覧できますし、勿論含まれる二次利用コンテンツ画像もちゃんと表示されます(Googleからの警告なども過去きていませんし勿論コンテンツ所有元からも)。


つまりGoogle+の「タイムライン上の画像だけ」が何かオカシイ感じ?です。


■推察


うーん?としばらく思案しつつ1つ思い浮かびました。

タイムライン上の記事のダイジェストでは、記事中の画像は自動的にやや縮小されたものがタイムラインに表示されます。

勝手な推測でしかありませんが、この縮小がまずいのか・・・?と。


縮小するとコンテンツ画像下部に明記しているタイトル、著作者名、サイト名の視認がしにくい/できない可能性があることに気づきました。

そうなるとタイムライン上においてはコンテンツ利用者なのか、著作者なのかの区別を明確にする「タイトル、著作者名、サイト名」の表記がわからりずらい/わからないかもしれない。

万一そうなると規約違反になる恐れが・・・?。


Google+側で勝手に縮小してるとはいえ、Google+使用者はその辺にも気を配るべき・・・と考えるべきなのでしょうこれは。



さらに推測の域ですが、
  • Bloggerの記事自体はきちんと規約を守っているので存続している。
  • しかしGoogle+のタイムライン上の縮小画像はまずい。
  • 縮小画像はGoogle+側のシステムによるもので、記事作成者に悪意は無い、と判断された可能性。
  • よって、タイムライン上の画像のみが非表示になるように処理された。
 と、考えるとなんとなく納得できそうな気が?。


■対応策?(私的勝手推論)

タイムライン上においても視認可能なように「タイトル、著作者名、サイト名」をもっと大きく明記してはどうか?と一瞬思いました。
しかしさらに考えるとこれもあまり良策ではなさそう。


Google検索等においても画像は表示される可能性はありますし他のBingなどの検索エンジンでも同様です。
その際「タイトル、著作者名、サイト名」の視認性まで保証できますか?です。

ムズカシそうです・・・。

パブリックな公開をしている以上、どこでどういう風に表示されるかなんてわかりません・・・。
(しつこいですが、あくまで全て私的な推察、推論の域です)。

これはつまり動的に閲覧が可能なネットコンテンツにおいて、その見え方を把握、コントロールするのは非常に困難である・・・かもと。

場合によってはシステム側で自動トリミングされ、どこかに表示された際に二次利用表記部分が切り捨てられる可能性さえもあります。

このような媒体において(規約とその解釈によりますが)二次利用の難しさというのが垣間見える気がします。

ブラよろはこの辺きっちりチェックしているのかもしれませんね。



追記: 「ブラックジャックによろしく」のコンテンツ利用はちょっと気になることもあるので結局利用を辞めました(Picasa上からも全削除)。

追記2:ユニティちゃんコンテンツを利用した開発に関する記事にて、制作中のスクリーンショットをのせているので念の為こちらについても固定ページ「このブログについて」にてライセンス明記するようにしました。


2014年12月26日金曜日

Candy Rock Star をさわってみた#06 ~ バックスクリーン

Candy Rock Star を題材にユニティちゃんディレクター杯に参加しました。
開催終了後、作品制作過程での諸々をメモ。


■開発環境/ツール

Windows7x64
Unity 4.6.0f3
PC: CPU i3-2130 3.4GHz(Sandy Bridge) / RAM 16GB / HDD 5TB / SSD 128GB



■バックスクリーン

いわゆるライブ演出のバックスクリーンです。

バックスクリーン用のカメラがユニティちゃんの頭を追尾しており、その映像を映しています。
(Back Screen Camera Rig(Clone) の孫オブジェクトにカメラ Back Screen Camera があります)。


その際「それっぽい雰囲気」が出るようにフリッカーの効果が演出されています。

フリッカー: 一応補足しておくと、現実世界にてTVやプロジェクタをビデオ撮影するとちらついて見える現象が発生します。これをフリッカーと呼んでいます。(参考: Wiki フリッカー
ひとことでいうと「チラツキ」です。相互の垂直同期周波数の差異により発生します。



どうもこのフリッカー効果はシェーダーで実現しているようで、「Back Screen(Clone)」オブジェクトに付いているコンポーネントの「Back Screen」シェーダーで処理しているようです。
これは面白いですね、こんなこともできるのだな~と。



再生中にこの「Back Screen(Clone)」オブジェクトを選択するとシェーダーのパラメータ設定などが見えます。

今回の投稿作品ではこのパラメータを少しいじっています。


パラメータ 意味? 元値 新値
Base Level ベースの明るさ 0.4 0.1
Sprite Level ストライブの明るさ 5 5
Flicker Level チラツキ周波数デューティぽい 0.6 0.6
Flicker Freq チラツキ周波数 40 0



注目する点は「Flicker Freq」でのチラツキの周波数です。

多分元の値40は垂直同期周波数40Hzの意味と推察します。
オリジナルのCRSでは再生時概ね60fpsでていますので垂直同期周波数60Hzといえます。
それに対して40なのでこのズレ分がチラツキ加減を演出してることになります。


今回はこの「Flicker Freq」を0にしています。つまりチラツキ無しです。



■フリッカー演出を無しにした理由

今回ユニティちゃんは3体出しています。
この為バックスクリーンの前を遮りやすくなりました。
するとこのバックスクリーンのフリッカーが思いのほか目に付くように。

主役はユニティちゃんたちなので。フリッカーが妙に目立つのはよろしくないかなと。


他、最大理由としてうちのPCが非力だからです。


概ね fps60 出ているのですが、たまに60を割ることがあります。
(作品実装が進むにつれて徐々に落ちやすくなる傾向へ)
Flicker Freq は多分60fpsを前提に40に調整されているのでしょう。
ちょっと見え方もかわります。フリッカーが妙に見えるのはこのせいも若干あります。


そして最終的にフリッカー無しとすることを決定づけた理由がさらにあります。 

  • このフリッカー効果は結構高負荷
    このフリッカー効果を切ると約 10fps 以上軽くなります。
    作り込み終盤において fpsを気にしている所にこれはまさに神の救い(ぁ
    視覚的にも負荷的にも一石二鳥。

  • 動画エンコードに有利
    この常時ちらついている画像はエンコードには不利です。
    映像の時間軸における変化差分が小さい程エンコードには有利になります。
    チラツキが多いとその分余分にビットレートを持っていかれるので画像品質に不利になる可能性。


常に気にかけていたことについて


実は制作中、私的に常に気にかけていた点があります。

Unityの良さのひとつは高速なリアルタイム・レンダリングだと思うのですね(あくまで私的には。

3DCGがぬるぬる(?)動くのがなんかこう・・・良いんですよ。
(CRSがリアルタイムで動いてるのは少なからずインパクトがあると思います)
このぬるぬる感というのは欲を言えば80~120fps程度欲しいです。しかしさすがにこれは欲張りすぎ。

エンコードも考えると60fps出せれば恩の字です(というか充分。

つまり、ニコニコ動画には60fpsでアップロードしたい・・・、と考えていました。
そうでなければ私的にUnityの良さ=ぬるぬるさが出せないなぁと。


つまりこれ、Unity上でCRSを60fpsで動かしつつ、録画も60fps維持するってことですね。

ハイ、うちのPC性能ではきつかったです(汗;

きつめでしたが・・・諸々のチューンの末ほぼ60fpsで録画してます。
※ユニティちゃんに目いっぱい寄るようなカメラワークは実はfps的に一番厳しいようです。が、演出を優先したいのでなんとかしのぎきり(ごまかし)ました。
録画、エンコードについてはまた別の機会に書こうと思います。



変な話、PCが低性能だったが故にフリッカーの負荷に気づいたので、エンコードの助けになったといえなくも・・・ない・・・かな;。

そんなこんなでオリジナルCRSのフリッカーは申し訳なくもオフ状態にて収録しています。


2014年12月23日火曜日

Candy Rock Star をさわってみた#05 ~ ユニティちゃんのアニメ連動移動制御

Candy Rock Star を題材にユニティちゃんディレクター杯に参加しました。
投稿後、作品制作過程での諸々をメモ。



投稿作品ではユニティちゃんは3体出していますが、個々に個別の移動制御をしています。
(投稿作品: 【画質向上版 】ユニティちゃん3人で踊ってもらった



■開発環境/ツール

Windows7x64
Unity 4.6.0f3


※Unity及び関連の機能を全て把握してるわけではない為、技術的な間違いを含む可能性もありますので注意です、念の為。



■ダンス・アニメーション

移動の話の前にまずアニメーションについて。

ダンスのアニメーションはCandy Rock Star のプロジェクトの中に3種存在しています。
(/Assets/UnityChan/Animations/C86unitychan_~)

オリジナルのプロジェクトをUnity上で再生し「CandyRockStar(Clone)」モデルを選択&Animatorウィンドウを見ると、
  • 001_SAK01_Final
  • 002_SIM01_Final
  • 003_NOT01_Final
の3つの遷移設定が見えます。
実際にはデフォルトの「002_SIM01_Final」が最初から最後まで再生されています。
オリジナルでは他の2つのダンスは再生していないようで、素材として用意されているのかなと思いました。


今回の投稿作品では他の2種のダンスも活用しています。

センターのユニティちゃんはデフォルトのダンスアニメーション「002_SIM01_Final」を使用。
他の2体のユニティちゃんには他2種のダンスアニメーションで踊るようにしています。
ですので3体とも終始異なるダンスを踊っています。
他の2つのダンスはメインのダンスと絡むように見える動きもあり、それらを生かす感じでディレクションを心がけました。 
(結構な時間この3種のダンスは並列再生してガン見してました(笑;)



■Root Motion

再生中の「CandyRockStar(Clone)」を選択してInspectorを見ると、Animator欄の「Apply Root Motion」にチェックが入っています。

このチェックが入っているとアニメーションによる前後左右の3D座標移動が有効になります。
もしこれを外すとダンスはその場でのみ踊るようになり位置移動をしなくなります。
つまりユニティちゃんが元気にステージを走りまわらなくなります。

このアニメーションの位置移動は外部ツールでアニメーションを作成する際に決定されているので、Unity上ではいじれません。
(と思いますが、何か手があったりするのかな・・・とかちょっと気になりますけど。




■ダンスフォーメーション

3体のユニティちゃんを横に並べて3種のダンスをそれぞれで再生。概ねいい感じに踊ってくれます。
しかしちょっと相互にニアミス気味な時があり微調整をしたい感じ。

時間的に迷うとこでしたがやはり調整を加えたい。ついでにちょっと野望もあるので(謎。
そこで位置移動を加えるにあたり2つの案が浮かびました。
  1. ダンスアニメーションを修正する。
    最も正攻法(?)。ダンスアニメーションを外部ツールで修正し再度Unityにもってくる。しかしこれはなんらかの方法でアニメーションをUnityからエクスポートしないと加工できない気がします。
    元は多分Mayaあたりで作られてるのでは?と思うので、その元データが無いと難しそう(どのみちMayaは無いけど!BVHならあるいは・・・
    ひょっとするとUnityのアニメーションをBlenderに持ち込む方法もあるかもしれませんが、締め切りまで時間もあまり無い状況でコンバート関係で時間を費やすのは得策ではないと判断。

  2. iTweenを使って駆動
    みんなダイスキiTween♪
    これでお手軽に駆動できるんじゃないかと思ったら少し甘かったです。
    しかし結局これで実装しました。



■iTweenで駆動

Root Motion が有効になっているので、アニメーション再生によりユニティちゃんは前後(Z)左右(X)上下(Y)に移動します。
つまりアニメーションで3軸が変動します。


普通にiTweenで駆動するとアニメーションによる軸移動とで相互に位置座標を上書きしようとする為、おかしい動きになります。

そこで「現在の座標」に対してオフセット(相対移動)で駆動すればそれっぽい動きになるだろうと考えました。

ここで問題点が。

iTween での相対移動指定の方法がわかりませんでした・・・。
何か方法があるのか、本当に機能上できないのか1~2時間程度ネットで調べても判明せず。

時間が勿体ないのでやむなくiTweenのコールバックを使い自前で相対移動を実装しました。
(参考: Unity - iTween メモ

当初この方法をすぐ採用せずiTweenの機能(&オブジェクトの本来(?)の基準座標位置を得る方法も)を探した理由は、単純に実装すると相対移動による累積誤差で徐々にずれていく可能性を危惧した為です。
誤差分を要所で減らす工夫もできそうですがゼロにはできないだろう、と。

しかしもはや時間も無いのでこれでいけるとこまで実装してみるしかない。累積誤差がでたら各イベント制御側の移動量指定分に補正量も埋め込んでいくしかないという考えで。

結果的にステージ上では全くわからないので、今回の用途では誤差分は心配する程のことではなかったようです。

※後にして思えば、アニメーション駆動の親オブジェクト内に子オブジェクトを入れて、子のローカル座標をiTweenで駆動すれば誤差無しで制御できるような気がしました。
ということは、CandyRockStar(Clone) はAnimator駆動のままで、その中の Character1_Reference のローカル座標をiTweenで駆動してやれば良かったのかも・・・。





■その他こもごも

そんなわけで3体のユニティちゃんはダンスアニメーションに対して、さらに3軸相対移動が可能な実装がされています。

と、いうことはユニティちゃんは上下方向にも動けるってことです。と、いうか動かしたかったので。
(ゲーム開発プラットフォームなUnityなわけですし、キャラクタ移動制御くらいできないでどうする・・・ですよね)


冒頭0:26付近でセンターのユニティちゃんが右手を振り上げて小ジャンプするシーンがありますが、ここで上方わずかに相対移動でジャンプ分をブーストしています(地面からより離れています)。
カメラアングルが足元を写してないのでわかりにくですが・・・;
(最終的に左のユニティちゃんとの被写界深度のカメラ焦点遷移を優先したアングルにしたので・・・;)



この小ジャンプをより演出する為に、0:23からのスピン後のバックステップでも後方に相対移動を追加。そこから前方へ戻る際も相対移動追加で勢いよくステージ手前へ移動、先の小ジャンプにつなぐようにしています。

0:32付近のバンザイしてるところが左右のユニティちゃんよりもセンターのユニティちゃんが高く飛ぶのでわかりやすいです。ここでも上方に相対移動させてます(その後すぐ下方に移動も)。



他、前後、斜め一列などのフォーメーションは元のアニメの動きに対して違和感ないような(バレないようなw)タイミングでこっそり相対移動させています。
(一応カメラで全景を写しても違和感ないように移動はつないでます。後でニコニ立体に視点変更可にして上げようかなと思っていたので。しかしバイナリサイズ制限があったとは・・・)

これらのタイミングをイベント化する作業が地味に大変でした。


個々の制御は自前の時間経過によるイベント発行部から、iTween駆動部へトリガーを与えて開始。
iTween駆動部には「指定時間内に指定の相対距離を移動」というパラメータを与えて制御を行っています。

非常に原始的な方法なので、ジャンプ上りと、ジャンプ下りは別イベントです。つまり数フレーム単位でイベント発生を人力で組んでいます。

つまり最終的なイベント発生タイミングの調整が大変な作りです;
※とにかくシステムとしてまずは稼働させないと締め切り時間が~なので。イベントタイミング作成は最悪物量=時間次第(1日は24時間!)なので気合で!な方針で(苦笑


ユニティちゃん3体のダンスフォーメーションはこれで駆動しているのでイベント発生タイミングと移動量、速度の調整は、やはり予想通りそれなりに時間を費やすこととなりました;

しかし最低限の移動の自由度は確保できたのでやはり実装おいて良かったと思います。
最終調整段階で動画の出来映えに(私的な満足度的には)関係する要素のひとつになっていたと思います。