募集要項

  • ■ボイスの募集は終了しました。

    非常に沢山のご応募ありがとうございました!

     結果はこちら
2017年6月
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

« 2012年11月 | トップページ | 2013年1月 »

2012年12月

2012年12月22日 (土)

【Unity Tips】 噂?のDstAlphaを試してみた。

昨日のメガUnityユーザーミートアップ2013での
ライトニングセッションであった
「DstAlpha で広がる表現の世界」で紹介された、
「目と眉を髪の前に出す処理」を早速試してみました!

121222

前髪パッツンキャラなので効果が薄いですが、
まゆげとかが髪の上に表示されてるのが分かる...分かりますよね?(汗
アニメ調のキャラクターの場合はかなり有効そうですね!

と、言うだけだとアレなので、
参考までに簡単に自分の方で試した流れを記載しておきます。

①DstAlpha用のシェーダーを作成する
 アルファに対応したシェーダーであれば、
 どれでも改変を行って使えるとの事でしたので、
 NGUIに付属している「Unlit/Transparent Colored」
 を複製して使用しました。

 変えたところと言っても1点だけで、
 Blend SrcAlpha OneMinusSrcAlpha
 ↓
 Blend DstAlpha OneMinusDstAlpha

 のみです。
 あ、ZWrite OnだったのでここはOffにしました。

②顔のテクスチャのモデルより前に表示させたい部分をアルファ抜きにする
 
 ↓な感じです。
121222_2_3
 ※あと、他のテクスチャにアルファ有りのテクスチャがあると干渉したり
  するっぽいので注意です。

③前面に出すパーツのマテリアルを①で作成したシェーダーにする

④でけた!
 121222_3_3

ちなみに、alpha表示にすると
こんな感じになってます。

121222_4

お手軽にできる割に見た目の効果が高いですね!
え?処理負荷?・・・調べてないです(マテ
とはいえアルファなので軽くはないと思います。。。、

あ、あとシェーダー次第では優先具合が安定しなかったりしますね。
例えば、標準のライトに対応したアウトラインシェーダーだとダメでした。

それでは良いDstAlphaライフを!ヽ(´ー`)ノ

2012年12月19日 (水)

Mayaからのカメラアニメーション&FOVのインポート・ネオ ~番外篇~

本日TwitterでFovのMayaとUnityの違いについて助言を頂き、
調べた結果、ほぼ解決となったので、
情報共有の意味も含めて番外編として記載しておきます。

結論から言うと、Unityは垂直画角ベースなのに、
今までの算出方法は水平画角でやっていたことが原因
でした。

で、改めまして使用した計算式です。

Fov = 2.0 * atan((0.5 * verticalFilmAperture) / (focalLength * 0.03937)) * 57.29578

これで算出して出力、モーションを再生し、
MayaとUnityの画面を比較してみました。
※すべて同じ位置からのカメラで、画角&アスペクト比のみ変更した画像です。

121219_fov_2 

縦横比が変わっても、極端な画角でも大丈夫!
Unity側で補正掛けなくてもOKでした。

ただ、一つ注意点があります。
Maya上でのカメラも垂直画角ベースしないと、
解像度を変えた際に、見え方が変わってしまうので、
「解像度ゲートに適合」を垂直にしてからカメラに動きをつけるようにする事をお勧めします。

121219_fov2

いやぁ・・・分かり難いです、これ・・・。
上手く合わない理由はここでした・・・。
とりあえず何か合わないと思ったら
Mayaカメラの垂直アパーチャを疑いましょう。

改めまして情報ありがとうございました(´▽`)ノ

Mayaからのカメラアニメーション&FOVのインポート・ネオ ~後篇~

前篇からの続きです。
実は以前書いてたのものから、
Mayaからのカメラ出力に対して1点処理を追加してたので記載します。

内容としては、Unityの日本公式にある記事の、
「TIPS – アニメーションの補間を完全に切る」
http://japan.unity3d.com/blog/blog/2012/07/20/tips-animation-curves/

にも書かれている、複数のカットを繋げることによる回転値の問題
ちょっと気になってたので、
カットの切り替えフレームの情報の出力と反映もできるようにしてます。

上記記事では、カット切り替えのタイミングをキーとして設定し、
それを元にアニメーションの上書きする処理を行っています。

実際、カット数が少なければ手動で特に問題ないのですが、
3Dツールで作ったカット切り替えが多い場合、正直めんどくさ(略
・・・という事で何とか元データ(3Dツール上)の時点で解決できないか
と考えてみました。

で、どういった方法を取ったかですが、
出力処理と同時に、打たれているキー毎に接線情報を取得し、
Step接線だったら情報をその都度保存していく処理を行っています
(Step接線で)

つまり↓のようなモーションの場合、(※検証用に、1fじゃないstep接線も用意)121218_1

↓のようなアトリビュートが出力時に自動的に生成されます
121218_0

ここまでできればもう単純な話で
これまでのカメラの情報と併せて、
新しく生成したパラメータも同じアニメーションとして出力し、

Unity上で公式の記事のスクリプトを元に、
「enabled」で管理しているパラメータを
「生成したアトリビュート」を参照して動作するようにすれば
完成です!

・・・といきたい所だったのですが
実装した際に問題が発生しました  (ノд‐。)
カメラ関連の移動値等を合成した値をエクスプレッションで設定していた為、
出力時にベイクすると接線情報がリセットされるため、
ベイク後にstep接線を自動で再設定してから出力する事に。
※その前後フレームの接線も要調整。

おまけ(というか最大の問題)に、回転情報は接線情報を持って行けないようで、
前後のフレームの接線がConstantにならず、回転ががたつきます。

…なんてこったーヽ(`Д´)ノ
Unityさん…接線情報持ってってー ・゚・(つД`)・゚・
…と言っても始まらないので、解決方法を模索してみました。

で、どう解決するかですが、2点とりあえず考えました。

1:Unity側でスクリプトを使用して修正する
   回転のカット切り替えのフレームの接線をスクリプトでConstantに切り替える方法です。
   切り替えのタイミング自体は出力してあるので、それを参照すれば自動でいけるはず。
2:ザ・力技
   ここで問題になるのは、カット切り替えの前後1fのみなので、
   カット切り替えの前後1fも回転値を上書きしてしまえば変なフレームは入りません。

あ、「手動で接線を修正する」は効率がアレなので考慮してませんヽ(´ー`)ノ

で、自分がどうしたかと言うと、2番にしてます(汗
まぁ1/60フレームなら目立たないかなという安直な考えと、
変換スクリプトを作る手間の問題です (。・x・)ゝ手抜きジャナイヨ??
(そのうち変換するヤツもつくるかも。)

で、結局エクスポーター側をそれに合わせて調整しました。

と、まぁ色々と調整した挙句、なんとか持って行けた感じです。

ただ、クオリティ重視の拘りのカメラワークであれば、
ちゃんと接線を整えるシステムを作った方が良いかも
ですね。
あくまで手間が少ないやり方、と捉えて下さい。

以下に実験に使ったデータの動画も参考までに載せておきます。

■補正前(カット切り替えで変なフレームが見えると思います)


■補正後

…といっても作成中のゲームではカット切り替えが必要なシーンは現状想定してないのですが!(マテ

2012年12月18日 (火)

Mayaからのカメラアニメーション&FOVのインポート・ネオ ~前篇~

コメントにて要望があったのも踏まえて、
以前ブログに書きました、

Mayaからのカメラアニメーション&FOVのインポート

に関してもう少しだけ詳しく書いてみます。
(後で書くかもと言ってて忘れてた…)

まず、おさらいですが、Maya側から持っていくものですが、
・移動
・回転(ツイスト)
・Fov(というかAov)
・クリッピング(near/far)

になります。
で、Maya上でそれぞれどう求めているかですが、
--------------------------------------------------------------
・移動
 そのままですね。特に変な事はしてません。
 ただ、aimカメラにも対応するため、出力時は
 camera_groupと、cameraShapeの移動値を掛け合わしたものを
 参照するようにしています(aim無しの場合はShapeのみで算出)

・回転(ツイスト)
 こちらも普通に、Shape側の回転値を基本として参照しています。
 また、移動と同様に、camera_groupを動かしていた場合を想定し、
 camera_groupの値も加算した値を参照しています。

 ※12/20追記:(というか書き忘れ)
   カメラをMayaからUnityへ持って行く場合、向きが異なりますので、
   回転値に補正をかけて出力する必要があります。

・Fov(Aov)
 いわゆるビューアングルです。
 focal length(焦点距離)から計算した値を算出しています。
 計算式としてはいくつかあると思いますが、自分は以下で算出しています。

 2.0 * atan((0.5 * horizontalFilmAperture) / (focalLength * 0.03937)) * 57.29578

 これでAovと同じになるので、
 この値を出力時に参照します。

・クリッピング
 この値はShapeの値を直で参照しているだけです。
--------------------------------------------------------------
で、上記の値をエクスプレッションを使用して、
出力ノードに集約、ベイクしたデータをアニメーションとして出力しています。

ここまでできればあとはUnity側の処理ですが、
やること自体は前回の動画のままです。

で、スクリプトの中身ですが、
LateUpdateあたりでFov、Near、Farをアニメーションの値から参照して
実際のカメラのそれぞれの値に渡している処理が入っているだけです。
具体的には

MayaCamera.fieldOfView  = Camera.localScale.x *(UnityのFovとMayaのAovの補正値);
MayaCamera.far   = Camera.localScale.z *(モデルスケールに差異があれば倍率をかける);
MayaCamera.near  = Camera.localScale.y *(モデルスケールに差異があれば倍率をかける);

な感じですね。
また、確認しやすいように

[ExecuteInEditMode ()]

のフラグをスクリプトに足して、実行中以外でも見れるようにしてます。

尚、UnityのFovとMayaのAovの補正値に関しては、
正直未だにおおよその値で取っており、確実にこれだ!というものにはなってません。
誰か知ってる人いたら教えて下さい(汗

一旦ここまで。後編に続きます。
ちなみに、後編は需要あるか不明ですが
~追加した機能(複数カットの切り替え対応)~編です。

2012年12月 8日 (土)

いつのまにやら10万HIT

先ほどカウンターが10万超えてる事に気付きました!

3ヶ月くらい更新できてない間もあったのに有難い限りです (。・x・)ゝ
今後はあまりペースを落とさずに進めるはずなので、
たまに覗いて貰えると喜びます(≧∇≦)b

今作ってるゲームは……3月末くらいかなぁ…
個人製作だと、当然苦手なジャンルや、
やった事無い作業もしないとなので、四苦八苦する毎日です。
が、割とマジで勉強になります

基本的には企業だと
分業化が進んでる事もあって、自分の担当業務以外は覚える機会が少ないんですよね。
有る程度できるようになると管理業務に回されますし(笑)

そういった意味では、まだまだ微妙な部分も多いですが、
どんどん上達できるように頑張ります!

【Unity Action】 細かい進捗メモ

最近やった事とこれからやろうとしてる事メモ~

■最近やった事
 ・スキルアイコンの追加と、切り替え処理
 ・装備によって使用できるスキルが変わるシステム実装
  ※最終的にこの形にするかは要検討
 ・一部技にエフェクト追加
 ・Resources.UnloadUnusedAssets();のタイミングとかをちょっと見なおし
 ・ロード画面にNowLoading表記追加、ブラックアウトとは別タイミングでのフェード処理実装
  ※短いロードならローディング表示しないようにするかもしれない為。
 ・飛び道具生成スクリプトを、味方、敵とで共用できるように。
  ※追尾、直進、貫通等の飛び道具の特性も選択可能な形に。
 ・一部、ボタンを押しても反応が鈍いボタンがあったので修正
 ・操作感調整

■週末やる(予定)
 ・JoyPadの処理をもう少し使いやすく修正
 ・メニューのステージ選択の挙動修正
 ・ステージの順次開放処理
 ・ボススライムにモーション追加
 ・NGUIの表示優先度が一部おかしくなっている箇所修正
 ・メニューの各画面の構成物、レイアウト検討

言ってみれば、現在は試作中です。
量産したいし素材の作り込みしたい!(特にキャラ)
・・・まだまだ試作は長そう・・・(´ヘ`;)

何とか今月中に新たな進捗動画を上げる!
という感じで進めます。

2012年12月 3日 (月)

【ゲーム】購入したゲームと、やってるゲームと、買おうか悩んでるゲームとか

現在2回目の裁判まで行きました。
のんびりプレイします。
思ったより3Dなのは違和感無いですね。(多少はありますが
3Dにした事で色々と可能性を感じます。

個人的には逆転裁判好きで買ったので
現状レイトンのナゾ解き部分がやや蛇足な印象。。。

とはいえまだ前半なので今後次第!

継続プレイ中。
他作業しながらでもレベル上げできるのが有難い。
面白いかどうかは人次第。ドラクエなのに人を選びます(;´д`)ゞ
オンラインなので仕方ないですが…。

とりあえずは12月のアップデートまでは継続プレイ予定。
それ以後はアップデート内容次第で考えます。

後、個人的に某ゲームサイトで「メタルスライム討伐イベント」
の煽り具合が気になりました。。。確信犯かどうかは分かりませんが、
「残り4日」の数字なのに「残り3日」と書いたり、
そもそもドラクエ10のメタルスライムは数時間狩りして1回倒せればいい方なのに
βのイベント画像を張ったり…(大量にメタルスライムがいる画像)
 ※他の事やってる時間を考えると10時間に1匹レベルも普通にありえる

まぁ実際無理そうなのは事実ですが、変に誤解を招く表現を混ぜるのは
如何なものかと思います(´ヘ`;)

個人的にはむしろ「まだこんなに戦ってる人達いたんだ」という解釈をしてます。
社会人とかだと1日1匹も倒せない人がほとんどなので、
1日7万ペースで討伐数増えるのはすごいなぁ的な。
ちなみに自分はイベント中(多分)15時間以上は戦ってる気がしますが、
1匹しか倒せてません(´▽`*)狙えるもんじゃねぇー。完全運です。

と、ちょっと愚痴っぽくなりましたね、スミマセン。
なんだかんだ文句言いつつも楽しんではいる証拠でしょうか(汗

ちょっとやりたいけど、時間の問題で買うか悩み中。
なんだかんだでこのシリーズは良く出来てると思ってるので、期待値高いです。

2012年12月 2日 (日)

【Unity Tips】Unity4アニメーション負荷テスト? Legacy VS Generic

ゲーム用素材作っててちょっと気になったので、
以下の点を検証?してみました。

----------------------------------------------------------
・Unity4で「単体ループモーションしかしないオブジェクト」の場合
 FBXの設定を標準のGenericでAnimator Controller使ってやるより、
 Animation TypeをLegacyにして使った方が軽いんじゃないか?

----------------------------------------------------------

という点です。
で、↓がテストした環境のスクショ。(無駄に半透明…)

121202_2

GenericのAnimator Controllerの参照は1つのみで、全パーツ同じオブジェクトの複製です。
アニメーションさせたパーツ数は850個
短いループモーションを個別に設定して、FPSを比較しました。
※使用端末:NW-Z1050(Android2.3)

■結果:
 ①Legacy
   10~14FPS
 ②
Generic
   6~10FPS
 

・・・ナンダッテー!?・・・結構違いました。
Animator Controllerも1つしか使ってなくてこれだと、
全部に個別のAnimator Controller持たせたりするとさらに重い…?(検証メンドイので省略
結局の所、単純な制御のアニメーションはLegacyにした方が良いかもしれません。
単純な動きだけならLegacyの方が設定も楽ですし。

※あくまで数が多い場合なので、
 アニメーション制御数が少なければ大した差では無いとも見れますし、
 また、色々なバリエーションで試したわけではないので、
 状況によってさらに異なるかもしれません。

関係ないけど、NW-Z1050はAndroid 4.0にアップデートされるのか…

◆Z1000シリーズをAndroid 4.0に更新…12月中旬に提供
http://kakaku.com/item/K0000288664/feature/#tab

でも開発機としてみたらアップデートしない方がいいかもなぁ。悩む。

« 2012年11月 | トップページ | 2013年1月 »

Twitter等

  • にほんブログ村 ゲームブログ ゲーム制作へ

メールフォーム

  • 直接コンタクト取りたい方はこちらからどうぞ

サイト内検索
ココログ最強検索 by 暴想