!!!独り言日記 !![Shade 3D] 後から色補正（2014/05/30） Shade 3D Basicでも後から色補正できるようにスクリプト書いてみました。 {{ref_image shade_color_correction_script.jpg}} Python/JavaScript/AngularJSで連携使用。 ガンマと輝度（露出）の値を変更すると、リアルタイムでプレビューが更新されます。 変更後の結果を、イメージウィンドウ上を変えることなくファイルに保存可能になります。 もう少し調整してから、後々ソースごとアップ予定です。 !![Unity] AnimationClipのlengthの小数点が切り捨てられる？の解決編（2014/05/28） 今月日記に書いていた、AnimationClipのlengthでの取得値をandroid/iOSで見ると、 小数点以下が切り捨てられたような挙動をしていた件ですが、facebookのユーザー助け合い所で「Animator.GetCurrentAnimatorStateInfo(0).length」で回避できますよ、と教えてもらいました。 また、Unity 4.5ではこれ自身修正されているのを確認しました。 http://unity3d.com/unity/whats-new/unity-4.5 の「Mecanim Fixes」の「Fixed AnimationClip.Length always returning 1 for all player.」ですかね。 ということで、作ったアプリの動作をUnity 4.5で検証後、安全そうなら移行するようにします。 !!Unity 4.5（2014/05/27） EnglishページではすでにUnity 4.5がダウンロードできるようになりましたね。 こちらはまだ既存アプリ検証中なので使うとしても平行でだなぁ。 それ以前にまだ、Unity2DとAssetBundleが掘れてないです。2Dも今年中にチャレンジしておきたいところ。 !!人型キャラクタアニメーション（2014/05/26） 今はカミキリムシで説明してますが、実は5月中に人型キャラクタのモデリングとモーション付けを進めてました。 これは完成したら出そうと思ってますが、フェイシャルアニメーション込みのものになります。 まずは「ここまでできるよ」ってのを見せたほうが早いかと思いまして。 これについては、出来次第情報出すようにします。 !![Shade 3D] 続続・ウエイトペイント（2014/05/25） 結局、1ヶ月も間が空いてしまいました、すみません m(_ _)m。 ひさびさのShade 3Dでのウエイトペイントの続きです。 「Shade」と書いていたのですが今後は「Shade 3D」と書きます。 バージョン14あたりで3Dのカンムリが付くようになりましたのでそれにあわせて。 カミキリムシのウエイトペイントでのスキン調整でしたね。 *足（6本）を動かす *首を上下左右に動かす *腹をピクピクさせる の3つについて。 !足（6本）を動かす ウエイトペイントで表示すると、自動バインドでつけられたウエイト値は足の節にまたがって与えられているため、足が赤色一色になるように調整します。 {{ref_image shade_weight_paint_01_20140525.jpg}} これは、ウエイトペイントで「加算」にして、 *ウエイトを与えない部分はShift押しながら透視図でペイント、でウエイト値を消す処理を行う（青色にする） *ウエイトを与える部分は透視図でペイント、でウエイト値を1.0にする（赤色にする） だけです。透視図でぐりぐり動かして調整しましょう。 確認は、一度ウエイトペイントモードを抜けて足のボーンをブラウザで選択。 形状情報ウィンドウの「ボーンジョイント属性」のオイラー角を変えてみて変化を確認。 !首を上下左右に動かす この例では、首を動かすと自動バインドではうまくいかないのが分かりやすいです。 まずは、首のボーンをブラウザで選択して形状情報ウィンドウで「ボーンジョイント属性」のオイラー角を変えてどこが連動してしまうのか確認。 {{ref_image shade_weight_paint_02_20140525.jpg}} boneRoot-boneNeck0-boneHead、と連なるボーンのboneHeadを選択して回転して確認しました。 boneRootがキャラクタの中心となる開始ボーン、boneNeck0が首の付け根のボーン、 boneHeadが頭の付け根のボーン、としてます。 首を動かしただけなのに腹が動いてますね。 「boneNeck0」の動きで関係ないところが連動してしまってます。ここを調整しましょう。 boneRootの子としては、boneNeck0/boneWingCenter/boneBody/boneLegCenterの4つが存在するとします。 それぞれのウエイト値を見てみると、、、、。 {{ref_image shade_weight_paint_03_20140525.png}} 結構わけのわからない状態になってます。 ここで「boneNeck0」を見た際の、親と兄弟ボーンに注目します。 面倒ですのでまずはこうします。 「'''対象の、親のボーンに影響する頂点でのウエイト値をひとまず1.0で埋める'''」 ここでは、「boneNeck0」の親の「boneRoot」が動く際の影響を、関連する頂点すべてに与えます（対象頂点でのboneRootが影響するウエイト値を1.0にする）。 足と羽根についてはすでにウエイト値を割り当て済み（先月の日記参照）ですので、それ以外の頂点を選択。 頂点選択モードにして、ウエイトペイントに移行。 boneRootをリストより選択して、1.0でバケツボタンを押して塗りつぶし。 {{ref_image shade_weight_paint_04_20140525.png}} これで、ウエイトペイントモードから抜けて「boneNeck0」や「boneHead」を選択し、形状情報ウィンドウでボーンの角度を変更してみます。 ボーンは動くけどメッシュの頂点はついてこないですね。 次は、首から上の頂点（触覚や目玉含む）をすべて選択し、「boneNeck0」にウエイト値1.0で割り当てます。 {{ref_image shade_weight_paint_05_20140525.png}} これで「boneNeck0」が回転すれば首から上の頂点がついてきます。 首周りの滑らかでない変形はこの段階では無視してください。まだカクカクでＯＫ。 では、次は頭となる「boneHead」を選択して同様の作業を繰り返し、先端のボーンまで同じように対処していきます。 さて、「boneNeck0」と「boneHead」は親子関係になっているとして、 ここで首と頭の接合点部分が滑らかに変形するように調整します。 ウエイトペイントで、ある頂点のウエイト値が1.0になっている場合、 「その頂点のウエイト値を減らすと、親もしくは子ボーンでの影響を加算する」動きをとります。 ある頂点のウエイト値が0.0になっている場合、 「その頂点のウエイト値を加算すると、親もしくは子ボーンでの影響を減算する」動きをとります。 個々の頂点において、各ボーンが与えるウエイト値の合計は1.0になります。 ウエイトペイントモードに移行し、「boneHead」をリストより選択。 首と頭は、先ほどの塗りつぶしで0.0または1.0のウエイト値が与えられているため、 首周りの青色のところをチョチョっとタッチして若干黄色になるようにします。 ウエイト値は0.1くらいを指定。 影響範囲円が大きい場合は、マウス右ドラッグで範囲を変更してください。 {{ref_image shade_weight_paint_06_20140525.png}} ウエイトペイントモードから抜けて、「boneHead」を選択して 形状情報ウィンドウでボーンの角度を変更。滑らかに変形できました。 {{ref_image shade_weight_paint_07_20140525.png}} こんな感じで、頭から上の触覚やあごのハサミまで調整していきます。 今までをまとめると、 *対象ボーンの親ボーンが影響するメッシュの頂点を選択して、ウエイト値1.0で塗りつぶし *その子ボーンの影響するメッシュの頂点を選択して、ウエイト値1.0で塗りつぶし *さらにその子ボーンの影響するメッシュの頂点を選択して、同様に先端まで *個々のボーンの関節部分でのウエイト値を微調整。スキン変形を滑らかに！ !腹をピクピクさせる 後は、今までの応用。 {{ref_image shade_weight_paint_08_20140525.png}} boneRootから、boneBody-boneHipとボーンが割り当てられています。 今、boneRootによる影響は、腹の部分の頂点では1.0になってますので、 *腹の後ろ半分を選択。 *ウエイトペイントモードに移行し、boneBodyを選択。 *ウエイト値1.0にして塗りつぶす *一度ウエイトペイントモードを抜けて、羽根の面を選択して非表示にする（形状編集モードにて） *改めてウエイトペイントモードに移行し、boneBodyを選択した状態で腹の中央部分のウエイト値を0.5付近になるように調整 {{ref_image shade_weight_paint_09_20140525.png}} これで、boneBodyのボーンを選択して回転させると、腹のメッシュの変形は滑らかになってるのを確認できます。 ウエイトペイントについては、これでひとまず完了です。9割以上は自動バインドとウエイトペイントで処理できるかと思います。 これでもどうもスキン変形がうまくいかない、という場合は最終手段としてスキンのテーブルを見てみましょう。 気になるメッシュの頂点を選択してから、それがどのボーンの影響を受けているか見ます。 ここで、本来影響してはいけないボーンのウエイト値が微妙に入っている場合もあるかもしれません。 ウエイトペイント操作自身は、個々の頂点にて、 対象のボーンとその親または子のウエイト値による影響を増減する処理を行うため、 意識せずに隣に微妙に影響が「漏れる」ような操作をしてしまう、、、かも。 最終的には、個々のボーンを選択して回転させてみて、思い通りの変形になってるかチェックしていくとよいと思います。 この作業中に、オブジェクトモード/形状編集モードで ボーンのマニピュレータを選択して回転または移動、などは 決して行わないようにしてください。 ここでのボーンによる回転での変形確認は、ジョイントモードもしくは 形状情報ウィンドウのボーンジョイント属性での回転で操作し、 確認が終わったら0.0に戻すようにします。 スキン変形の調整中は、ボーン構成や位置はすでに決定されていて 「そのボーンが回転したらいかにポリゴンメッシュが変形でついてくるか」に注力します。 地道な作業ですが、 *自動バインドで、超大雑把にウエイト値を割り当て （はじめの1回のみ） *ウエイトペイントで不正な変形を詰めていく （大部分はこの作業） *最終手段は、スキンのテーブルで数値調整 （最終的な調整。しなくていい場合も多い） の3段階でスキンの割り当てを収束させるようにします。 ということで、スキンの指定についてはこれまで。 次は動きのパターンについて。fbxでのモーション付きデータの出力と、UnityでのMecanimにも入っていきます。 !!Python（2014/05/22） まだ試行錯誤中ですが、Shade 3DでPythonを使ってWidgets（WebブラウザのJavaScriptと思っていただければ）の実装をすると、おそらくプラグイン以上のことができる手ごたえが。 色補正をShade 3D Basicレベルでも後から変更できてほしいため、Python/Widgetsの勉強もかねて実験君で作ってみることにしました。 後、GitHubを試してみたいというもくろみも。 嗚呼、またアニメーション解説が遠ざかっている、、、。 !!Oculus Rift DK2を注文（2014/05/15） PC上で動画を見てもよく分からないけど、実際試してみるとすごく没入感があってびっくりする Oculus RiftのDK2をご本家サイトから注文。 でも、まだ出荷されてないので夏ごろまで数ヶ月待ちですねぇ。 実際は数週間前に注文したのだけど、これらのコミュニティってどこにあるのだろう？ http://www.moguragames.com/entry/oculus3 によると、 https://share.oculusvr.com/ に公式の一覧があるんですね。 楽しみに機材が届くのを待っておこう、その前にモノはないのにSDKをダウンロード。 先にいろいろいじっておきたいところ。 !!ツボの元ネタ（2014/05/14） 説明いれようとして忘れてました。今回は歴史の話題。 最近日記でよく出している「壷」ですが、実はある元ネタがあります。 というのを本日、東京国立博物館の展示を見ていて思い出しました。 {{ref_image tubo_20140514.jpg}} 壷の模様自身はSAIで描いています。といっても、歴史ある陶磁器はこんなちゃちい絵/模様ではないわけですが(^_^;; 「伊万里」（伊万里焼）という陶磁器の種類がありまして。これは有田から伊万里という港を経由して出荷されたもの、だそうです。有田は「有田焼」で有名ですね。 特徴としては白地に青をベースとし、時代とともにだんだん模様の彩色が豊かになっていきます。 そのうち、乳白色の素地の上に彩色を施す色絵磁器が出てきて「柿右衛門様式」というのが確立していきます。 この時代（江戸）のお皿とか見ると「ああ、この感じか」と思うのがあるかも。 その柿右衛門「風」なのを目指してみました。 東京国立博物館では「伊万里(柿右衛門様式)」というのがいくつかありますので、見てみるのもよいかもしれません。 なお、柿右衛門さんは世襲制で、現代でも子孫の方が陶磁器を作り続けておられるようです。 !![Unity] 続続・AnimationClipのlengthの小数点が切り捨てられる？（2014/05/13） 解決（というか回避策発見）したかもしれない。 アニメーション設定を行ったInspectorウィンドウのAnimationsの一番下に「Events」というのがあります。 ここの一番最後の1.0の位置にダミーイベントを追加。 当然ながら、割り当てるスクリプトとコールバック関数は記載する必要があります。中身はカラでいいです。 {{ref_image unity_animation_length.png}} これを指定することで「AnimationClip.length」を取得すると、モバイル実行時/exe実行時に整数値が取得されて小数部が切り捨てられてしまう問題は回避できるようでした。 !![Unity] 続・AnimationClipのlengthの小数点が切り捨てられる？（2014/05/13） む〜、解決策が思いつかないぞ。 他の方も試されているように、モーションの長さの取得はあきらめてスクリプト内で決めうち。fbxを出力する前に30fpsだと60/90/120 frameなどの割り切れるフレーム数にする、で調整するしかないだろうか。 追記： いろいろいじってたら、android実機でも何かの拍子でlengthが正しく取得できるようになりました。 再現手順を詰めてみます。 !![Unity] AnimationClipのlengthの小数点が切り捨てられる？（2014/05/13） facebookの「Unityユーザー助け合い所」で投稿があってこちらでも再現したので調査中。 こちらで作ったアプリでもおそらくこれが原因で、想定の動きと微妙に異なるため気になって仕方ない部分です(^_^;; モーション付きのfbxを作成。30fpsのモーションのうち50frame(0-49frame)くらいの長さにして保存するとします。Shade 3Dで作成しました。 これは、Unityに持っていくと1周期が49/30 = 1.6333/秒の長さになりますね。 *Unity側で作成したfbxをProjectにインポート *Animator Controllerを新規作成 *Animatorウィンドウを表示 *Projectにて、fbxを開いてMotionのClipをAnimatorウィンドウにドラッグ。これをデフォルトのモーションにする（右クリックで「Set As Default」を指定） *シーンにモーション付きの形状（fbx）をドラッグ *シーンにドラッグしたモーション付きの形状に、Animator Controllerをドラッグして割り当て *以下のスクリプトを作成（ShowAnimInfo.cs）してComponentとして割り当て。 using UnityEngine; using System.Collections; public class ShowAnimInfo : MonoBehaviour { private Animator m_animator; void Start () { m_animator = this.gameObject.GetComponent(); } void OnGUI() { if (m_animator != null) { for (int i = 0; i < m_animator.layerCount; i++) { AnimationInfo [] info = m_animator.GetCurrentAnimationClipState(i); for (int j = 0; j < info.Length; j++) { GUILayout.Label((i).ToString() + " : AnimationClip.length = " + info[j].clip.length); } } } } } これをPC(Unity Editor上)実行すると、最終フレームが49の場合は49/30 = 1.6333が左上に表示されます。 ところが、Android実機に持っていって実行すると1が表示されました。 あ、Windowsでexe出力して実行しても1になりますね。 動きについてもEditor上とそれ以外では少し挙動が異なるように感じるため、なぜこうなるのか調査中。 Animator Controllerを使わない「Legacy」のアニメーションの場合はこれが再現しないので、fbxでの問題じゃない気がしてます。Unityのバグ？ !![Shade] 続続続続・めざせフォトリアルレンダリング（2014/05/08） 「リニアワークフロー」のShadeでの概念図を書いてみました。 {{ref_image shade_gamma_20140508.png}} レンダリングのガンマ補正をかけた最終的なツボの模様が、オリジナルのテクスチャと同じ色合いになってるのに注目。 これは何をしているのかというと、今ディスプレイで見ている *色 *テクスチャ については、モニタでちょうどよい色合いになっている「ガンマ補正がすでにかかったもの」になります。写真撮影したjpeg画像もすでにガンマ補正がかかってます。 補正値は2.2を使う場合が多いです（モニタでのガンマ値）。 フォトリアルではこのままでは正しく扱えず、いったんレンダリング前にガンマ補正をかける前の状態に近似的に戻す必要があります。これが「リニア」な状態といえます。 色をRGB(0.0, 0.0, 0.0) 〜 (1.0, 1.0, 1.0)としたときに、 入力時は「RGB値を2.2乗する」ことでリニアになります。真っ赤の場合は(1.0, 0.0, 0.0)なのでこれはガンマ補正前も後も同じ値です。 レンダリングはこのすべてがリニアな色（輝度）情報で計算を行い、レンダリング後にガンマ補正をかける（RGB値を (1/2.2) = 0.4545 乗する）ことでフォトリアルな色具合になります。Shadeでは「色補正」ウィンドウでガンマ値を指定できます。 これらのガンマ逆補正やリニアな空間での計算、最終的にガンマ補正をかけてモニタに表示する色合いにする、といった流れが「リニアワークフロー」と呼ばれます。 こういう処理は、Shadeに限らず3DCGでは同じ工程があるかと思います。 Unityではlightmapとかこのへん自動化してるかも。 本日記に書いているフォトリアルな画像は、全部この処理を行ったものです。 これを理解するだけで、ぜんぜんリアルさは変わりますよ（マニュアルに書いてましたっけ）。 !![Shade] 続続続・めざせフォトリアルレンダリング（2014/05/07） {{ref_image wood_house_03_201407.jpg}} *Shade 3D 14.1.0 *Windows 7 Home Premium/Intel Core i5-2500 CPU 3.30GHz (4 core)/Mem 4GB *光源なし、背景hdrによるIBLのみ *パストレーシング（'''イラディアンスキャッシュ使用'''） *レイトレーシングの画質 300 で、44分47秒。 やはり、イラディアンスキャッシュを使うと速いですね。 質感としてはジャリジャリしたのが好きなのでそれらは平坦になり補間されますが、室内でも十分効力を発揮しそうです。 パラメータをもっとつめれば、さらなる速度アップ/品質アップはできそうではあります。 さて、ここからです、汚れをつけていきましょう。 先にリニアワークフローについて書いたほうがいいような気がしてきたので、そこらへん後々書くようにします。 と、その前に、週一回の予定のアニメーション関連を、、、、。 !!Substance Painterで汚れをつける（2014/05/06） 既存のポリゴンメッシュ形状に対してSubstance Painterで汚れを付ける、という場合に ポリゴンメッシュに割り当てたUVに対して3Dペイントするため、 面ごとのUVをすでに使いまわしてるとなかなか汚れをつけにくいです。 ということで、オリジナルの形状からうっすら面を浮かしたポリゴンメッシュを別途作成。 ここに、汚れ用に極力面がかぶらないようにUVを開いた状態で配置。 これをSubstance Painterに持っていって汚れを加えることにしました。 {{ref_image substance_painter_20140506.jpg}} 上画像の左がSubstance Painterの3Dビュー、右がUVビュー。 UVビューで一部面が出てないのはたぶんSubstance Painterのバグ（まだ、Open Bataなので）。 Unityのデモプロジェクトでも、汚れ用のMeshを別途配置というテクニックは使ってましたので、それをまねています。 これでなんとかなりそうだけど、形状ごとにUVを新たに割り当ててというのは手間がかかりますねぇ。特に家/建築物の場合はどうしようか。 なお、1つのポリゴンメッシュに対して、2つのUVを割り当ててfbx出力し、 これをSubstance Painterで処理できるか試したのですが、2つめのUVはSubstance Painterが認識してくれませんね。 !![Shade] 続続・めざせフォトリアルレンダリング（2014/05/06） 完全に趣味の視点でのレンダリングですが、閉じられた部屋に窓や入り口から光が差し込んでくる感じが好きなのでそれをレンダリング。 {{ref_image wood_house_01_20140505.jpg}} *Shade 3D 14.1.0 *Windows 7 Home Premium/Intel Core i5-2500 CPU 3.30GHz (4 core)/Mem 4GB *光源なし、背景hdrによるIBLのみ *パストレーシング（イラディアンスキャッシュなし） *レイトレーシングの画質 1500 で、7時間32分。 こういった昔の日本の建物の雰囲気を現実で味わうには、東京近辺なら *川崎市立日本民家園 (神奈川県川崎市) *江戸東京博物館（東京都墨田区） *江戸東京たてもの園 (東京都小金井市) などがいいですよ。全部行きました。実際にものを見ないと分からないのもありますので、歴史好きならぜひ。 日本民家園は、そのまんまこんな感じの雰囲気です。 !!Steamにはいいツールが転がってる（2014/05/05） Bitmap2MaterialやSubstance Painterのような個人的に重宝してるツールは、Steamにあったりします。 Bitmap2MaterialはUnityのAsset Storeで半額セール時に購入したのですが、Steamでも買えます。 Steamのストアで「ソフトウェア」を選択すると買うことが出来るツールが一覧できます。 {{ref_image steam_20140505.jpg}} 小さなソフトハウスのものと思われる製品でも、こりゃ使える！というのも転がってますし、半額セールなんて安くなるタイミングもありますので、定期的にチェックしてほしいときに買う、となるとなかなか悦に浸れますよ。 ゲームをSteamで購入すると安いのを片っ端から買ってしまおうか、とつい散財してしまって「積みゲー」化してしまうというワナに陥るわけですが(^_^;; 最近はAutodeskのMaya LTもSteamに参戦開始してます。 ただ、出てきた当初は結構Steamユーザーの辛口意見で、、とここは自重。 法線マップが作りたいのなら「MindTex」ってのも安くてよさそう。 2Dだと「Black Ink」というのも気になる、、、。 モデリングのツールや2Dペイントのツールもあったりで、安いツールを使って素材を作る、というのにはSteamがおススメです。ステマじゃないぞ、私が勝手に盛り上がって紹介してるだけ。 !![Shade] 続・めざせフォトリアルレンダリング（2014/05/05） まずはテスト的に室内のレンダリング。 ↓パストレーシング（イラディアンスキャッシュなし） {{ref_image wood_house_20140505.jpg}} *光源なし、背景のhdrでのIBLのみ *レイトレーシングの画質 1000 室内だとまだまだこれでもサンプリング数が足りないですね。jpegにするとつぶれるので見えにくいですが、天井部分の暗い箇所に高周波ノイズが。 ここに見えているテクスチャは、実は実際の家屋のものではなくて、 公園などにある柱だったり看板の木材だったりします。 それらの素材はiPhoneで撮影したもの。 1軒の木造の建物は、どの木材を取ってみても同じものはないとは思いますが（木目がそれぞれ異なるので）、上記画像の家屋の場合はもともとUnityでゲーム用素材として用意したものあるのでかなり省略して作ってます。 上記レンダリング画像で見える部分としては、木材は512x512 pixelのテクスチャ1枚、右上に若干見えている茅葺屋根の512x512 pixelのテクスチャ1枚のみ使用。 合計で2マテリアル（Shadeではマスターサーフェス）を使用してます。 木材の多様感は、UVを微妙にずらしたりで表現してます。 で、木の素材（テクスチャ）を作成する際に分かったこととして「'''木材はタイリングで利用しようとしない'''」というのがありました。 木素材ですので、年輪などの特徴的な模様が付いてたりします。 木素材をBitmap2Materialでタイリングできるように補間して試してもみたのですが、繰り返しが目立ってしまい木材っぽさが失われてしまいました。 最終的には、1枚の512x512 pixelのテクスチャ画像に5種くらいの木材を押し込んでしまう、これが有効でした。 {{ref_image wood_house_02_20140505.jpg}} こうすることで、建物だけでなく木材表現を行う道具はなんでもこれだけでたいだい片付いてしまったりします。 これを個人的に「'''万能木材テクスチャ'''」と位置づけて使用してます。 これだと、マテリアルは1つで省エネですし。 なお、法線マップも使ってますが、これはBitmap2Materialで生成してます。 が、木材の場合は凸凹の高さは抑え気味のほうがよいかと思います。 !まとめ *木のテクスチャはiPhoneなどで撮影して用意しよう。街中で木っぽいのをいくつか撮影してストックすればOK！ *木はタイリング加工しないほうがよいかも。 *凸凹表現は、Bitmap2Materialで法線マップとして出力した画像を使用 !![Unity] NGUIとユニティちゃんの干渉を回避（2014/05/05） これは実験していて気づいたのですがNGUIとユニティちゃんを共存させようとすると、 NGUIのビューとしてユニティちゃんが貼りつくので「あれっ？」となりますね。 NGUIはUser Layerの空いている始め(User Layer 8、8のUser Layer名が指定されていれば9)のものを使用していて、これを使ってカメラでの表示のマスクを行っています。一方、ユニティちゃんのほうもUser Layer 8を使用してます。 これが干渉するみたいなのです。 であるので、Inspectorを開いてLayerのドロップダウンより「Add Layer」を選択。 User Layer 8を「NGUI」、User Layer 9を「UnityChan」と入力。 {{ref_image unity_01_20140505.png}} ここでメインメニューの「NGUI」-「Create」-「2D UI」で「UI Root」をシーン階層に作成。 「/UI Root」のInspectorで右上のLayerが「NGUI」になっているのを確認します。 なってなければ選択しなおしてください。 「/UI Root/Camera」のInspectorで「Culling Mask」がNGUIになっているのを確認します。 この後、UnityChan/Prefabs/for Locomotionより「unitychan」をシーン階層にドラッグ。 この段階ではゲーム画面では以下のようになってしまってます。 {{ref_image unity_02_20140505.png}} unitychanのInspectorで、LayerをUnityChan(User Layer 9)に切り替え。 これで以下のように正しい配置になりました。 {{ref_image unity_03_20140505.png}} !![Shade] めざせフォトリアルレンダリング（2014/05/05） 某所ではちょくちょくテストレンダリングして公開してたのですが、GW中に、もうちとまじめにやりまする。 ↓ とりあえず小物を配置しただけ。ただ、これはテスト用なのでボツ。 {{ref_image items_20140403.jpg}} 光源は無し、背景のHDRのみでパストレーシング（イラディアンスキャッシュ無し）です。 あらゆる手段を使ってできるだけ本物っぽくする、ってのを短期間の小ネタ的にやってみます。 使う予定の道具/ツール達は以下。 *iPhone 5s（テクスチャの撮影） *Shade 3D（モデリング、レンダリング） *Bitmap2Material（テクスチャのタイリング加工、法線マップ生成） *Substance Painter （3Dモデルに汚れをつける） *SAI (テクスチャの調整など) *PhotoShop Elements （全体的な色調の微調整など） 「iPhone 5s」以外は、1万円くらいかそれより安いツール達です。 Shade 3DはBasicで十分（と言うと怒られそうだけど(^_^;;）。 !!KADAN Ver1.0.1の修正点（2014/05/03） androidのカジュアルゲーム「KADAN」を1.0.1にバージョンアップしました。 2014/05/03の00:31段階ではまだ更新されてませんが、しばらくするとGoogle Playで更新されると思います。 http://www.ft-lab.jp/KADAN/index.html の「更新履歴」にて変更点を記載。 主にクラッシュする場合があった致命的な問題を修正しました。 技術的な点で何を修正したのか記載します。たぶん、同じ部分ではまる方もいらっしゃると思うので。 Unity 4.3.4 + NGUI 3.4.8(3.0.9 f7)で確認。 NGUIはバージョンによって挙動が変わることがあるので注意。 それもあって、テストの都合もあり、 今はこのバージョンでNGUIのバージョンアップを止めてます。 バージョンが上がると直っているかもしれません。 NGUIにて、ButtonクリックやTweenの終了感知をコールバック関数として指定することができます。 このコールバック関数が呼ばれるタイミングが、Start関数が終了した後で呼ばれるのだろうと思っていたのですが、その前に呼ばれることもあるようでした。 これは、Android SDKのエミュレータ環境の'''ものすごい遅い実行'''である場所では頻発、ある場所ではごくごくまれに発生してました。 不定期に起きていたのもある点に注意（気づかない場合も）。 Start関数が終わっていることを前提にNGUIのコールバックを呼ぶ実装にしている場合、nullチェックをしておらずにクラッシュするということがありえるかもしれません。 挙動としては、NGUIとして割り当てたコールバック関数を呼ぶタイミングでないのに（押してないはずのプッシュボタンのClickイベントとか）特定のコールバックがなぜか '''Start関数が呼ばれる前に呼ばれてしまう'''、というものでした。 というか、私自身そうなってました。 アプリを作る方はこのあたりの挙動は注意したほうがよさそうです。 '''Start関数が完全に処理しきったのを待って、イベントのコールバックに入るように判定する'''。boolでフラグ判定して、Start関数がまだ呼ばれてない場合はすべてのコールバック関数は問答無用でreturnするなど。 !!アイコンはこうして作った（2014/05/02） アプリを作ったときのちょっとしたTipsを記載。 プログラムじゃなくてデザインについてです。 アプリ「KADAN」( http://www.ft-lab.jp/KADAN/index.html )では、全体的に色の統一感とデザインの統一感も（一応）考えて作ってたりします。ここのちょっとしたこだわりなどを。 !色の配置 ベースになっているのは「日本画」で使われる岩絵具の代表的な色を使ってます。 絵についてはSAIで描いてるのですが、ここのカラーにはテンプレート的にその色を登録してます。 全体的に淡い色合いが多いのですが、白と黒色だけは例外です。これは強調の意味で使ってます。白は真っ白でなくて「胡粉」という少し濁りのある色を使ってます。 !レイヤ構成で作成 {{ref_image app_icon_02_20140502.jpg}} SAIではレイヤとして、普通にペイントするものと「ペン入れ」というベクターデータ（直線またはスプライン曲線）で描けるレイヤが存在します。 これを重ねていって1枚のアイコンにしていってます。 !下書き 下書きはShadeで3Dで作成してます。普通にレイトレでレンダリングして画像出力。SAIの一番下のレイヤに。これは単なるアタリではあります。 アイコンの下書きにする前に。この例では斧と丸太がありますが、わざとパースが揃わないようにしてます。 これは個人的な言い訳で、アイコンとして見た場合に2つの別々なものが強調されるようにしたかったのと、たとえば日本画の代表的な「浮世絵」って、当時(18世紀ごろ)はまだ一点透視図法とか二点透視図法とか整ってない時代なんです。西洋美術をようやく見よう見真似で取り入れてみた、というのがちらほらとある時代。北斎とかの時代です。 なので、ぱっと見で不安定な感じがする。それをインスパイアしたかったというのがあります。 ちなみに一点透視図を使った作品が出始めたころ、流行りになってどの作品も奥行きがある似たような感じになった、ってのもあったそうです。 というウンチクは、東京の「太田記念美術館」というのを見にいって仕入れました。 と、話が反れてしまいました。 後、パースをしっかりさせた場合に重心が出来てしまうとつまらないというのもありました。 !輪郭線 この上に「ペン入れ」で輪郭を描き、わざと周囲を黒く太くしてます。 ここは故意に強調するくらい太い線のほうがいい感じではありました。アイコンとして引き締まった感が出ますので。 !塗り できるだけ淡いムラを出すように、岩絵具で表現できそうな色合いを使ってます。 これで統一感を。 ということで以下のようなレイヤになってます。 {{ref_image app_icon_01_20140502.png}} はじめはアイコンもすべて3Dだけで表現できないか試したのですが、どうしても自分の好みに合わず、結局「描く」のが一番いいかなという結論に。 日本画をインスパイアしてるのは、単に自分の趣味です(^_^;; !!ft-lab.jp用の日記（2014/05/01） http://ft-lab.sblo.jp/ にて、主にアプリについての情報をブログとして書いていくことにします。 技術的な解説については、今までどおりここの独り言日記で書いていきます。 !![Unity] Photon PUN+購入（2014/05/01） Photon CloudのUnityでのAssetである「Photon PUN+」を購入し、試してみました。 モバイル（android）でもラグはないですね、こりゃいろいろできそう。 まだまだ理解できていない部分が多いのですが、だいぶ作法がわかってきました。 http://ft-lab.ne.jp/cgi-bin-unity/wiki.cgi?page=unity_photon_cloud に、自身が使う情報を随時書き溜めていってます。 とりあえず約一ヶ月くらいの作業量で1本、マルチプレイのアプリを作ることができれば。 また先月末に出した「KADAN」については、クラッシュする環境があるとのことで書き込みいただきましたので、追跡中です。 公開したアプリについてのリリースやバージョンアップ、作業中の情報については、ここよりもft-lab.jpのほうにブログ作ったほうがいいような気もしますので、あちらにブログ設けるようにします。 本独り言日記は、どっちかというと開発向けってのもありますので。