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

2015年3月12日木曜日

Google提供の日本語Webフォント

いまさらですが、Googleが日本語Webフォントを提供していた という記事をチラっと見かけたのでちょっとメモ。



■予備知識


同じ文章でも異なる文字の形で読んでいる

今ではパソコン、スマホ、タブレット等々と様々な機器でブログ/HPを閲覧しています。

閲覧時、普通は各機器に内蔵の「日本語フォント」を用いて表示しています。
MACとWindowsマシンではちょっと違う雰囲気の漢字(フォント)で読んでいたりするわけです。
Android、iPhoneでもちょっと違うかも?

フォントもサイトデザインの一環

しかしタイポグラフィ(?)的というか文字フォントも「サイトデザイン」の一部といえます。

できれば万人に同じフォントで同じ雰囲気で読んでもらいたい、という要望も一部ではあります。
※極論、明朝フォントでサイトは作ったつもりが、閲覧機器の内蔵フォントの都合でゴシックで表示された、など。
 

Webフォント

平たく言うと、Web上から日本語フォントデータを「もってくる」技術。

なので、どんな機器でも同じ日本語フォントで閲覧できるように。
フォントデータ自体はTTFやOTFなので別段特殊なものではない。

肝はスタイルシートで「オンライン上のフォントデータ」を指定できるという点。

ライセンス

ブログやHPはパブリックスペースなので、フォントの使用ライセンスに注意が必要。
商用サイトならばなおさらです。

この辺はなかなか面倒な話しですが「Web上でも自由に使える」という点で、Google提供のフォントは使いやすいライセンスである、ということが注目点です。

実質ほぼ自由に使用可能です。



■Google提供の日本語フォント


フォント名: Noto Fonts。

サンプル表示&ダウンロード先: Beautiful and free fonts for all languages

ブログで使う場合はCSS指定で特にダウンロードせずとも使えます。
ダウンロードして自サーバに置いてもOK。

□ライセンス

SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007」を適用とあります。

参考:Wiki SIL Open Font License


□つまりどういうこと?ヽ(`Д´)ノ ?

端的に言うと、、

  • 自由に使っていいよ O(≧▽≦)O ワーイ♪
    ブログやHPの表示に自由に使っても良い。
    ※パブリックスペースでの使用可。商用可。

  • 「フォントだけ」を販売してはダメ (´・x・`) 転売ダメ!
    ざっと見る限りダメだと思います。
    する人もまずいないとは思いますが・・・。

  • でも、アプリに組み込んでアプリを売るのはいいよ♪\(^o^)/ ヤッター
    Unity?Unityで利用可能なのか!?
    日本語フォントの入ってないAndroid機でも日本語だせるね!(ぇ

ざっくりこんな感じ。
※あくまでざっくりです。ライセンスの読み間違い等の可能性もありえます。
フォント利用&ライセンス確認は自己責任にて。当ページに間違いがあっても一切責任持てませんので念の為。



■Bloggerでつかってみる

CSSに追加するだけです。


ログインしてBloggerの管理ページに行く。

左列メニューから「テンプレート」をクリック。
「カスタマイズ」をクリック。

上級者向けをクリック。

CSSを追加をクリック。

カスタムCSSの欄に次をコピペする。
@import url(http://fonts.googleapis.com/earlyaccess/notosansjapanese.css);
body{
font-family:'Noto Sans Japanese';
}

まだ試験運用的な雰囲気もありそうなので、恒常的に安定利用可能かは若干注意かもしれません。

■Unityでつかってみる

結論からいうと使えます。動作確認済み。

Asset配下のResourceフォルダ以下にフォントデータを配置すればC#から読めます。

メッシュテキストならこんな感じでフォントをロード。
public TextMesh txtmesh;
txtmesh.font = Resources.Load("NotoSansCJKjp-Light");



■独り言

ここまで書いておいて、言うのもなんですが・・・。

特別綺麗なフォントというわけでも・・・ないよね?;(スイマセン;スイマセン;

いや、でも一頃のアレやコレなフォントで苦労したことを思えば・・・充分綺麗ですよネ!

ライセンス的にもクリアですし、安心感が違うっ!なんせGoogleだしねっ!


BloggerではCSSでメイリオ指定した方がWindowsだと綺麗だしなぁ(ボソ
Unity利用でも梅フォントとか結構好きだし(ボソ


でもWindowsのPゴシックよりは良い感じだし、選択肢が広がるのは良いと思います。




参考記事:グーグルが日本語Webフォントを提供してた。これはWebフォントの大転換になるかも?

2015年3月11日水曜日

Unity4のプロジェクトをUnity5でコンパイルしてみた

Unity 5 Personal Edition が公開されましたね。

従来PRO版のみだった、あれやこれやの機能も使えるようになって驚きです。

まさに大盤振る舞い、スバラシイ!ユニティ・テクノロジーズ!


と、いうことで従来Unity4のプロジェクトをUnity5でコンパイル。

ちょっと気付いた点をメモ。


バイナリサイズ

Unity4でAndroid用に過去作成したアプリをUnity5でコンパイルしたところ、

Unity4: 12301KB
Unity5: 14326KB

と、ちょっとだけ(約2MB)増えていることに気付きました。

とりあえずいろいろ見渡してみたところではこの2MBの差がどうにも詰まりません。


空プロジェクトで比較

Unity4/5共に空プロジェクトを作り、Android用(ARM v7)でコンパイル。

バイナリサイズを比較してみました。

Unity4:  8468KB
Unity5: 10120KB

やはりUnity5の方が約2MB程多いです。

これは・・・仕様かな?。

VerUPするとよくあるパターン(?)でしょうか。


機能面向上とのトレードオフとも言えそうなのでやむを得ない感じ?。
※何か他の設定でUnity4並みにできる手立てはあるのかもしれません。

一応従来アプリを再コンパイルする際は若干注意。
※特にAndroidアプリ等はロード=起動時間にも関係するので。




おまけ~Device Filter

当初これに気付かずバイナリサイズが2倍になって焦ったのでメモ。

これはUnity4から存在するものなので特にUnity5だから、というものではありません。


※Unity4のAndroidアプリプロジェクトを初回変換した後にARM+86になっていたことに気付く。
変換時に変更された?と思い、その後空プロジェクトのUnity4>5変換では正確に設定を引き継いでいるのを確認。
しかし旧Unity4のアプリプロジェクトはARMのみ指定なことも確認。
Unity5に変換後に人為的に弄ってしまったのか?よくわかりませんが、ちょっと焦ったのでメモです(´・ω・`)


CTRL+SHIFT+B で Build Setting を開き、Androidに Switch Platform。
Player Setting を クリック。

Inspectorを見ると、Other Settings の中に Device Filter があります。

そこで生成するバイナリ種を指定するのですが、

FAT(ARM v7+86)

に、なっていた為、ARMとx86両方のバイナリを埋め込む為サイズが倍近くになっていました。

ARM v7

こちらに設定すると、ARMのみのバイナリになるのでサイズが小さくなります。


ちなみにUnity5新設オプションの、

Android TV Compatibility
Android Game

では、サイズ変動なしでした。

2014年12月29日月曜日

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のImpoter設定はこんな感じ。



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でアニメくらいは作れそうです。


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月12日金曜日

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

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


■レンズフレア


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


  • レンズフレアコンポーネント
    ライト等のオブジェクトに付与して使う。
  • 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;
-----

これで完了。

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. スクリプトPropActivatorvoid 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 は良い題材だと思います。




2014年8月12日火曜日

UnityChanをBlenderでインポート/エクスポート試行

UnityちゃんをBlenderでインポート/エクスポートしてみたメモ。

試行錯誤中なので、間違い/思い違いを含む可能性有りです。




環境

  • Windows7x64
  • Blender2.70a
  • UnityChan Ver1.2

問題点


Blender標準のFBXインポーターだと全くインポートできない。

有志提供によるプラグイン Bos FBX Importer/Exporter を使うと一応できた。



※追記:Blender2.72aでは標準搭載のImporterで読み込めます。逆にBosが動作しなくなくなりました。BlenderのFBXプラグインが大幅に機能対応したようです。


現状 Bos FBX Importer/Exporter を利用するのが良さそう。

追記:.blendファイルでUnityへの直接読込は試していません。
    情報としては2.67では問題があるとのこと。  
  
 

できたこと/できなかったこと等々

Bos FBX Importer/Exporter を利用して試行。

  • UnityChanのモデルをBlenderでインポートできた
     
  • ボーンはインポートできる
    Armatureの設定がされた状態になる。
    → Good!。
     
  • 一部のパーツはボーンから外れる
    頭部連動の目、眉など。(UnityChanの設計上そうなってる感じ?プラグイン云々とは別の話しかもしれない?)。
     
  • Weight Paint はインポートされないもインポートされる。
    そもそもUnityでHumanoid型で設定するのでWeightデータが存在していない?
    Vertex Group紐付けで存在。ただWeight0の無関係部位も全てずらっと存在している感じ。

  • マテリアルは存在はするが中身はない
    マテリアル、テクスチャ貼り付けは全て手動で行う必要有り。

Bos FBX Importer/Exporterの入手&インストール



サイトblenderfbx よりダウンロード。
※Win32/64専用なので注意

動作の為に UmConvも必要なのでダウンロード。
同梱Readme_jaにBlenderへのインストール方法明記有り。

Bos FBX Importer/Exporter はBlenderのプラグイン形式。
UmConvは手動でBlenderのインストールフォルダにコピーする必要があるので注意。

 

その他メモ

  •  メッシュとボーンの紐付けはVertex Group
    Blenderではよくあるパターンなのでわかりやすい
    • Blender上ではVertex GroupでWeightエリア名とメッシュを関連付け
      メッシュ修正後は適当に該当するVertex GroupにAssignすれば良い。
      ※Assign漏れがあると、Unity上でそこだけ尖ったりおかしくなる。
       そういう場合はまずVertex GroupでAssign漏れを疑ってみる。

       
    • Unity上のHumanoid~ConfigでWeightエリア名とボーンを関連付け
      既存UnityChanモデルから読み込み&コピーで関連付け完了できる。
      → 楽ちん。

      既存UnityChanモデルから読み込みではうまくいかない。
      Create From This Model で生成でうまくいった。
       
  • 頭部連動の目、眉などがボーンの階層構造に無い
    Blenderでエクスポート、Unityにインポート後、目、眉などはボーンとの親子関係位置の手動調整要。※EYE_DEFとかEL_DEFとか。
    (一度インポート&位置調整&プレハブ化、以後FBX更新毎での調整作業を回避)
    手足アニメにのみなら関係なし。
    表情のShapeアニメは同梱Animator、スクリプトのままでは動かせず。

     
  • 手動で階層構造調整
    Unityへインポート後、Character1_Reference や root_mesh の階層構造が無い。
    手動で GameObject追加、リネーム。既存Unityちゃんと同じ階層構造になるように手動調整。
    → 既存UnityChanと互換を保ちつつ、BlenderでExportが現状困難そうな予感。
     
  • Blender上でアニメーションを作る用途だと自前で適当にWeight付けが必要。
    手足など基本部位のみで良ければ元Weight利用で。
    Rigfy有効化、AutoWeightで概ねなんとかなるかも?→Autoのみではきつい。面倒。
    簡単なアニメーション作成くらいなら、UnityChanに似た体型の手持ちのアバターを使った方が早いという考えも。
     
  • マテリアル名
    BlenderからBos FBXでエクスポート、Unityでインポートした際、マテリアル名はBlenderで扱っているテクスチャのファイル名になる。
    ※Blender上のマテリアル名でも、テクスチャイメージ名でもなく、実ファイル名
    UnityChanのマテリアル名と一致しなくなる為、いろいろと面倒なことになる。

    テクスチャのファイル名を書き換えると一見回避できるが、複数マテリアルで1テクスチャを使用しているのでやっぱり破綻する。

    どのみち初回はテクスチャを手動設定しなけばならないので、そこでやるしかない様子。(微妙に苦行)

テストで少しメッシュを修正、Unityにインポート、UnityChan同梱のデモスクリプトで動かしてみた。
  • 各種ポーズ → OK
  • 目パチ → OK
  • 髪 → 現状ポーズに連動せず、動かない → 現状の課題
  • 目の視線移動 → 未確認。もともと無いようだ。
原本では二の腕、脇下等々が服下にあり、低コスト化でメッシュが存在しない。
とりあえず適当にメッシュ処理したので激しい動きでは破綻する部分が。

まじめに動かすにはもっと丁寧にメッシュ修正作業をする必要がありそう。




追記:
UnityChan を BlenderでImport、メッシュ加工&Exportでいろいろ試行。
(Mayaを使えばいろいろ幸せな気が・・・する; 学生なら無料版が使えますね今は)

  • 手足アニメーション(ポーズ)
    Armatureによるアニメーション(髪は含まず=Humanoid型の範囲外?)。
    Blender上で Import(Bos FBX)、メッシュ加工、Export(Bos FBX)で普通に作業可。
    メッシュ~ArmatureアサインはVertex Group。
    髪、顔アニメが必要なければ配布物(スクリプト、アニメ等)との互換動作の確保も容易。
     
  • 顔のモーフ
    Shape制御(口、眉、まぶた)。
    BlenderでImport/Export(Bos FBX)は一応できてる。できてるがオリジナルとは若干異なるデータ階層(?)になってしまうのか、配布物のAnimator、スクリプトそのままでは制御不能(メカニム経由)。
    Shapeデータ自体はUnity上に一応Importされてる。自前でスクリプトを書いて制御すれば一通り顔アニメは制御可能(Legacy的な制御?)。
    → メカニム経由での制御がまだうまくいってない(要追試)。
     
  • 髪のアニメーション
    既存アニメーションでの髪アニメはとりあえず断念。
    配布物のアニメーションを利用しようと試みたが、
    • Humanoid型でCreate From This Model で生成すると、
      手足の基本アニメは動く。髪は動かない。
    • 既存UnityChanのModelのAvatar読込&プレハブ上でデータ階層再配置
      髪は一応動く。手足はめちゃくちゃに崩れる。
    BlenderでExportすると髪ボーンの階層がズレる(?)のか、そもそも既存アニメと互換がなくなるような感じ。Unity上でHumanoid型で生成すると基本部分だけは互換が取れてるような感じ?
    (多分・・・Mayaなら問題なくできるんじゃないかと妄想)。
     
  • 髪の揺れモノ駆動
    Vet1.2からダイナミックUnityChanが同梱。
    「揺れモノ」制御のスクリプト類が付属。
    添付Documentを見る感じ、これは使えそうな気がする(未テスト)。テスト済。現状この方式が最適解な気がします。
    シドニア的な何かを感じます(謎)。これは良い。
    ダイナミックUnityChanでは髪のボーンアニメは使ってないような気がする&かなり見栄えが良い。髪は揺れモノ駆動でいいかもしれない(ただし負荷は上がる)。
    Androidで実際ゲーム等に使える負荷レベルなのかはなんともいえない所。がんばればなんとかそれなりに動く。
    (負荷増分を他で削ればなんとかなるか?という妄想)

2014年7月1日火曜日

BlenderでExport~Unity Import時のメモ


Unity用にモデルをBlenderで作成して、Export、Importする際のメモ


縮尺とか向きとかすぐ忘れるのでまとめて書いておく。
(作業上絶対こうしなくてはいけないわけではないです。自分用メモです)

Blender側

モデリング

Blenderの長さ単位1mは、Unityの1mと想定してモデリングする。





  1. ScaleはXYZ全て1.0でロックしておく
    UnityではScale値がいろいろ関与してくるので1.0にロックしておくといろいろ幸せ。
    親子関係で複数Objectでモデルを構成しつつ、Unity内で子をスクリプト制御する際、Unityでは移動/拡大単位がScale値を乗じたものになる。スクリプトから制御時にやっかいなので1.0に固定するクセをつける。
    しかしあらゆるBlenderの編集機能から完全にロックしきれるわけではない。
    たまに油断すると変わっていたりするので注意(Object ModeでApplyするModifier等)。
    普通にEdit Modeにて頂点編集で拡大、縮小していればまず問題ない。
     
  2. 向きの確認はLocalで
    Objectの前後左右向きとXYZ軸向きの確認はLocalで見る。
     
  3. Blender上でのObjectの向き
    +Zを前
    +Xを左
    +Yを上
    としておく。
    FBX Export時の指定と関係してくるので、作業上こう決めておく。

Export形式

  • Collada
    BlenderのExpoterではアニメーションを複数同梱できなかった。
    Collada仕様上はできるらしい。
    他の3Dツールでも対応は少ないようなので、マイナーと思われる。
    単純なモデリングなら特に支障なく使える。
     
  • FBX
    複数アニメーションも同梱可能(確認済)
    Export対象も指定できたり、使いやすいと思われる。
    以降、UnityへのExportはFBX前提。

FBXでExport




  • Selected Object
    予め選択済みのObjectのみをExportする際チェック入れ。
    だいたいこれをよく使う。
     
  • Scale
    1.0にする。
    このScale値はUnity上のScale値の値になる。
     
  • Forward
    -Z Forward にする。
    ※前項で決めたBlender上でのObjectの向きと関連。
     
  • Up
    Y Up
    ※前項で決めたBlender上でのObjectの向きと関連。
     
  • Empty / Camera / Lamp / Armature / Mesh
    Meshにチェック入れ。
    アニメーションも同梱するような場合は、Armatureにもチェック入れ。
    他はチェック無し。(Camera、LampなどはExportすることは無いので)
     
  • Apply Modifier
    チェックを入れておく。
    各ModifierをApplyせずとも、結果をExportできるので便利。
    Modifier未使用でチェック入れても特に問題にはならない。

Unity側

Import



  •  Scale Factor
    0.5 とする。
    これでBlender上とUnity上でObjectサイズが整合。
 



  • Objectの向き
    Local軸で見る。
    FBX Export時に Forward/Upの指定しているので整合。
     
  •  Scale
    FBX Exportで 1.0 としたので1となる。







2014年6月23日月曜日

Spriteでテクスチャを回転

Unityでテクスチャをスプライトで回転させてみたメモ。


スプライトは2Dゲーム開発用かとおもいきや、
3Dでもスプライトは便利そう。


目的

  • テクスチャを回転させたい。
  • Object自体はできれば回さない。
  • スクリプトでテクスチャ切り替えは面倒。

→スプライトを使えば比較的楽にできそう。


テクスチャを用意


次のような円状のものをちょっとずつずらして回転したものを作成。
(地味に回転&再配置が面倒・・・)

アニメのコマは4x2の8枚。
黒部分はアルファレイヤで透過になります。


LockCursor.tga (1024x1024)


スプライト生成

  1. テクスチャ選択
  2. Inspector内のTexture Typeクリックしてプルダウン
  3. Spriteに変更する






  1. Spriteにしたら
  2. Sprite ModeをMultipleにする。※コマ数が複数あるので
  3. コマ数の分割を指定を行う為、Sprite Editorをクリック





  1. Sliceをクリック
  2. TypeをGridに。Pixel Sizeを256x256に指定。
    ※テクスチャが1024x1024なので縦横4分割とする
  3. Sliceをクリックして分割






今回は上半分に4x2=8コマの絵がある状態。
Slice後、下半分の絵が無いところにもコマとして確保される場合がある。

不要なコマ部分をクリック、DELキー押しで削除できる。
これで下半分の不要なコマを削除する。

一通りできたらApplyをクリックして変更を確定。Sliceウィンドウを閉じる。









スライスした絵が8枚できているので(LockCursor_0~7)
全て選択してHierarchyウィンドウにドラッグ&ドロップする。

保存ウィンドウがでるので、LockCursor.anim などとして保存。
(アニメーションのファイルとかMecanimの雛形が自動生成される)

するとHierarchyウィンドウ内に LockCursor_0 という名前でスライスしたものをまとめたものができる。
※これをAssetsウィンドウに再度ドラッグ&ドロップするとプレハブ化するので、スクリプトから動的生成もしやすい。








見やすいようにカメラの前付近に LockCursor_0 の位置を調整して、
UnityをPlayすると、LockCursor_0 はくるくる回りだす(スクリプト無し)。







アニメーションが8コマなので少々回転が荒い・・・。

Asset Storeをもっと活用すべきなのでしょうけど、いまいち使いきれてないな・・・うーむ。


2014年6月18日水曜日

アニメーション付メッシュをBlenderでExport, UnityでImport

アニメーションを付与したメッシュをBlenderでExport、UnityでImportする際のメモ。

目的

非人型形状のメッシュモデルをアニメーション駆動する。
(多間接な有機物や無機物等)




使用環境

Windows7x64
Unity 4.3.4.f1
Blender2.70a




Unityでインポートできる形式

ユーザーズマニュアルによると、
  • Maya(.mb、.ma)
  • Cinema 4D(.c4d)
  • Autodesk(.fbx)
などとある。
.bvh形式はUnityにドラッグ&ドロップにて読み込みはできたが、実際利用可能なのかは未確認。




メッシュモデルとアニメーションの作成

Blenderで作成。
Blender上でのモデルとアニメーションの作成方法については割愛。

サンプル用に簡単なドアのモデルを作成。
アニメーションはOpenとCloseの2つを作成。




メッシュとアニメーションのエクスポート

人型の場合はアニメーションを使いまわす可能性があるのでメッシュモデルから分離しておく方が有利なこともある。

非人型の有機物/無機物等の、あまりアニメーションの可搬性がない(そのメッシュ専用のアニメーション)モデルを今回は想定するので分離しないほうが都合が良さそうと考える。

今回はメッシュと複数アニメーションを同梱できる.fbx形式でExportした。
※ちなみにCollada形式では1つのアニメーションしか付与できなかった。
  1. Objectを選択状態にする。
  2. File > Export >  Autodesk FBX (.fbx)
  3. 各欄を設定してExport(Door.fbx とした)
    1. Selected Objects:
      選択したObjectのみをExport対象とする。
    2. Scale: 1.00
      サイズの整合はUnityのインポーター側で行うことにする。
    3. Forward: -Z Forward
      BlenderとUnityでのZ軸方向の違いを補正。
    4. Up: Y Up
      BlenderとUnityでのY軸方向の違いを補正。
    5. Armature/Mesh:
      メッシュとArmatureをExport対象に含める。(ArmatureはObjectとAnimationの関連付けに必要)
    6. Include Animation:
      アニメーションをExportに含める。




.blendファイルをUnityのAssetに置かない私的理由

今回のサンプルでは行っていないが、実際の作業ではノーマルマップを生成する都合上、ハイポリゴンモデルとローポリゴンモデルが1つの.blendファイルに含んでいる場合がある。
(作業上Bakeが楽な為)

この.blend ファイルをUnityのAssetに配置すると、ローポリモデルだけでなくハイポリモデルもUnityは読み込んでしまう。
これがうっとおしいので.fbxでエクスポート/インポートを試してみた。




Unityでfbxファイルをインポート

BlenderでExportした Door.fbx をUnityのAssetsにドラッグ&ドロップする。

アニメーション確認

アニメーション(Open/Close)もきちんとインポートされており、Inspector上で個々のアニメーション動作の確認ができる。



モデルサイズの整合性

しかしこのままではモデルの大きさが整合せず、非常に小さいサイズになってしまう。

Inspector内の Model > Scale Factor の値がデフォルトでは 0.01 となっている。
これを 0.5に修正して、Applyをクリックする。
これでBlender上での1.0単位とUnity上での1.0単位が整合する。
※BlenderからExportする際のScale値にも関係する。上記はそのScale値を 1.00 としている場合。
※追記:Blender側のObject自体のScale値も1.0に固定したほうが何かと良い。参考記事→「
Blenderでモデリング時のTransform Scale


アニメーションの設定

Inspector内の Rig > Animation Type をLegacyに変更してApply。
※Blenderで作成したアニメーションはLegacyに設定しないとダメらしい?。インポート時UnityのConsoleにてLegacyに設定しろとログが流れる。

これによりHierarchyにドラッグ&ドロップした際に自動的に Animationコンポーネントが追加された状態になる。
なお且つAnimationコンポーネントのAnimations欄に全アニメーションがElementsに自動登録されている。


※ちなみにテクスチャは別途Unityにドラッグ&ドロップして、手動で貼り付ける。
先にテクスチャを/Resource/Assets/Texture配下にインポートしてからfbxファイルをインポートすると自動的に貼ってくれたりする。
この辺は自動認識で貼らせる規則性等がUnityにはある様子なので利用すると少し楽ができる。




シーンにドアを配置

シーンにDoorを配置する。

この状態で Play実行すると Play Automatically に設定されているアニメーションが(スクリプトが無くても)自動起動する。







スクリプトからアニメーションを駆動

準備

スクリプトからのみアニメーションを制御するようにしてみる。
先のPlay実行時のアニメーション自動実行を止める為、Animation欄の Play Automaticallyのチェックをはずす。

スクリプト(C#)


関数 animation.Play() を使う。引数にアニメーション名を渡すだけ。


using UnityEngine;
using System.Collections;

public class DoorTest : MonoBehaviour {

    void Start () {
        animation.Play("Open");
    }
}

サンプル






上記サンプルプロジェクト保管庫(GitHub)
https://github.com/maruton/Sample_AramtureDoor

サイト右列下方の「Download ZIP」からダウンロード可能。
※Unity5化済み。




感想など

.fbx形式便利です。 (一応世間ではデファクトスタンダード?)

なんとなく過去のしがらみ(?)の都合上ColladaでExportすることが多かったのですが、複数アニメーションに関してはColladaではうまくいかず。
やはり.fbx形式を使うべきなのか。

ハイポリ/ローポリを.blendファイルに共存させる必要がなければ、.blendファイルをAssetsに放り込んでしまえばもっと楽かもしれない。

人型アバターのアニメーションが例としては多いが、無機物などでも結構使い道はあるかも?

※過去に別プラットフォームにて多段間接をクォータニング計算でスクリプト駆動したことがありますが、計算が面倒&誤差がでると目もあてられないので、アニメーションで実装は楽で良いと思います。