ラベル Unity-CandyRockStar の投稿を表示しています。 すべての投稿を表示
ラベル Unity-CandyRockStar の投稿を表示しています。 すべての投稿を表示

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体のダンスフォーメーションはこれで駆動しているのでイベント発生タイミングと移動量、速度の調整は、やはり予想通りそれなりに時間を費やすこととなりました;

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

2014年12月22日月曜日

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

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



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

■開発環境/ツール

Windows7x64
Unity 4.6.0f3



■Laserオブジェクト

レーザーの照射部分は1つのプレハブから生成しているようでいくつかの箇所から照射されています。ステージ上の複数のスピーカー 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に移して発光増しの演出を制御。




■補足

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

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



2014年12月18日木曜日

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

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


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

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

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


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


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

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


■開発環境/ツール

Windows7x64
Unity 4.6.0f3
Blender 2.72b



■参考資料探し

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

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

見れば見るほど細かい造形が気になりだす > 作りこみたくなる。( ゚д゚)ハッ! マズイ;
(こだわりすぎて完成しないパターンの典型)


■完成しなければ負け

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

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

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

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


テクスチャはもはや「描かない」ことに。
(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 にヘッドセットを放りこんで組み付け。
これで頭部の動きに連動。
※造形は首固定で組み付けは頭部なのは突っ込まない方向で。


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

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






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

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



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

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


2014年12月16日火曜日

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

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


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

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

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


■開発環境/ツール

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

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

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

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


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

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

主要部分は、
  • 髪
  • ジャケット
  • 水着(?)・ニーソ
  • 目
  • スキン
ツノ(触覚?)はユニティちゃんのアイデンティティ(?)なので今回はいじってません。バンダナの色もそのまま。
ユニティちゃんがユニティちゃんであるには「ツノ」は最重要パーツなので!

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



■配色検討

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


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

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

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


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


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

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




ユニティちゃんTypeA(右担当):
  • 髪色はオリジナル(C髪)から時計回りずらして薄緑系に。
  • 水着は半時計まわりにずらして緑系に。

ユニティちゃんTypeB(左担当):
  • 髪色はオリジナル(C髪)から半時計回りずらして赤系に。
  • 水着は時計まわりにピンク系に。

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

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

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

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


■作業もろもろ

○ジャケット

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

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



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

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

  • ユニティちゃんTypeA(右担当):
    赤に緑系なのでチェック模様の白部分を黒にして落ち着いた感じに(赤黒チェック柄)。
    黒ベタは安っぽくなりそうなので、皮のような模様をフィルタで生成。下地調整、オーバレイなどで重ね合わせ。その他はTypeB同様な感じで処理。



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

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


○髪


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

まずはTypeBのピンク系がやりやすそうなので先にチャッチャと処理。
  • 濃いめのキャンディ・レッド(?)と白でグラデーション作成。
  • 明るめのピンクと白でグラデーション作成。
この2枚をオリジナルを下地にした上に乗算や焼きこみで重ねます。
さらにオリジナルの色調調整と、重ね位置(UVとグラデの位置具合)などを調整しつつ、ロングの毛先、生え際、左右の毛先などの位置と色加減も合わせこみ。

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

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




○水着・ニーソ

  • ユニティちゃんTypeA(右担当):
    ブラはやや明るめの緑系(ジャケに黒を入れたので少し目立たせる方向に)。
    ニーソは暗い濃い緑で引き締めて、足元はあまり主張させない。
    同一色の使い重ねがしつこいとチープ感がでやすいので地味にメリハリを。

  • ユニティちゃんTypeB(左担当):
    ジャケ、髪が既に赤系なのでブラは明るさ抑え気味な若干暗めのピンクに。
    ニーソは濃い目で輝度は微落としたちょっと重さ(?)のあるピンク。

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


○目

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

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

  • ユニティちゃんTypeA(右担当):
    ライトブルー系になるように、色調調整を繰り返し調整。
    一応逆光フィルタで輝きぽいものを描き込んでます。→ 動画では確実にわからないですが;

  • ユニティちゃんTypeB(左担当):
    ピンク+イエロー系になるように色調調整を繰り返し調整。
    ちょっと突っ込みどころがありそうですが、時間もなかったのでそこそこでFix。 




○スキン

  • ユニティちゃんTypeA(右担当):
    とにかく色白にしたかったので、かなり白めに調整してます。
    腰の星(☆)マークも緑にしますが若干色調を変える(他の緑と同一だと安っぽさがでるので)。


  • ユニティちゃんTypeB(左担当):
    服、髪が赤系なので、スキンはやや暗めの微赤系に調整。※動画だとこれもまず気づかないかも。
    腰の星(☆)マークは気持ち薄めのライトピンク。スキンの色調を暗めにしたのでここはワンポイントで少し明るめに。



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







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



■脇の下破れ問題

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

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


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

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


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

  1. メッシュの頂点調整でスキンがはみ出さないようにする。
    → 今回メッシュはいじらないと決めてるので却下。
     
  2. はみ出ているスキンのテクスチャ面だけ透過にする。
    → 元RGBをRGBAにすることになる。体全体のスキンがRGBAになるので負荷増が予想されるので却下。負荷増えるくらいなら今回は放置にする。

  3. はみ出ているスキンのテクスチャ面に「上着の絵柄」を描きこむ。
    → 多分最もバランスのとれる解決策。しかし描き込むのが面倒だな~。重ねて焼きこむとかBlenderでやらないとかなぁ・・・日数もないし;
     
  4. はみ出ているスキンのテクスチャ面を上着の色でベタ塗りする。
    → かなり手抜きですが、動画上ではわかりにくいです。少なくとも何も対策しないよりは充分効果あり。
と、いうことで案4を採用。

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



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

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





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

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

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

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


しかし、

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


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

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

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


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

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


2014年12月15日月曜日

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。

残り2週間強しかない( ̄д ̄)エー。

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

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

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

■なにをつくろうか


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


さてどうするか・・・。

  • 投稿先はニコニコ動画指定
    ここでの投稿はやったことがない(最大不安要素 。
    プレアカはどうやら必須となりそうなのでこれは考えておく。

  • 残期間は2週間半程度しかない
    ニコ動用エンコードがかなりヤバそうかも・・・妙な勘がアラート(ぁ。
    1~1週間半以内(約10日以内)に作品完成目処。
    残りをエンコード作業にあてる日程と考えてみる。
    最悪エンコードで玉砕したら参加をスッパリ諦めると決める(弱気。
    → やっぱり苦戦しました。ニコ動エンコ&投稿は(まともな画質で出すには)敷居高い。

  • 工数10日でできることは何か
    時間制約により「なにをつくろうか」というよりも「なにができそうか」ということにもなる。
    裏を返すと「なにができないか」ということも。

  • ユニティちゃんモデルはそのまま使う
    そもそも残期間でモデルをいじってたらまず間に合わないかもしれない(うちのスキルでは。
    よって何があってもオリジナルのボーン、メッシュはいじらないと決める。
    いじらないといけないような作業は割り切って捨てる。
    (つい手を出して時間を消費することが多いので自分の中で絶対決定事項としておく)。
    ※気づいてる人はいると思いますが、CRSのユニティちゃんで万歳ポーズすると脇の下の服が破れてスキンが見えてます。正直割り切り事項ですがやはり気になるのでこれは別な方法で解決しました。

  • Candy Rock Star を繰り返し視聴
    とりあえずモチベが上がるので繰り返し観る(笑。
    よくできてます。全然飽きない(多分1時間どころではない位観てます(笑

  • ディレクター杯なのでディレクション重視とする
    クリエイタ要素=設置物、小物モデル追加 > しない方向。する場合は最小限と考える。
    やっても最大工数半日以下程度。
    それよりもカメラワークとか演出系(パーティクルとか)を重視することを考える方向で。

  • ユニティちゃん以外のモデルの登場は?
    ユニティちゃん1体だと寂しいので、3~5体くらいで踊らせたい。
    負荷もあるので3体くらいが適当か。時間的にも負荷低減チューンはできればしたくない。
    使えそうなアバター素材を探してみる。
    いくつかあるにはあったが・・・ユニティちゃんのクオリティが高すぎる&雰囲気がバランスしないので却下。そもそも他のライセンス的に利用可なモデルは手を入れないと使いにくそうだった。
     
  • ユニティちゃんモデルはテクスチャをいじろう
    テクスチャ修正で複数体を用意・・・かな。
    なんとも逃げ口上ではあるが、テクスチャだけでもかなり見栄えがかわる・・・ハズ。
    「気軽に参加」が重要だよね、と考える。

  • アイデア模索
    ステージ効果とかダンスフォーメーションで何かヒントがないかと、とりあえずラブライブを全話見直す(2期含)。アイマスも全話見直す。AKB系もちょっとPVなどみてみる。
    →なぜそうなった(笑)  → 一応まじめですしおすし、本気出してます(キリリ。
    →収穫ゼロ(コラ。でもテンションは上がったのでOK。
    →そんな暇があったら作業しろ(笑。
    実際は以降の作業と平行して観てたりなので大丈夫(なわけない。

    でもまじめな話、重要だと思いますリサーチは。

  • 再度 Candy Rock Star を繰り返し視聴
    ふとAnimatorをみて気づく。アニメーションが3つ見える。
    Set as Defaultで切り替えて見るとダンスが変わる。
    つまりCRSのユニティちゃんには3つのダンスが存在している。
    これをうまく使えないか?
    ※この時点でCRSは延べ10時間以上は観てると思います(笑。

  • 速攻でユニティちゃん3体登場&ダンス
    3体並べて3種ダンスを並列再生できるようにして鑑賞。
    鑑賞・・・ 鑑賞・・・ 鑑賞・・・(また1時間以上は見てます(笑
    メインのダンスはとにかくアクティブ、元気系として、
    他の1つ SIM01 は動作がカワイイ系な印象。みぶり手ぶりは大きめで間接動作角広め。ある程度の平面移動がある。
    もう1つの SAK01 はあまり平面移動が無く、身振り手振りも控えめなおとなし系。しかし地味にリズムを取るノリノリ動作があったり、部分部分のキメポーズがクールでかっこいい。
    これらの印象を生かすようなディレクションを主軸にするといいかもしれない。
    ひょっとしてこれ、本当はトリオでダンスなのでは?と思わせる連係動作もあり、これらも活用できるといいかもと考える。

■ざっくり方向性

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

○優先項目:

  • ユニティちゃんモデル3体によるダンス。

  • 3体の差別化はテクスチャで行う。
    →テクスチャ作業は半日程度と見積もる。

  • ダンスは3体3種。
    これはプレハブを2つ作ってAnimatorいじってAssetに持ってくれば簡単にできそう。

  • 3体並べてのダンスの位置関係
    そのままでも使えなくもないがちょっとニアミス気味な時はある。一応XYZ制御は視野に。
    XYZ制御をやるとRootアニメーションで動いてるのでちょっとやっかいかもしれない。2日程度はかかるかもと見積もる。
    → アテにしたいiTweenは絶対座標指定だと思うのでそのままでは使えない。一応実装案はすぐ思いついたが危惧する点もありできれば避けたい感。
    結果的に3体のダンスフォーメーションの微調整で必要になりやっぱり実装。
    垂直軸は不要かもしれないがVector3なら手間は同じ。実はダンスでジャンプする部分を垂直軸移動で少しブーストできないかと妄想していた(最終的に実装)。

  • レーザーを派手にしたい
    これはMUST項目であるッ(謎。
    ビームっぽい滲みというかなんというか(ブツブツ。

  • パーティクルの色を変えたい
    常時白い紙吹雪(?)パーティクルがでているので、これの色などを変えたい。
    できれば停止、再開などの制御も。

  • カメラワーク
    実はあまりいじりたくない。
    が、多分いじらないと気分的にモヤっと感な気がする・・・。演出の肝な気もするし・・・。
    → 結局やった。結構悩むことになる。演出ムズカシイです。



等、諸々から、主要作業は、
  • 自前のイベントスケジューラみたいなものが必要。
    タイムライン基準で各イベント処理にふりわける。
    (基幹部。シンプルに実装する)

  • ステージ制御
    イベントスケジューラでハンドリングする形態にしておく。
    制御対象や数は時間があれば増やす感じで(スケーラビリティ確保)。

  •  ユニティちゃんの3軸移動制御
    できれば避けたい。でもやらないとダメな気する。
    イベントスケジューラからのトリガーで起動するようにする感じ。
    iTweenでなんとかできない場合は自前実装も一応考慮。
    → 結果的にiTween+αで実装。
    ※FBX内包のアニメを修正する手もありますが、それこそ外部NLA編集で3体をきっちり合わせるとこまでやらないとなのでパス。

  • 調整(ディレクション)
    カメラワークの位置調整。ユニティちゃんの移動位置調整など。
    多分ここでかなりの時間を費やすと思うのでコードの実装自体は1週間以内に終わらせたいと考える。

○優先低項目:

時間があればやりたい項目などをざっくり(結局全部やった)。
  • 楽曲 Unite in the Sky の加工編集
    音がややおとなしめなので全体的にちょっといじってみたかった(素材的にはおとなしめの方が使いやすい=配布物としてはさすがです)。
    「さてと」の部分を強調してみたいが、Asset収録ボイスとはイントネーションが異なるのでどうするか。
    効果音を追加したいがどうせなら楽曲にミックスしたほうが音ズレも起きずCPU負荷もないので確実。
    ※レーザー類がスペクトラム分析で連動してるので、過渡な効果音は注意。
    MP3再生音の周波数スペクトラムをリアルタイムで検出できるとか最初信じがたかったです。すごすぎます。しかも複数同時でやってますねこれ。(昔スペアナとか数百万の機材でしたが時代が(ry。

  • ヘッドセットを追加
    ライブなのでヘッドセットを追加したい。
    しかし時間はかけたくない。
    半日以内にメッシュ作成&UV展開、ユニティちゃんモデルにマウントを目標とする。それ以上かかったらその時点でこの案は廃止。
    →結局3時間くらいででっちあげたのでまじまじ見るといろいろと(ry。

  • パーティクルの追加
    やはりライブなのでスモークなどがあると・・・いいかも?
    パーティクル制御はUnityではやったことはないのでAsset Store頼み。
    多分主要パラメータ概念はどの開発環境でも大差ないだろうと思うのでなんとかなるだろう。

  • レンズフレア
    レンズフレアって高尚な3DCGの象徴みたいなとこありますよね、うん(超主観。
    カップめんにエビさえ入ってればかつるみたいな(謎。
    でもやったことないので見当がつかない。Asset Storeで(ry。
    → 後にフレア効果が全くでないという謎問題に直面してハマることになる。
    一応忘れないうちに基本はメモ → レンズフレアの設定 ~ Unity C#

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


続く。

2014年12月1日月曜日

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

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


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



■手動でいじってみる


#1.パーティクルを放出しているオブジェクト

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




#2.パーティクルの色を手動で変更

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


#3.パーティクルを手動でON/OFF


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

 

#4.パーティクルのレイヤ

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

#5.動的生成元


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



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


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

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



○Animation Event

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

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

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



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