Kindle Fire HD8.9で艦これ

Kindle Fire HD8.9で艦これを動かすメモ。

過去にも数度Kindle Fire HD8.9で動かしてますが、年末定点観測的に動作実験＆メモ。
（動作を推奨しているわけではありません。もしも行う際は自己責任で。ちなみに普段はPCのみでプレイしています）



使用したKindle機種は次の通り。

製品名： Kindle Fire HD8.9
搭載OS： Android 4.0.3
ネット回線： Wifi経由 光回線。

多分他のKindle Fireでも動きそうですが（Android4.3位以前）未確認なのでわかりません。

■前準備

Kindle側：

• 野良アプリインストール可にしておく。
  上下スワイプ > その他 > 端末 > アプリケーションのインストールを許可 を オンにする。
  
  
• デバッグモードにしておく。
  上下スワイプ > その他 > セキュリティ > ADBを有効にする を オンにする。

PC側：

• Android SDK をインストールしておく。
  
  
• PCとUSBケーブルで接続＆認識できるようにしておく。
  所謂ソフト開発＆デバッグ可能な状態。
  ※WindowsのデバイスマネージャでポータブルデバイスにKindleが認識しているだけでなく、 Android Composite ADB Interface もインストール＆認識している状態。

■Flashのインストール

【重要】
Android版 Flash Player は2013/9/10のリリースを最後に開発終了しています（Android 2.x/3.x/4.x）。

その後のセキュリティホールなどについては何が起こるかわかりません。自己責任にて使用することになります。

□ダウンロード＆インストール

今回対象のKindleはAndroid 4.0.3 なので、4.x系最終リリース版 11.1.115.81 を使います。

以下のAdobeのサイトからダウンロードします。
Flash Player Help / アーカイブ版 Flash Player の提供について

上記サイトを開き、中程にある、
「Android 4.0 用の Flash Player バージョン」
を、見つけます。

その下の、
Flash Player 11.1 for Android 4.0 (11.1.115.81)
これをダウンロード（install_flash_player_ics.apk）。

PCとKindle機をUSB接続し、DOSプロンプトから以下のコマンドでインストール。
adb install install_flash_player_ics.apk

既にブラウザインストール済み（Firefox等）の場合は一旦終了させる。
（終了＆再度起動しないとFlashプラグインが認識されない為）


※後でアンインストールする場合は以下のコマンドで。
adb uninstall com.adobe.flashplayer

■Firefox 34.01

□バイナリ入手

今回は別のAndroid機（ME-173X）にGooglePlayから一旦インストール、App Extractionというアプリでバイナリ化（/sdcard 以下に保存）。

このバイナリをUSB経由でＰＣに一旦保存。
（adb pull /sdcard/Firefox.34.0.1.apk Firefox.34.0.1.apk でPCに引っ張る）


その後USB経由でPCからKindleにインストールするという手順を踏んでます。
（手持ち機材ではこれが一番早くできたので）

他にもいろいろ手はあるかもしれません。

□バイナリインストール

PCとAndroid機をUSB接続し、DOSプロンプトから以下のコマンドでインストール。
adb install Firefox.34.0.1.apk

※後でアンインストールする場合は以下のコマンドで。
adb uninstall org.mozilla.firefox

□動作設定

 メニュー > ＰＣサイトモード
で、チェックを入れる。

艦これにログインすると「このゲームはＰＣ専用となっております。推奨環境をご確認ください。」と表示されてしまう。
※以前出来たのにこのFirefoxバージョンではダメな様子。

User Agent情報で弾かれている？と予想。よってこれの対策をしてみる。

メニュー > ツール > アドオン すべてのFirefoxアドオンを見る。
検索欄で user agent と入力。 Custom User-Agent String をインストール。

メニュー > ツール > アドオン > Custom User-Agent String

元のUser Agent情報：
Mozilla/5.0 (Android; Mobile; rv:22.0) Gecko/22.0 Firefox/22.0

以下に書き換える
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

艦これに再度ログイン。
Flash画面表示枠内に「ここをタップするとプラグインを実行します」とでるので、タップして進む。

艦これ起動！。

■Firefox Beta 35

□バイナリ入手

Firefox 34.01と同じ方法で行った。

□バイナリインストール

PCとAndroid機をUSB接続し、DOSプロンプトから以下のコマンドでインストール。
adb install Firefox.34.0.1.apk

※後でアンインストールする場合は以下のコマンドで。
adb uninstall org.mozilla.firefox_beta


メニュー > ＰＣサイトモード
で、チェックを入れる。

□動作設定

艦これにログインする。
Flash画面表示枠内に「ここをタップするとプラグインを実行します」とでるので、タップして進む。

艦これ起動。

ちなみにUser Agent情報は。
Mozilla/5.0 (Android; Mobile; rv:22.0) Gecko/22.0 Firefox/22.0
と、34.01と同じなのにこちらではなんなく起動する。

私的感想：

• PCよりは遅い（アタリマエ。
  
  
• 意外とそれなりに遊べる。
  
  
• 画面が大きいので操作しやすい。
  意外と操作感に結構影響してる。
  ピンチ操作で画面の拡大縮小も可能。
   
• 1920x1200なので画質はPC同等。
  追記：「艦これ」は実質ゲーム画面800x600程度なのでグラフィックの精細さが特に向上するわけではなく、拡大した分粗く見えるとも。文字はアウトラインみたいなので少しきれいかも？
   
• グラフィックの動きは若干モッサリと遅い。
  特に戦闘はグラフィックの遅さで時間がかかり気味。

艦これリリース直後頃に比べれば劇的に軽くなってる（艦これ側の改良で軽量化してる様子）。
現行Android機の性能向上もあいまって意外と実用域で動作する感じ。

■Chrome 39.0.2171.93

□バイナリ入手

Firefox 34.01 と同じ方法で行った。

□動作設定

PCサイトモードにしても、
 「このゲームを遊ぶには、Adobe Flash Playerが必要です」と表示され艦これできず。







とりあえず Firefox Beta35 が比較的手間も少なく動作する感じですね。
気のせいかブラウザそのものの動作もちょっと早い気がします。

Android機で艦これ

Android機で艦これを動かすメモ。

過去に何度かME-173Xなどで動かしてますが、年末定点観測的に動作実験＆メモ。
（動作を推奨しているわけではありません。もしも行う際は自己責任で。ちなみに普段はPCのみでプレイしています）


使用した機種は次の通り。

製品名： Asus ME-173X
搭載OS： Android 4.2.2
ネット回線： Wifi経由 光回線。

多分4.3位までは同様な手順で動作しそう。
それ以降は様相が変わってるとの情報もチラホラ。所持していない為未確認。

■前準備

詳細省略。ざっくり以下のような感じ。

Android側：

• 野良アプリインストール可にしておく
  
  
• デバッグモードにしておく
  所謂adbコマンドでDOSプロンプトから接続できる状態。

PC側：

• Android SDK をインストールしておく
  
  
• PCとUSBケーブルで接続＆認識できるようにしておく。
  所謂adbコマンドでDOSプロンプトから接続できる状態。
  ※WindowsのデバイスマネージャでポータブルデバイスにAndroid機が認識しているだけでなく、 Android Composite ADB Interface もインストール＆認識している状態。

■Flashのインストール

【重要】
Android版 Flash Player は2013/9/10のリリースを最後に開発終了しています（Android 2.x/3.x/4.x）。

その後のセキュリティホールなどについては何が起こるかわかりません。自己責任にて使用することになります。

□ダウンロード＆インストール

今回対象機種はAndroid 4.2.2なので、4.x系最終リリース版 11.1.115.81 を使います。

以下のAdobeのサイトからダウンロードします。
Flash Player Help / アーカイブ版 Flash Player の提供について

上記サイトを開き、中程にある、
「Android 4.0 用の Flash Player バージョン」
を、見つけます。

その下の、
Flash Player 11.1 for Android 4.0 (11.1.115.81)
これをダウンロードします（install_flash_player_ics.apk）。

PCとAndroid機をUSB接続し、DOSプロンプトから以下のコマンドでインストール。
adb install install_flash_player_ics.apk

もし既にブラウザ（Firefox等）が起動している場合は一旦終了させる。
（終了＆再度起動しないとFlashプラグインが認識されない為）

■Ｆｉｒｅｆｏｘ 34.01

GooglePlayでインストール＆起動。

メニュー > ＰＣサイトモード
に、チェックを入れる。

艦これにログインすると「このゲームはＰＣ専用となっております。推奨環境をご確認ください。」と表示される。
※以前はプレイできた気がしますがこのFirefoxバージョンではダメな様子。


User Agent情報で弾かれている？と予想。よってこれの対策をしてみる。

メニュー > ツール > アドオン すべてのFirefoxアドオンを見る。
検索欄で user agent と入力。 Custom User-Agent String をインストール。

メニュー > ツール > アドオン > Custom User-Agent String

元のUser Agent情報：
Mozilla/5.0 (Android; Mobile; rv:22.0) Gecko/22.0 Firefox/22.0

これを以下に書き換える
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0


艦これに再度ログイン。
Flash画面表示枠内に「ここをタップするとプラグインを実行します」とでるので、タップして進む。

艦これ起動！。

私的感想：

• 昔は激重かったが、だいぶ軽くなってる。
  一頃から艦これ自体が軽くなった気がする （数回Vupしてる気がします）。
  ME-173Xでも微もっさりながらも充分遊べるレベルになった感。
  
  
• グラフィックの動作はかなり軽くなったとはいえ微もっさりなのは否めない。
  
  
• タップ反応が微渋いのでしっかりタップする感じで操作。
  タップ時にズレるとスワイプ入力になりやすい点も注意。
  
  
• ピンチ操作で画面の拡大縮小可能。
  補給等タップ位置が小さい場合は、拡大してタップするとやりやすい。

■Ｆｉｒｅｆｏｘ Beta 35

多分一番手間がかからないブラウザ。

メニュー > ＰＣサイトモード
で、チェックを入れる。

艦これにログインする。
Flash画面表示枠内に「ここをタップするとプラグインを実行します」とでるので、タップして進む。

艦これ起動。

気持ちFirefox 34.01より軽い気がするようなしないような・・・？。

ちなみにUser Agent情報は。
Mozilla/5.0 (Android; Mobile; rv:22.0) Gecko/22.0 Firefox/22.0
と、34.01と同じなのにこちらではなんなく起動する。

■net（iLunascape version 2.2.0.0）

一応動作はする。
補給の選択タップが1度で2回タップされたような認識でおかしい。
ピンチもきかないので微妙。

■ドルフィンブラウザ

デフォルトだと「このゲームはPC専用となっております。推奨環境をご確認の上、ご利用下さい」と表示され艦これ画面までいかない。

画面左下のイルカマークをタップ。３つでるアイコンの右端をタップしてメニュー表示。
メニュー内の設定をタップ。
ユーザエージェントをタップし、デスクトップをタップ。

 「このゲームを遊ぶには、Adobe Flash Playerが必要です」と表示され艦これできず。

User Agent的には通ったようだが動作せず。

前はこれで動かしたような記憶があったのに何か変わったかな？

■Chrome 39.0.2171.93

 「このゲームを遊ぶには、Adobe Flash Playerが必要です」と表示され艦これできず。





Firefoxが比較的安定動作な感じ。
FirefoxのバージョンでUser Agent偽装の必要/不要がある様子。
現状手間を極力かけないなら Firefox Beta 35 が楽かも？

SDユニティちゃんをBlenderでImportしてみる

SDユニティちゃんが公開されましたね！きゃわいい！

早速Blenderでインポートを試してみたメモ。

■Blender2.72b以前

2014/12/29時点の公式リリース版Blender 2.72b（及び以前版）ではうまくFBXでImportできません。

顔だけになったりおかしいことに。

■Blender2.73 Test Build1以降

Blender 2.73 Test build1だと一応インポートできました。
ちょっとボーンのマーカーの向きがおかしい気もしますが。FBXのIｍpoter設定はこんな感じ。

FBX Importerの設定で「Automatic Bone Orientation」をオンにするとボーンらしくインポートできる。

どちらの設定でインポートしてもアニメーションの作成等には支障がなさそうなので、この際深く気にしなくてもいいかもしれない。
足のボーンマーカーの大きさも違ったりしますが気にしなければ多分OK！（アバウトさも肝要♪。

■Blender2.73 RC

追記：2015/1時点で2.73が正式リリースされているのでそちらを使う方が良いでしょう。
2014/12/29時点で2.73RC版がでています。
これでもインポートができることを確認。TestBuild1よりこちらのほうが良いかもしれない。

どちらにしても現行の正式リリース版ではまだインポートできないようです。
（RC版は一応正式リリース前版）。

とりあえずBlender上でアニメーション作成＆再生はできることを確認。
Blenderからアニメーション込みでFBXでExport。

Unityでインポート、アニメーションプレビューもできた。

とりあえずBlenderでアニメくらいは作れそうです。

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アプリをタスクバーから終了、スタートメニュー/デスクトップアイコン等から再度起動。

だいたい「３」の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ケーブルを再度確認する。

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

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

■状況確認

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

もうすこし正確に言いますと

1. Bloggerに記事を書いて投稿。記事には画像も含む
2. 投稿時に共有する
3. Google+のタイムラインにもその記事のダイジェストと画像などが一緒に載る

このタイムライン表示の画像が「！」マークになって消えているということです。

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

■状況調査

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

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

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

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

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


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

■推察

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

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

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


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

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

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


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



さらに推測の域ですが、

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

 と、考えるとなんとなく納得できそうな気が？。

■対応策？（私的勝手推論）

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


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

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

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

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

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

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

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



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

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

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」を０にしています。つまりチラツキ無しです。

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

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

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


他、最大理由としてうちの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のフリッカーは申し訳なくもオフ状態にて収録しています。

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

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



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

■開発環境/ツール

Windows7x64
Unity 4.6.0f3


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

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

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

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

オリジナルのプロジェクトをUnity上で再生し「CandyRockStar(Clone)」モデルを選択＆Animatorウィンドウを見ると、

• 001_SAK01_Final
• 002_SIM01_Final
• 003_NOT01_Final

の３つの遷移設定が見えます。
実際にはデフォルトの「002_SIM01_Final」が最初から最後まで再生されています。
オリジナルでは他の２つのダンスは再生していないようで、素材として用意されているのかなと思いました。


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

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

■Root Motion

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

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

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

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

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

時間的に迷うとこでしたがやはり調整を加えたい。ついでにちょっと野望もあるので（謎。
そこで位置移動を加えるにあたり２つの案が浮かびました。

1. ダンスアニメーションを修正する。
   最も正攻法(?)。ダンスアニメーションを外部ツールで修正し再度Unityにもってくる。しかしこれはなんらかの方法でアニメーションをUnityからエクスポートしないと加工できない気がします。
   元は多分Mayaあたりで作られてるのでは？と思うので、その元データが無いと難しそう（どのみちMayaは無いけど！BVHならあるいは・・・
   ひょっとするとUnityのアニメーションをBlenderに持ち込む方法もあるかもしれませんが、締め切りまで時間もあまり無い状況でコンバート関係で時間を費やすのは得策ではないと判断。
   
   
2. iTweenを使って駆動
   みんなダイスキiTween♪
   これでお手軽に駆動できるんじゃないかと思ったら少し甘かったです。
   しかし結局これで実装しました。

■iTweenで駆動

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


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

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

ここで問題点が。

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

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

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

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

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

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

■その他こもごも

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

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


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

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

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

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

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


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

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

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


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

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

Candy Rock Star をさわってみた#04 ～ レーザー

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



レーザー類をちょっとだけ滲ませて(?)目立つように改造してます。

■開発環境/ツール

Windows7x64
Unity 4.6.0f3

■Laserオブジェクト

レーザーの照射部分は１つのプレハブから生成しているようでいくつかの箇所から照射されています。ステージ上の複数のスピーカー Rings、ステージ外郭を周回する Orbit Outer/Inner など。
（生成後のレーザー部： Laser(Clone)）

大元のLaserに「何か」を施せば全てのレーザーに反映されそうと推察。

■目的の効果

レーザーの照射部分をもっと滲ませて(?)ビームの発光感を出したい。
できれば既存オブジェクトを生かしつつ。

Point Light を新設し、Laserオブジェクトに強力な光源を当ててトバして発光感を出そうと（安易。
Point Lightの追加は負荷が上がる可能性がありそうですが、結果的に思ったほどではなかったのでそのまま採用。
※シェーダーとかパーティクルを使うとか別な方法もありそうな気はします。

■作業

ステージ中心の床少し上に Point Light を新規に設置。

このままだとUnityちゃんや他のステージ機材にも影響してしまうのでレーザー用にレイヤ「Laser」を作成。
Point Light はレイヤ「Laser」に配置、Intensityは最大値に設定。

Assets にある Laser(Clone)  の生成元 、

Project > UnityChanStage > Effect > Laser > Laser

のレイヤ指定を「Laser」へ変更。これでレーザー部分の発光が増加。

他、動的にスピーカーの Rings もレイヤもStage  <-> Laserに移して発光増しの演出を制御。

■補足

あとから思いましたが、このレーザー類の滲みは動画エンコードには不利だったんじゃないか、と。
エンコード重視なら元のままの方が良かったかもしれません。

が、やってみたかったのでしょうがない(´∀｀)

SubStance Painterを買ってみた

STEAM で安かったので SubStance Painter を買ってみた。


日本円で 4949円。


昔STEAMでの支払いはUSDだったはず。
ここ1年位？の間に請求額面が登録国リージョンの通貨になった様子(?)。


以下、素人目線での雑感。

■試した動作環境

Windows7x64
Blender 2.72b x64
Unity 4.6.0f3
PC： CPU i3-2130 3.4GHz(Sandy Bridge) / RAM 16GB / HDD 5TB / SSD 128GB
GPU： Geforce 550Ti

■購入前検討

本家HP： allegorithmic ～ SUBSTANCE PAINTER


最初公式動画等を見た感じでは、ノーマルマップの作成に強そう？みたいな第一印象。

とりあえずトライアル版が無料利用できるので試してみました。

思うに購入前にはトライアル版での動作確認を強く推奨な気がします。

• グラボの機能を積極的に使ってるらしい
  GPUとの相性がでやすいかもと推察。
  
  
• グラボドライバをアップデートしろと警告がでる
  最新版ないしは、かなり最新寄りのドライバVerを具体的にコンソール画面で指定してきます。
  警告無視でも一応使えましたが。

2014/12/19時点でnVidiaドライバパッケージ344.48以降を導入するように警告がでたのでアップデート。
ちなみに最新は344.75ですがこの版は画面色調があからさまに変わってしまう問題が出たので344.48に戻しました。これはSubStanceだけでなくUnity他でも色変化するのでnVidiaのドライバの問題だと思います。

■SubStance Painter って何ができるの？

最初 SubStande Designer と Painter の違いがよくわからず。

Painterは「塗り」に特化みたいですね。Designerはノードとかいろいろ扱えるような感じ？

インディーズパック（Designer等も同梱）も安いと思いましたがとりあえず Painter のみを購入。


思うに肝は「マテリアル」ぽいですねこれ。

さまざまな質感のマテリアルがプリセットされており、それを利用することで高品位な「塗り」ができる。
（2Dだと Filter Forge をたまに使ってますが、さらに強力な３D版的な印象）

■使ってみた

一応トライアル版でも出力ができないだけで機能は一通り使えます。
しかしやはり実際出力して使ってみないと・・・ですね。


私的環境においてとりあえず試行してみた感じを以下に。
（一応３Ｄ系のこの手のツールは不慣れな為、最初結構とまどった）

□ Blenderでモデリング

練習用に２つのObjectで構成。
１つのObjectは複数マテリアル割り当て
（モデルは自作の適当なものなので見栄えが悪いですが気にしない方向で）

□ Blenderでモデルをエクスポート

OBJ形式が良いようです。
SubStance Painter はFBXを読めませんでした。
海外フォーラムなどでもＦＢＸでは読めない、OBJが無難と言った書込も散見されます。

□ SubStance Painter で Objファイルを読む

File > New。開いたダイアログの右上のSelectでObjファイル指定。
（なぜかこの開き方が最初わかりにくかった）。

□ SubStance Painter で塗り塗り

「なんとなく」わかる感じのGUI。ちょっとBlenderにも似てる。
マテリアル選択、ブラシ選択、ブラシ強度等々。

塗る際の面境界はBlender上で割り当てたマテリアル面単位（TextureSets）となっており、それを選択する画面が左にあります。

□ SubStance Painter で エクスポート

CTRL+SHIFT+Eでエクスポートのダイアログを開く。
出力フォーマットなどを指定してテクスチャをエクスポート

テクスチャ/ノーマルマップは各TextureSets単位（Blenderのマテリアル単位）で出力される。なのでこのままではUnity上で貼りにくい(マテリアルが多数あるので）。

ここで１枚に合成したテクスチャ/ノーマルマップの出力方法がわからなかった（できない？）。出力できればそのままUnityに持っていけると思ったが・・・。
やむなくBlender上で再度ベイクすることに。

※追記１： Unity4/5で使うなら素直に各エクスポートのプリセットを使う方が楽です。
※追記２： 色選択マスクを使うと、Blenderでモデリング＞SubStance Painterでマテリアル付け＞Unity持ち込みとワークフローがすっきりする感じ。 参考： 色選択マスク ～ SubStance Painter

□ Blenderのマテリアルでテクスチャを設定

テクスチャ、ノーマルマップを設定。
スペキュラは今回未設定。
各マテリアルにSubStance Painter出力のテクスチャ/ノーマルマップを設定。

□ Blenderでテクスチャ、ノーマルマップをベイク＆保存

テクスチャ、ノーマルマップを各々１枚にベイク＆保存。
ノーマルマップのベイクをするとSubStance Painterとは少し異なる結果になる（再演算してる？。
単純に１枚に合成できればいいのでテクスチャ扱いで合成すれば多分同じ結果でノーマルマップもベイクできそうな気がする。

□ Unityでテクスチャ、ノーマルマップをインポート

全く同じとまではいかないがUnity上でそれなりな感じで見える。
（シェーダー次第でまた見え方も変わりそう？）

作業フロー的には SubStance Painter はテクスチャ/ノーマルマップ/スペキュラ作成に特化した部分と考えれば良さそう。
今までここはフォトショップやBlender上でプロシージャル・テクスチャやノードでやっていた部分なのでうまく併用すれば面白そう。


ただ、複数マテリアルをテクスチャ１枚で出力はできないのかな？という点は気になる（要勉強？
ひょっとするとソコは SubStance Designer 使ってクダサイなのか・・・。


とりあえず Blender と併用でも充分使えそうなことは確認できた感じ。

4949円なら良い買い物だった気はします。


そしてSubStance Designerも気になる・・・（笑

Candy Rock Star をさわってみた#03 ～ ヘッドセット追加

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


当初ヘッドセットは作業の優先順位を低く位置付けしていました。
無くても一応成り立ちますし。

他にもっと必須事案があるわけで（カメラとかステージ効果とか）。

しかしテクスチャを変えてダンスの具合などを見ていたら、どうしても、


つけてみたいんじゃ～ ⊂⌒~⊃｡Д｡)⊃


な気分になってしまったので・・・。

凝らない、こだわらない、超速で作る、の条件を自分に課して製作。

■開発環境/ツール

Windows7x64
Unity 4.6.0f3
Blender 2.72b

■参考資料探し

ヘッドセットなんてマジマジみたことないし、ましてやステージ用などまともに見たことない。

と、いうことでネットで製品や着用状態などをチラチラ見てみる。

見れば見るほど細かい造形が気になりだす ＞ 作りこみたくなる。( ﾟдﾟ)ﾊｯ! マズイ；
（こだわりすぎて完成しないパターンの典型）

■完成しなければ負け

と、いうことで完成させることを重視な方向に思考転換（と、いう名目の手抜きへ

だいたいヘッドセットは耳からぐるっとまわして固定してる感じですが。
耳とかややこしい３次元形状のところはこの際相手にしたくない。

首＝円柱をぐるっとまわして固定。こういう感じで造形へ。

リアルで固定できるのコレ？という疑問はこの際置いておいて。


テクスチャはもはや「描かない」ことに。
（Bodyテクスチャの隙間を利用して描き込むこともできそうですが）。

Bodyテクスチャに間借りします（というか借用？）。

ヘッドセットのUV展開をBodyテクスチャの「それっぽい」ところに調整。
モデルの様子を見つつだいたいの感じに。

これだとマテリアルごと共用できるのでドローコールも増えず一石二鳥。

ユニティちゃんモデルの首まわりに置いてBlender上で合わせこみ。

CRSユニティちゃんはBlender2.7.2bでそのままではインポートできない為、既にインポート済みの従来のユニティちゃんモデルを使用。この辺の部位形状に差異はないようです。

■組み付け

ヘッドセットの組み付けはUnity上で行いました。
（CRSモデルの Blender へインポート、組み付け、エクスポート、ユレモノ設定など面倒なので）

ヘッドセットを Blender から FBX でエクスポート。
CRSのプロジェクトを開いて Unity の Asset に放り込んでインポート。


Asset > UnityChan > Prefabs にある CandyRockStar がユニティちゃんのモデル。
このプレハブを一旦Hierarchyにドラッグ＆ドロップしてシーンへ。


シーンに置いたCRSユニティちゃんのボーン階層で、

Character1_Reference > Character1_Hips > Character1_Spine > Character1_Spine1 > Character1_Spine2 > Character1_Neck　> Character1_Head

までを展開。

この Character1_Head にヘッドセットを放りこんで組み付け。
これで頭部の動きに連動。
※造形は首固定で組み付けは頭部なのは突っ込まない方向で。


位置、角度は手動で適当にぐりぐりして位置決め。
（この位置、角度はメモしておいて、他２体も同じように組み付け）。

できたら、Hierarchy から Asset にドラッグ＆ドロップで保存。以後このプレハブを使うようにする。
シーン上に残っているユニティちゃんは不要なので削除。

なんかブログで書くと長いですが、所詮シリンダー２個でヘッドセット造形、ユニティちゃんにくっつけてるだけだったり。

他、ダンス動作での干渉確認、追加で２体分プレハブ作成。



アクセサリ類はこの方法で簡単に追加できそうですね。

Blender へのユニティちゃんモデルのインポート/追加作成/エクスポートはいろいろ面倒なので。

Candy Rock Star をさわってみた#02 ～ テクスチャ

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


ダンスユニット的にユニティちゃんを３人用意する。

１体はオリジナルのままでセンター配置。これはもう決まりで。

あと２体をテクスチャのみ変更で違うタイプを作る。

■開発環境/ツール

Windows7x64
Photoshop 5.5 (メイリオ系は使えないですがWin7でも動作します)

今となっては5.5は低機能なのでGIMP2等の方が機能ははるかに上だと思います。
5.5を使ってる理由は「慣れてるから」と、だいたい使う機能が限定的なので。

つまり「高度なこと」はしないからです（笑。

ちなみにElementsは透過レイヤが使えない為お蔵入り。

■テクスチャ変更部分検討

できるだけ３人ユニットとして「統一感」を維持したい感じで検討。

主要部分は、

• 髪
• ジャケット
• 水着(?)・ニーソ
• 目
• スキン

ツノ(触覚?)はユニティちゃんのアイデンティティ(?)なので今回はいじってません。バンダナの色もそのまま。
ユニティちゃんがユニティちゃんであるには「ツノ」は最重要パーツなので！

靴もそのままです。上下の先端を同じ配色にしておいた方が安定感(?)がありそうなので。
エフェクター類は悩むところでしたが、悩むくらいならいじらないことに決定。

■配色検討

※ちなみに色彩関係においては素人です。専門家さんだときちんとした理論に基づく色彩設計の仕方があると思います。以降あくまで私的な主観に基づいています。


CRSユニティちゃんをまじまじ見ます|дﾟ)ジー。

カラーバリエーション作成は配色でどうしても迷ってしまうので、ここは色相環（マンセル図）を利用して方向性を決めてしまいます、時間もなかったので。（→ 参考： Wiki 色相環）

オリジナルのユニティちゃんの配色を見るとだいたいこんな感じ。

水着は髪の色の補色位置にきっちり選択されてます（さすがプロデザイン）。
補色は反対色なので相互に目立たせやすい色でよく使われます。


ジャケットは２つの中間となる色相環角度を取っています（ほぼ９０度位置でバランス）。
（ちなみに目は緑系なのでさらにジャケットの対向位置にありバランスしています）。

と、いうことがなんとなく見えたところで独断と偏見で、

ユニティちゃんTypeA（右担当）：

• 髪色はオリジナル（C髪）から時計回りずらして薄緑系に。
• 水着は半時計まわりにずらして緑系に。

ユニティちゃんTypeB（左担当）：

• 髪色はオリジナル（C髪）から半時計回りずらして赤系に。
• 水着は時計まわりにピンク系に。

と、それぞれをオリジナルの色位置から一定角度ずらすということでだいたいの色調の方向性を決定。
２体はそれぞれ近い色相角度内に収めることで個々で親和性(?)を持たせる感じに。
それでいて３体の配色が一定の色相角度を保っているのでそこそこ(?)チグハグにならない程度にバランスするはず（すればいいなぁくらいな感じで）。

ちなみにステージ向かって左をTypeB（ピンク系）にしたのは一応ちょっとだけ理由があります。

おおむね現代人は左上からモノを見るクセがついているので（上＞下。左＞右で文字を読むので）左は一応目につく＝派手さアピールしやすいので、そこにピンク系を配置。
ステージ右は落ち着いた感じで緑系を配置にと考えました。

実はSAK01のダンスはおとなしめ系なのでこの時点で緑のTypeAにアサインするつもりでいました。
なおかつSAK01ダンス中のキメポーズは右斜めからのアングルがカッコいい。
そうなると右斜めからSAK01のキメポーズ撮影となり、右に配置すべきだろうということで確定。
（【画質向上版 】ユニティちゃん３人で踊ってもらった　2:40付近からのポーズ等）

■作業もろもろ

○ジャケット

チェック模様やボタン類の目立たないところだけを変更程度。
ベース色の赤はそのままで３人ユニットとして「統一感」を維持。

この辺はアイマスのコス等を見ると感じるところです（アイマスやったことないですが）。
カラースキーム的に色は全員同じ色採用で統一感を維持。コスのデザイン差異＝形状差異で同一性軽減。こういう設計をしているように感じます。


今回ジャケットデザイン変更＝メッシュ修正はしないと決めているので形状はそのままです。

結果的に細かい点を少しだけいじりました。

• ユニティちゃんTypeB（左担当）：
  赤に白は王道なのでチェック模様の白はそのままにピンクを少しのせています。
  ただしベタ塗りだと安っぽくなりそうなので、ラメ的(?)な柄としてステンドグラス・フィルタを細かい目で生成。
  これをチェック模様白部分だけを抜いて下地調整、オーバーレイ、スクリーンなど３層で重ねています。
  オリジナルテクスチャには光沢も描きこまれているのでオーバレイ、スクリーンなどでその光沢描きこみも残す為です。
  
  
• ユニティちゃんTypeA（右担当）：
  赤に緑系なのでチェック模様の白部分を黒にして落ち着いた感じに(赤黒チェック柄）。
  黒ベタは安っぽくなりそうなので、皮のような模様をフィルタで生成。下地調整、オーバレイなどで重ね合わせ。その他はTypeB同様な感じで処理。

他、ジャケット/パンツの裾のボワぽいところも同様な感じで処理。

結果的に動画では「全く」わかりませんねコレ（汗；
作ってるときは楽しかったのでイイデスケドね（ボソ；

○髪

髪は最も個性付けしやすいところで重要パーツ。
とりあえず「髪をメッシュ気味」にするというのは私的に確定事項でイメージ。

まずはTypeBのピンク系がやりやすそうなので先にチャッチャと処理。

• 濃いめのキャンディ・レッド(?)と白でグラデーション作成。
• 明るめのピンクと白でグラデーション作成。

この２枚をオリジナルを下地にした上に乗算や焼きこみで重ねます。
さらにオリジナルの色調調整と、重ね位置（UVとグラデの位置具合）などを調整しつつ、ロングの毛先、生え際、左右の毛先などの位置と色加減も合わせこみ。

このとき髪のUV配置を３Ｄツールで確認した方が調整が確実ですが、これくらいならUnity上で貼って様子をみればだいたいすぐ合わせこめると思います。
一応グリッドテクスチャを一時的に重ねて貼り込んで位置確認しつつで処理。
(グリッドテクスチャ＝格子状で全マスに番号がある。貼ると位置関係が見える）

TypeAも同様な感じで作成。
こちらはベースにかなり明るいエメラルド・グリーンを使ったので、顔左右の毛先は引き締まるように青入れ。
緑青系は難しいですが、結構TypeAの髪色は気にいってます。

○水着・ニーソ

• ユニティちゃんTypeA（右担当）：
  ブラはやや明るめの緑系（ジャケに黒を入れたので少し目立たせる方向に）。
  ニーソは暗い濃い緑で引き締めて、足元はあまり主張させない。
  同一色の使い重ねがしつこいとチープ感がでやすいので地味にメリハリを。
  
  
• ユニティちゃんTypeB（左担当）：
  ジャケ、髪が既に赤系なのでブラは明るさ抑え気味な若干暗めのピンクに。
  ニーソは濃い目で輝度は微落としたちょっと重さ(?)のあるピンク。

ブラの黄色いロゴ、星マークは全て黄色系で統一感を補助。
ただし全て少しずつ黄色は異なり、ベース生地の色に合わせて微調整。

○目

一番時間がかかったところです。

ちなみにオリジナルユニティちゃんの目は左右対称形ではありません。若干差異があるようにきちんと描かれています。

• ユニティちゃんTypeA（右担当）：
  ライトブルー系になるように、色調調整を繰り返し調整。
  一応逆光フィルタで輝きぽいものを描き込んでます。→ 動画では確実にわからないですが；
  
  
• ユニティちゃんTypeB（左担当）：
  ピンク＋イエロー系になるように色調調整を繰り返し調整。
  ちょっと突っ込みどころがありそうですが、時間もなかったのでそこそこでFix。 

○スキン

• ユニティちゃんTypeA（右担当）：
  とにかく色白にしたかったので、かなり白めに調整してます。
  腰の星（☆）マークも緑にしますが若干色調を変える（他の緑と同一だと安っぽさがでるので）。
  
  
  
• ユニティちゃんTypeB（左担当）：
  服、髪が赤系なので、スキンはやや暗めの微赤系に調整。※動画だとこれもまず気づかないかも。
  腰の星（☆）マークは気持ち薄めのライトピンク。スキンの色調を暗めにしたのでここはワンポイントで少し明るめに。
  

ちなみにTypeAだけは顔に☆マークやほくろが描き込まれています。
※これも動画だと確認困難ですが、意図的にわかるかもしれないカメラアングルを仕込んでます。

結構テクスチャで印象がかわるのでこれはこれでやってて面白い作業ですが。
あんまり長時間こだわり過ぎると飽きてきてモチベが下がるので。
そこそこでFixしてしまうのがコツな気がします。

■脇の下破れ問題

これは結構早期に気づいていましたが放置してました。そもそも元のユニティちゃんがそうなっているわけですし。

ですが、ダンス中のキメポーズなところで確実に見えるのです。
いや、むしろ「見せている」ようなポーズのときがあるんですね。


これくらいならまだいいですが、

こっちは正面向きで完全に見える位置ではみでているので。

対策方法はいくつか考えられます。

1. メッシュの頂点調整でスキンがはみ出さないようにする。
   → 今回メッシュはいじらないと決めてるので却下。
   　
   
2. はみ出ているスキンのテクスチャ面だけ透過にする。
   → 元RGBをRGBAにすることになる。体全体のスキンがRGBAになるので負荷増が予想されるので却下。負荷増えるくらいなら今回は放置にする。
   
   
3. はみ出ているスキンのテクスチャ面に「上着の絵柄」を描きこむ。
   → 多分最もバランスのとれる解決策。しかし描き込むのが面倒だな～。重ねて焼きこむとかBlenderでやらないとかなぁ・・・日数もないし；
   　
   
4. はみ出ているスキンのテクスチャ面を上着の色でベタ塗りする。
   → かなり手抜きですが、動画上ではわかりにくいです。少なくとも何も対策しないよりは充分効果あり。

と、いうことで案４を採用。

グリッドテクスチャをスキンテクスチャ代わりに貼り付けて位置を特定します。
こんなテクスチャです。全マス内に番号が描かれています。

問題のポーズの状態でこれをスキンがわりにUnity上で貼って位置をだいたい特定します。

これで位置をメモしておいて、Photoshop上で元のスキンにグリッドテクスチャを重ねつつ位置を確認。
そこを問題箇所周辺の服の色でベタ塗りします。

ベタ塗りを適用した状態が右の２つです。

これなら作業がすぐ済むし意外と効果があります。

まじまじ見ると服の黒線が見えなくなるのでちょっと怪しく見えますが。
実際ダンス中はかなり気づきにくいです。元の状態に比べれば充分効果があります。

と、いう超手抜き超低工数で対策をしています。


しかし、

動画を見て、こんなことに気づいてる人は多分皆無でしょう（泣；


まぁどうでもいいといえば、どうでもいいことなので・・・。

ま～対策も短時間で済んでいるので良しです、自己納得で（笑。

ちなみにこれ以外でもはみ出ているシーンはありますが、他は今回のダンス＆カメラ視点ではわかりにくそうだったのでスルーです。


スペキュラ、ノーマルマップはオリジナルをそのまま使用。特にいじる必要性もなかったので。

だいたい主にテクスチャ関連の修正はこんなところ。
たいしたことはしてないですね・・・。

Candy Rock Star をさわってみた#01 ～ ユニティちゃんディレクター杯参加

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



※CRS は Candy Rock Star の略としてよく使われている様子（最初わからなかったのでメモ！）。
（CRSダウンロード先： http://unity-chan.com/contents/guideline/）

■さてと・・・

ユニティちゃんディレクター杯は11月初旬くらいから開催していたようです。
締め切りが12月14日23：59：59。

そしてσ(ﾟ∀ﾟ がこのイベントに気づいたのが 11/26。

残り２週間強しかない(￣д￣)ｴｰ。

この時点で普段は諦めてスルーするのですが。

UnityでCandy Rock Starを再生して眺めてるとテンション上昇。

結構気軽に参加できそうな感じもあって、なにかできないかと思案。

■なにをつくろうか

MMDとかやったことないけど、ああいう感じのものができないかな？と考えだす。
というか、そういうものが既に Candy Rock Star なわけですよね。


さてどうするか・・・。

• 投稿先はニコニコ動画指定
  ここでの投稿はやったことがない（最大不安要素 。
  プレアカはどうやら必須となりそうなのでこれは考えておく。
  
  
• 残期間は２週間半程度しかない
  ニコ動用エンコードがかなりヤバそうかも・・・妙な勘がアラート（ぁ。
  １～１週間半以内（約１０日以内）に作品完成目処。
  残りをエンコード作業にあてる日程と考えてみる。
  最悪エンコードで玉砕したら参加をスッパリ諦めると決める（弱気。
  → やっぱり苦戦しました。ニコ動エンコ＆投稿は（まともな画質で出すには）敷居高い。
  
  
• 工数１０日でできることは何か
  時間制約により「なにをつくろうか」というよりも「なにができそうか」ということにもなる。
  裏を返すと「なにができないか」ということも。
  
  
• ユニティちゃんモデルはそのまま使う
  そもそも残期間でモデルをいじってたらまず間に合わないかもしれない（うちのスキルでは。
  よって何があってもオリジナルのボーン、メッシュはいじらないと決める。
  いじらないといけないような作業は割り切って捨てる。
  （つい手を出して時間を消費することが多いので自分の中で絶対決定事項としておく）。
  ※気づいてる人はいると思いますが、CRSのユニティちゃんで万歳ポーズすると脇の下の服が破れてスキンが見えてます。正直割り切り事項ですがやはり気になるのでこれは別な方法で解決しました。
  
  
• Candy Rock Star を繰り返し視聴
  とりあえずモチベが上がるので繰り返し観る（笑。
  よくできてます。全然飽きない（多分１時間どころではない位観てます（笑
  
  
• ディレクター杯なのでディレクション重視とする
  クリエイタ要素＝設置物、小物モデル追加 ＞ しない方向。する場合は最小限と考える。
  やっても最大工数半日以下程度。
  それよりもカメラワークとか演出系（パーティクルとか）を重視することを考える方向で。
  
  
• ユニティちゃん以外のモデルの登場は？
  ユニティちゃん１体だと寂しいので、３～５体くらいで踊らせたい。
  負荷もあるので３体くらいが適当か。時間的にも負荷低減チューンはできればしたくない。
  使えそうなアバター素材を探してみる。
  いくつかあるにはあったが・・・ユニティちゃんのクオリティが高すぎる＆雰囲気がバランスしないので却下。そもそも他のライセンス的に利用可なモデルは手を入れないと使いにくそうだった。
   
• ユニティちゃんモデルはテクスチャをいじろう
  テクスチャ修正で複数体を用意・・・かな。
  なんとも逃げ口上ではあるが、テクスチャだけでもかなり見栄えがかわる・・・ハズ。
  「気軽に参加」が重要だよね、と考える。
  
  
• アイデア模索
  ステージ効果とかダンスフォーメーションで何かヒントがないかと、とりあえずラブライブを全話見直す（２期含）。アイマスも全話見直す。AKB系もちょっとPVなどみてみる。
  →なぜそうなった（笑)  → 一応まじめですしおすし、本気出してます（ｷﾘﾘ。
  →収穫ゼロ（ｺﾗ。でもテンションは上がったのでOK。
  →そんな暇があったら作業しろ（笑。
  実際は以降の作業と平行して観てたりなので大丈夫（なわけない。
  
  でもまじめな話、重要だと思いますリサーチは。
  
  
• 再度 Candy Rock Star を繰り返し視聴
  ふとAnimatorをみて気づく。アニメーションが３つ見える。
  Set as Defaultで切り替えて見るとダンスが変わる。
  つまりCRSのユニティちゃんには３つのダンスが存在している。
  これをうまく使えないか？
  ※この時点でCRSは延べ10時間以上は観てると思います（笑。
  
  
• 速攻でユニティちゃん３体登場＆ダンス
  ３体並べて３種ダンスを並列再生できるようにして鑑賞。
  鑑賞・・・ 鑑賞・・・ 鑑賞・・・（また１時間以上は見てます（笑
  メインのダンスはとにかくアクティブ、元気系として、
  他の１つ SIM01 は動作がカワイイ系な印象。みぶり手ぶりは大きめで間接動作角広め。ある程度の平面移動がある。
  もう１つの SAK01 はあまり平面移動が無く、身振り手振りも控えめなおとなし系。しかし地味にリズムを取るノリノリ動作があったり、部分部分のキメポーズがクールでかっこいい。
  これらの印象を生かすようなディレクションを主軸にするといいかもしれない。
  ひょっとしてこれ、本当はトリオでダンスなのでは？と思わせる連係動作もあり、これらも活用できるといいかもと考える。

■ざっくり方向性

おおまかな方向性と作業の見積もりなど。

○優先項目：

• ユニティちゃんモデル３体によるダンス。
  
  
• ３体の差別化はテクスチャで行う。
  →テクスチャ作業は半日程度と見積もる。
  
  
• ダンスは３体３種。
  これはプレハブを２つ作ってAnimatorいじってAssetに持ってくれば簡単にできそう。
  
  
• ３体並べてのダンスの位置関係
  そのままでも使えなくもないがちょっとニアミス気味な時はある。一応XYZ制御は視野に。
  XYZ制御をやるとRootアニメーションで動いてるのでちょっとやっかいかもしれない。２日程度はかかるかもと見積もる。
  → アテにしたいiTweenは絶対座標指定だと思うのでそのままでは使えない。一応実装案はすぐ思いついたが危惧する点もありできれば避けたい感。
  結果的に３体のダンスフォーメーションの微調整で必要になりやっぱり実装。
  垂直軸は不要かもしれないがVector3なら手間は同じ。実はダンスでジャンプする部分を垂直軸移動で少しブーストできないかと妄想していた（最終的に実装）。
  
  
• レーザーを派手にしたい
  これはMUST項目であるッ（謎。
  ビームっぽい滲みというかなんというか（ブツブツ。
  
  
• パーティクルの色を変えたい
  常時白い紙吹雪(?)パーティクルがでているので、これの色などを変えたい。
  できれば停止、再開などの制御も。
  
  
• カメラワーク
  実はあまりいじりたくない。
  が、多分いじらないと気分的にモヤっと感な気がする・・・。演出の肝な気もするし・・・。
  → 結局やった。結構悩むことになる。演出ムズカシイです。

等、諸々から、主要作業は、

• 自前のイベントスケジューラみたいなものが必要。
  タイムライン基準で各イベント処理にふりわける。
  （基幹部。シンプルに実装する）
  
  
• ステージ制御
  イベントスケジューラでハンドリングする形態にしておく。
  制御対象や数は時間があれば増やす感じで（スケーラビリティ確保）。
  
  
•  ユニティちゃんの３軸移動制御
  できれば避けたい。でもやらないとダメな気する。
  イベントスケジューラからのトリガーで起動するようにする感じ。
  iTweenでなんとかできない場合は自前実装も一応考慮。
  → 結果的にiTween＋αで実装。
  ※FBX内包のアニメを修正する手もありますが、それこそ外部NLA編集で３体をきっちり合わせるとこまでやらないとなのでパス。
  
  
• 調整（ディレクション）
  カメラワークの位置調整。ユニティちゃんの移動位置調整など。
  多分ここでかなりの時間を費やすと思うのでコードの実装自体は1週間以内に終わらせたいと考える。

○優先低項目：

時間があればやりたい項目などをざっくり（結局全部やった）。

• 楽曲 Unite in the Sky の加工編集
  音がややおとなしめなので全体的にちょっといじってみたかった（素材的にはおとなしめの方が使いやすい＝配布物としてはさすがです）。
  「さてと」の部分を強調してみたいが、Asset収録ボイスとはイントネーションが異なるのでどうするか。
  効果音を追加したいがどうせなら楽曲にミックスしたほうが音ズレも起きずCPU負荷もないので確実。
  ※レーザー類がスペクトラム分析で連動してるので、過渡な効果音は注意。
  MP３再生音の周波数スペクトラムをリアルタイムで検出できるとか最初信じがたかったです。すごすぎます。しかも複数同時でやってますねこれ。（昔スペアナとか数百万の機材でしたが時代が（ｒｙ。
  
  
• ヘッドセットを追加
  ライブなのでヘッドセットを追加したい。
  しかし時間はかけたくない。
  半日以内にメッシュ作成＆UV展開、ユニティちゃんモデルにマウントを目標とする。それ以上かかったらその時点でこの案は廃止。
  →結局３時間くらいででっちあげたのでまじまじ見るといろいろと（ｒｙ。
  
  
• パーティクルの追加
  やはりライブなのでスモークなどがあると・・・いいかも？
  パーティクル制御はUnityではやったことはないのでAsset Store頼み。
  多分主要パラメータ概念はどの開発環境でも大差ないだろうと思うのでなんとかなるだろう。
  
  
• レンズフレア
  レンズフレアって高尚な3DCGの象徴みたいなとこありますよね、うん（超主観。
  カップめんにエビさえ入ってればかつるみたいな（謎。
  でもやったことないので見当がつかない。Asset Storeで（ｒｙ。
  → 後にフレア効果が全くでないという謎問題に直面してハマることになる。
  一応忘れないうちに基本はメモ → レンズフレアの設定 ～ Unity C#
  

だいたいこんな感じで脳内ぐーるぐるで着手に。


続く。

ユニティちゃんディレクター杯 登録してみた

面白そうだったので勢いで製作しはじめたものの、なんやかんやで時間が・・・。


結局締め切り当日にアップロード（汗；


最後の最後まで、ニコニコ動画用エンコードで悩みました。
悩むというか、なかなか思うような高画質にならない。


いや、そもそもビットレート3Mbpsでは激しい動きの動画はきついという感じでしょうか。
（４分間だと最大動画サイズ規定100MBからの逆算でおよそ3Mbps強）

とりあえず（エンコードで）最善は尽くせた・・・と思います。エンコードだけで3日は使い切ってしまったOrz。



お暇な方は是非視聴してみてください


【ユニティちゃんディレクター杯 】ユニティちゃん３人で踊ってもらった


追記：最後の悪あがきで締め切り30分前にギリギリ再エンコ＆画質向上版をアップロードできました。（エンコ開始後力尽きて寝落ち＞ギリギリで起きたのは内緒ｗ）

【画質向上版 】ユニティちゃん３人で踊ってもらった



今回のCandy Rock Starステージはいろいろと勉強になりました。

いずれ気が向いたらブログにまとめておきたいなとは思います。






ちなみに「これは！？」と思った投稿作品。


【ユニティちゃん】HGベアッガイさんが踊ってみた【3Dキャプチャ】

これはすごいです！。久々にちょっと感動。


父親にも殴られたこともない人： 「こいつ・・・動くぞ」

某３倍速い人：「ニコニコの技術部はバケモノか」


すごい時代になったもんです。Autodesk のツールもすごいですが、無論使う人のスキルも必須。

正直OculusやMotion Leapよりもこの動画が一番インパクトが大きかったです。


さて、締め切りまで残すところ約１０時間、ラストスパート(?)がかかるんでしょうか。

レンズフレアの設定 ～ Unity C#

レンズフレアの設定をC#で行うメモ。

■レンズフレア

２種類いずれかのコンポーネントを使う。
※一応両方設定することも可能。

• レンズフレアコンポーネント
  ライト等のオブジェクトに付与して使う。
  
• Lightコンポーネント
  このコンポーネントのプロパティにもフレアがある。

■Lightコンポーネント

まず「Lightコンポーネント」を使う場合。

Lightオブジェクトをシーンに配置し、選択状態でInspectorを見る。

Lightコンポーネント欄の Flare がNone (Flare) になっている。この状態ではまだフレアは未設定。

Unity Editor上ならここに手動でAssetのフレアをドラッグ＆ドロップすれば設定完了。この操作をC#で行えば良い。

○フレアリソース準備

レンズフレアのAssetを用意。
Assets > Import Package > や Assets Store からインポートしておく。


インポートしたフレアはAssets配下の Resources フォルダに配置しておく。
※C#からフレアリソースをLoadする際は、対象を /Assets/Resource/ フォルダ配下に配置しておく。

○フレア設定

シーンに事前に Point Light を配置。ここではObject名 "Point light for Laser"とした。
フレアは "Laser" というものをPoint Lightに設定してみる。

-----

// Get Light object instance.
GameObject go_Pointlight_for_Laser = GameObject.Find("/Point light for Laser");

// Load Flare resource.
Flare fe_LensFlare_Laser = Resources.Load<Flare>("Lens Flares/Laser");

// Set flare to light object.
go_Pointlight_for_Laser.light.flare = fe_LensFlare_Laser;

-----


これで「Lightコンポーネント」の場合は完了。
　

■レンズフレア コンポーネント

次はレンズフレア コンポーネントを使う場合。

シーンに事前に Point Light を配置。前項同様Object名 "Point light for Laser"。
フレアは "Laser" というものをフレアコンポーネントをC#から付与して設定。

-----

// Get Light object instance.
GameObject go_Pointlight_for_Laser = GameObject.Find("/Point light for Laser");
  
// Load Flare resource.
Flare fe_LensFlare_Laser = Resources.Load<Flare>("Lens Flares/Laser");
  
// Add LensFlare component.
LensFlare lf_Pointlight_for_Laser = go_Pointlight_for_Laser.AddComponent<LensFlare>();

// Set flare to LensFlare component.
lf_Pointlight_for_Laser.flare = fe_LensFlare_Laser;

-----

これで完了。

ユニティちゃんディレクター杯 その３

だいたい出来てきて調整段階に突入。


予想通りというか、動画作成に大変手間取り中 Orz。


Youtubeならだいぶ前にAviUtlにて1920x1080で過去アップロードを試してみたこともありますが。

ニコニコ動画はいろいろと大変な様相。

ニコニコ動画のアップロードの制約上、動きの激しい動画ではプレアカにしないと話にならない感じ。


プレアカ前提でいろいろ調べていくと、
（動画時間は４分程度を想定）

• 最大ファイルサイズは100MBytes。
• 逆算すると概ねビットレートは3Mbps強が限界。
• ニコニコ動画側はi420（YUV420）だと良いらしい（DVD世代の非HD仕様）。
• ここまでの仕様状況を鑑みると動画サイズはワイドなら640x360、スクエアなら512x384程度が限界。
• ファイルサイズ、動画フォーマットが規定外だと再エンコードされて劣化する。

機会があれば別途この辺はまとめておきたいところですが、とりあえず、

• アマレココで試す
  →遅かった。XP時代のものなのでしょうがない。
• アマレコTV（暫定Win7対応版）で60fpsを目指してRGBでHD（1280x720）録画。
  → HDDでは書込が間に合わずコマ落ち発生。
  　　諸々調整するも玉砕。
  → SSDで強引回避。
• アマレコTVのタスクスケジュール配分調整
  →たまにコマ落ちの気配を感じたので。CPUパワー不足？
• AviUtlでMP4にエンコード（640x480化）。
  ニコニコ動画プリセットが使えるところまでやっと環境構築＆エンコード。

やっとマシなエンコードができるようになってきたので、キャプチャパラメータ、エンコードパラメータも試行中。


ニコニコ動画ってアップロード制限いろいろと厳しかったんですね；
ほんと制約厳しすぎます；

Google検索エンジンからのアクセス激減

Google検索エンジンからのアクセス激減について。

激減後、復旧したので一応メモ。

巷ではこのような状況は有名なようで、検索するといろいろでてきますね。

正直うちみたいな弱小ブログは関係無いと思っていましたが・・・。

2014/9/6頃から10/25頃までスパっと落ちてますね。
落ちたところでPV数は元々大したことはないのですが、

「え？なんで落ちたんだろう？？？」


と、気にはなるわけです。

■状況調査

と、いってもだいたいのことは既に多くのサイトに書かれているので既出ですが。

まずはアクセスの流入元の変動を確認。
Google Analytics なら、集客＞すべてのトラフィック等で。
Googleウェブマスターツールなら、検索トラフィック＞検索クエリ のクエリ数、表示回数等。

うちの場合は従来に比べて極端にすべての数が落ち込んでいました。
自然なアクセス減少とは思いにくいのはほぼ明らか気味。

もしもAdSenseなどでペナルティを受けている場合は、ウェブマスターツールの、

検索トラフィック＞手動による対策

に何か表示されるらしいのですが、

「手動によるウェブスパム対策は見つかりませんでした。」

としか表示されていないので特に問題は起きてないようでした。

しかし何かが起こっている(?)のは間違いなさそうです。

■原因調査

はっきり言って特定できませんでした。
特にAdSenseやブログ規約に違反しているわけというわけではなさそうですし。
総合すると単にGoogle検索のアルゴリズムが微変更？か何かで影響を受けていたのかもしれませんが、わかりません。

■対策

原因もわからないまま対策とはおかしな話ではありますが。
とりあえず考えられそうなところに手を入れました。
いろいろやったので覚えてる限りを以下に列挙。

○AdSenseの規約を再確認。

ページを開いたときに、上部の広告で記事本文がが押し下げられてしまうとよろしくないとのこと。
PC画面では大丈夫でもタブレット、スマホ等の画面解像度が小さい場合にこれに該当してしまう場合有らしい。
多分大丈夫そうな気はしましたが念の為ページ最上部のブログ名のフォントサイズを少し小さめにして対応。

○記事のタイトル

同じ単語が複数の記事で多く含まれるのはよろしくないらしい。
10や20記事くらいでは問題ないらしいのですが、一応一部記事のタイトルを修正。

○広告のフィルタ

アダルト系、それに準ずる広告は結構厳しいようです。

元々AdSenseにおいては、宗教、性に関する内容、ギャンブルは当初よりフィルタ済み。
一応これに加えて、リプロダクティブ ヘルスも追加。

i-mobileなどは「強フィルタ」でもアダルト色のものがでる可能性はあるらしいので要注意。
管理ページのフィルタリングボックスで一部の電子書籍コミック系の広告ドメインを追記してフィルタ。

※2014/12現在では「強フィルタ＋」というのがあるようで、これでアダルト色を一切排除できる様子。前はコレなかった気がするのですが・・・。

○Google ウェブマスターツール

各項目でエラーがでていないか確認。

• 検索のデザイン
• 構造化データ
  参考記事：ウェブマスターツールの構造化データで hatom エラーの解消
• HTMLの改善
  「タイトルの重複」だけがいまだに消せません。どうも月ごとの「ブログ アーカイブ」パーツからのリンクでそう検知しているような気がします。放置中。
•  クロール
• クロールエラー
  ネット不調でクロールできていない場合が結構あるので（404レスポンスコード）その辺はゆるめに見る。
• Fetrch as Google
  念の為、「取得」している。
•  サイトマップ
• 未登録だったので、登録してみた。

もっといろいろやったような気もしますが、もはや覚えてないのと、どっちしても修正後は改善が見られなかったので・・・。

■結局は

いろいろ対策してみたものの１月以上変化無し。
２ヶ月弱経過で急に元に戻った感じです。

Google検索による表示数が激減していたのは間違いないので、Google先生のご気分次第・・・なんでしょうかねやはり。

結局まじめにコンテンツ＝記事を書いているならば、慌てず騒がずじっと地道に記事を増やしつつ待つのが得策なんでしょうかね。



 

パーティクルをいじる ～ Candy Rock Star

公開されているUnityちゃんの「Candy Rock Star」でパーティクルをいじってみたメモ。


（Unity上で既に「Candy Rock Star」が動いてる前提。理解不足などある可能性大なので注意）。

■手動でいじってみる

＃１．パーティクルを放出しているオブジェクト

Unity上で再生してHierarchyウィンドウを見てみると Confetti(Clone) というオブジェクトができている。
これがパーティクル放出を担当しているオブジェクト。
（動的生成されているので再生中しかHierarchyウィンドウに現れない）

＃２．パーティクルの色を手動で変更

再生を一時停止して、Hierarchyウィンドウ > Confetti(Clone) 配下の オブジェクトParticle System を選択する。
Inspectorウィンドウを見るとパーティクル設定が見える。
色は Start Color をいじれば即再生に反映される。
　

＃３．パーティクルを手動でON/OFF

Inspectorウィンドウ上部のオブジェクトParticle Systemを有効/無効のチェックを操作するとパーティクル放出もON/OFF変化する。

　

＃４．パーティクルのレイヤ

パーティクル用に設けられたレイヤ名 Particle に Confetti(Clone) は配置されている。
このオブジェクトの子には Directional Light があり、それも同じレイヤにある。
ということは Directional Light を調整すると Particleだけを対象としたライト効果を操作できる。
　

＃５．動的生成元

ここまでみてきた Confetti(Clone) の動的生成元（プレハブ）はProjectウィンンドウ内の /Asset/UnityChanStage/Prefabs/Confetti。
（※Confetti (light) というのも見えるがParticle Systemを１つにした軽量バージョンかもしれない？）
変更を加えたい場合はこちらのプレハブを変更すれば再生時に反映される。

■再生時のパーティクル起動

/Asset/UnityChanStage/Prefabs/Confetti の中のスクリプト PropActivator が再生後パーティクルの放出をしている。

これは前述でInspectorから手動でON/OFFした操作をスクリプトから行っているだけ（gameObject.SetActive(true); ）。

ただ、動的生成されている点に加え、呼び出しシーケンスが少々複雑であった。

1. 再生開始
2. オブジェクト/Stage Director内のスクリプト StageDirector が実行開始。
   StageDirector の Inspector の Prefabs Needs Activation は動的生成するオブジェクトの一覧の配列。ここに Confetti が事前に登録されている。
   スクリプト StageDirector はこの一覧のオブジェクトを（Awake()内から）動的生成する（インスタンス化）。
   　
3. スクリプトPropActivator内 void ActivateProps() の呼び出し元は？
   動的生成された オブジェクトConfetti(Clone) にはスクリプト PropActivator が入っているが、Start()もAwake()も無い。
   void ActivateProps() のみがあるだけでpublic関数でもない。なので外部からの通常の関数呼び出しは不可能。
   しかしこの関数は再生開始後しっかり呼びだされる。
   つまり「別の方法」で呼び出されている。
   　
4. ブロードキャスト経由で呼び出し。
   スクリプト PropActivator の void ActivateProps() を呼び出している箇所はどうやらスクリプト StageDirector 内の void ActivateProps()。
   ここからブロードキャストメッセージ経由で呼び出している様子。
   メッセージの送り先オブジェクトは配列 prefabsNeedsActivation（オブジェクト/Stage DirectorのInspectorで見える）を対象に送り付けている。
   　
5. 管理の大元スクリプト StageDirector 内の public void ActivateProps() を呼び出すコードが存在しない。
   ここまでで、オブジェクト/Stage Director 内のスクリプト StageDirector の public void ActivateProps() がパーティクルオブジェクト郡へメッセージ経由でオブジェクトの有効化＝パーティクル放出開始をしていると見て取れる。
   しかし当のこの関数 public void ActivateProps() をアクセスしている箇所がC#のコード上に存在しない。
   どこから呼ばれているのか？
   　
6. Animation Eventから呼び出されている。
   Hierarchyウィンドウでオブジェクト/Stage Director を選択。
   上部ツールバーのWindows > Animation（又はCTRL-6）。
   これでオブジェクト/Stage Directorに紐ついている(?) Animationの状態が確認できる。
   （まさにBlenderのNLAエディタみたいな感じ？）
   ホイールをまわすと時間スケールを変えて見れる。
   ここから関数ActivateProps()が呼び出される。
   　

 ■Animation Event

 上部ツールバーのWindows > Animation（又はCTRL-6）で開くと以下のように見える。

このタイムライン上にイベントを打ち込めるようで、そのイベントから関数呼び出しができるようだ（白い縦棒がイベント）。
白棒にマウスオーバーするとイベントでの呼び出し関数名が見える。

この白棒のある横軸のタイムラインエリアで右クリックAdd Animation Eventでイベント追加＆呼び出し関数の指定ができる。
この際当該オブジェクト内スクリプト（複数あれば全部）のpublic関数が候補にでてくる様子。

■まとめ？

たかがパーティクルのON/OFFなので、対象オブジェクトのGameobjectを取得＆操作で済みそうだと思ったら、結構複雑なことをしていた。

○BroadcastMessageによる制御

まずBroadcastMessageを使う意味について。
思うに対象オブジェクトとその階層下ならどこに移動しても制御可能なのがメリット・・・だと思われる（相手がpublic関数でなくても呼べる）。
複数Objectに増えてもそのまま対応できる。

結果的に Candy Rock Star では対象オブジェクトそのものにスクリプトが付いているが、開発中にスクリプトを子に移動したりしても呼び出してくれるので、これはちょっと楽かもしれない。

これを Getcomponents() でスクリプトのハンドルを拾う場合は子階層も追跡して拾うことになる
（自前追加実装部分ではこれをやっているが、ちょっと動きを確認したい時はメッセージの方が楽だとは思う。ただメッセージは重いので多用注意ぽい）。

今回の当該箇所はパーティクルの関数呼び出し回数も少ないので、開発中の簡便さでこうなっているのかなと推察。子オブジェクトの１パーティクル/２パーティクル版にもそのまま対応できるし。

○Animation Event

これは・・・めっちゃ便利そうです。
そしてこれに気づく前に、経過時間で各種自前イベント発生＆処理を振り分ける機構を既にC#で実装、イベントもほとんど実装し終わってしまったのは内緒・・・（号泣；

パーティクルを先に手をつけとくべきだったか・・・Orz

いやほんとこの機能は便利だと思います。特に Candy Rock Star のような時間進行でイベントが発生するものは。



やはり人のコードを読むのは勉強になりますね。
Candy Rock Star は良い題材だと思います。