Nao_uの日記 このページをアンテナに追加 RSSフィード

2013-01-06

[][]MMDモデルの読み込みとNavMesh MMDモデルの読み込みとNavMesh - Nao_uの日記 を含むブックマーク はてなブックマーク - MMDモデルの読み込みとNavMesh - Nao_uの日記 MMDモデルの読み込みとNavMesh - Nao_uの日記 のブックマークコメント

MMD for Unityを使って、MMDのモデルとモーションをUnityに取り込む実験。


Defaultシェーダーでインポートするとポリゴンの表裏がおかしくなったような見た目になったので、MMDシェーダーでインポートしてからマテリアルを設定しなおすとうまくいった。

リニアライティングにすると黒い部分の反射率が低すぎたのでGimpのトーンカーブで暗部だけ適当に持ち上げた。足はまだ修正してないので真っ黒。


以前にpmdをfbxに変換して取り込んだ時にはサイズが小さすぎるので補正する必要があったんだけど、MMD for Unityだとデフォルトでこのくらいのサイズになってた。

スカートやネクタイの物理計算がおかしくなってたので少し修正したけど、調整が適当なので動くとめり込んでしまいやすい。


モーションを変換するときは、「Create Asset」のチェックを入れて別のアセットとして出力するとうまく再生できなかったので、チェックを外してPrefavの中に入れるようにすると正常に再生できるようになった。原因は不明。


数体置くと60fpsが維持できなくなってしまった。プロファイラで見るとスクリプトのCPU負荷が高くなっていて、どうやらIKの処理が重くなっているらしい。

CCDIKSolver.csでiterationsのループ回数を1/4くらいに抑えて対処。今回みたいな用途であれば、イテレーション回数を多少減らしても大きな問題にはならないみたい。

ついでにNavMeshをつかってプレイヤーを追いかけてくるようにしてみた。

道路の部分のモデルだけにNavigation staticを設定してbakeするだけで問題なく道路のみを歩いて追いかけてくるようになった。わりと簡単な設定で使えるみたいなのでとても便利。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20130106

2012-12-25

[][]ラグドールテスト ラグドールテスト - Nao_uの日記 を含むブックマーク はてなブックマーク - ラグドールテスト - Nao_uの日記 ラグドールテスト - Nao_uの日記 のブックマークコメント

Unityでラグドールのテスト。

ついでにWiiリモコンでの射撃テスト、HDRと動的露出補正、SSAOなどで市街地をそれっぽく見せる調整の実験と、動画には撮ってないけどワイヤーによる立体機動アクションの検証も兼ねてる。


Tポーズにしてラグドールを埋め込んだモデルをPrefav化して、弾がヒットした時に、transform以下のすべての姿勢をコピーして、新しいモデルに切り替え。


姿勢生成時に、各関節に速度を追加。ヒットした点からの距離に応じて速度を減衰することで、ヒットした点から力が加わっているように見せる。

// ラグドールの生成 
private void GenerateRagdoll( Transform originalRoot, Vector3 velocity, Vector3 pos)
{
	GameObject ragdoll = (GameObject)Instantiate(mPrefavRagdoll);
	CopyTransformRecursively(originalRoot, ragdoll.transform, velocity, pos);
}

// トランスフォームを再帰的にコピーする 
// ついでに初速の設定も行う(力点との距離が離れたら減衰)
private void CopyTransformRecursively(Transform src, Transform dst, Vector3 velocity, Vector3 pos) 
{
	dst.localPosition = src.localPosition;
	dst.localRotation = src.localRotation;
	
	float maxDist = 0.4f; // 最大距離
	float dist = Vector3.Distance( dst.transform.position, pos );
	float pow = 0.0f;
	if( dist < maxDist ){
		dist /= maxDist;
		pow = Mathf.Pow( dist, 1.0f ); // 線形減衰でも問題なかった
	}
	if (dst.rigidbody) dst.rigidbody.velocity = velocity * pow;
	foreach(var child in src) {
		var srcChild = child as Transform;
		var dstChild = dst.Find(srcChild.name);
		if (dstChild) CopyTransformRecursively(srcChild, dstChild, velocity, pos);
	}
}

吹き飛ぶ前のポーズが両手を合わせた形になっているせいか、手と肩がおかしくなることがある。両手だけ広げる方向に初速を与える、とかで改善できる?

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20121225

2012-12-24

[][]Wii Motion PlusをUnityで使うときのメモ Wii Motion PlusをUnityで使うときのメモ - Nao_uの日記 を含むブックマーク はてなブックマーク - Wii Motion PlusをUnityで使うときのメモ - Nao_uの日記 Wii Motion PlusをUnityで使うときのメモ - Nao_uの日記 のブックマークコメント

GlovePie + PPJoyを使用。GlovePieでリモコンの情報を入力して、PPJoyで作った仮想ジョイスティックに流し込む。

仮想ジョイスティックの値をUnityのInput Settingの設定で通常のジョイスティック入力として受け取る。


PPJoyはver 0.83を使用。Windows7以降ではドライバが正常にインストールできないため、PPJoyをインストール後に、Windowsを未検証ドライバが入れられるテストモードに切り替えて、PPJoySetup-0.8.4.5-early-release.exeでドライバをインストールする必要がある。


Bluetoothの接続はなぜかかなり不安定。最初の接続失敗がかなり多い。2つリモコンを同時につなごうとすると成功しやすいような気がしないでもない。スリープに入るとGlovePieが不安定になって、Windowsを再起動しないとつながりにくくなるような雰囲気も。一度つながってしまえば、しばらくは大丈夫。


GlobePieのスクリプトは下記の通り。アナログ値はPPJoy1.AnalogXで受け渡し。Unity側が0.0~1.0までしか受け取れないみたい(Input Settingで変えられるかも?)

var.Vec_X = Wiimote.MotionPlus.GyroYaw - var.Last_GyroYaw;

var.Vec_Y = Wiimote.MotionPlus.GyroPitch - var.Last_GyroPitch;

var.Vec_Z = Wiimote.MotionPlus.GyroRoll - var.Last_GyroRoll;


var.s0 = Wiimote.MotionPlus.PitchSpeed;

var.s1 = Wiimote.MotionPlus.YawSpeed;

var.s2 = Wiimote.MotionPlus.RollSpeed;


var.Last_GyroYaw = Wiimote.MotionPlus.GyroYaw;

var.Last_GyroPitch = Wiimote.MotionPlus.GyroPitch;

var.Last_GyroRoll = Wiimote.MotionPlus.GyroRoll;


var.ncx = Wiimote1.Nunchuk.JoyX

var.ncy = Wiimote1.Nunchuk.JoyY


var.rx = (var.Last_GyroPitch+180) * (1.0/360.0);

var.ry = (var.Last_GyroYaw+180) * (1.0/360.0);

var.rz = (var.Last_GyroRoll+180) * (1.0/360.0);


while( var.rx < 0 ) var.rx += 1.0;

while( var.rx > 1 ) var.rx -= 1.0;

while( var.ry < 0 ) var.ry += 1.0;

while( var.ry > 1 ) var.ry -= 1.0;

while( var.rz < 0 ) var.rz += 1.0;

while( var.rz > 1 ) var.rz -= 1.0;


var.rrx = var.s0 / 10000 + 0.5;

var.rry = var.s1 / 10000 + 0.5;

var.rrz = var.s2 / 10000 + 0.5;


PPJoy1.Analog3 = var.rrx;

PPJoy1.Analog4 = var.rry;

PPJoy1.Analog5 = var.rrz;


PPJoy1.Analog2 = 0;

PPJoy1.Analog0 = var.ncx;

PPJoy1.Analog1 = -var.ncy;


Keyboard.X = Wiimote.Nunchuk.ZButton;

Keyboard.C = Wiimote1.Minus;

Keyboard.V = Wiimote1.B;

Keyboard.Space = Wiimote1.One;

  • PPJoy1.Analog0 : デフォルトではHorizontal
  • PPJoy1.Analog1 : デフォルトではVertical
  • PPJoy1.Analog2 : 割り当てがうまくいかない?
  • PPJoy1.Analog3~5 : ジョイスティックのZなどに割り当てられた。Unityでは4~6に相当。

UnityのInput Settingで適当な名前を付けて、ジョイパッドからの入力として受け取る。0.0~1.0の値になるように適当に変換して、入力結果を受け取ってから元に戻す。


ジャイロの入力は、角度をそのまま使うとうまくいかなかった。真上に向けて、Z軸回転させてから戻すと元に戻らない。いろいろ試したけどダメだったので、それぞれの軸の速度を受け取るように修正。


今の姿勢行列に、それぞれの軸の回転速度を毎フレーム掛ける。少しづつずれてしまうけど、角度を受け取ってもずれは発生してしまってどこかで補正が必要になるので、こちらの方が素直な実装かも。実際に触ってみたら角度そのままよりも、移動量を増幅した方が気持ちい動きになったので、むしろ好都合だった。


ずれの補正については、センサーバーで正面方向を、重力加速度でピッチとロールを自動補正できるはず。渡せるアナログ値の数の限界に引っかからないかどうかは要確認。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20121224

2012-12-01

[][]メタボールパーティクル メタボールパーティクル - Nao_uの日記 を含むブックマーク はてなブックマーク - メタボールパーティクル - Nao_uの日記 メタボールパーティクル - Nao_uの日記 のブックマークコメント


Unityのシェーダーとマルチパスレンダリングの使い方の練習を兼ねて、メタボールパーティクルの描画を試してみた。


オフスクリーンに白黒のハイトマップをレンダリングしておいて、2パス目でハイトマップの上下との値の差分から法線マップ化して、反射と屈折した結果を合成して描画。


屈折先テクスチャも別パスで低解像度でレンダリングしていて、反射はキューブマップ+スフィアマップを使用。キューブマップだけだと光沢感が足りなかったので、スフィアマップを足した結果の輝度の高い部分だけを抽出してさらに加算する事で、強引にHDR化してる。


ポストフィルタはブルームとFXAAを使用。地面を上を流れてるときや、粒が小さくなった時の見え方が不自然になってるので、反射や屈折はもう少し工夫する必要がありそう。


  • 今回のハマりポイントのメモ
    • シェーダーで使うテクスチャの数が増えると「Program 'frag_surf', Maximum texture indirection of 4 exceeded; 5 indirections needed to compile program」というエラーが出るので「#pragma target 3.0」が必要になる。

    • カメラを追加してレンダーターゲットテクスチャを追加する事でオフスクリーンレンダリングができる。オブジェクトごとの描画パスの制御はレイヤーで行う。カメラとオブジェクト双方にどのレイヤーを描画するかのチェックを入れる必要があるので注意。ライトも同様。

    • オフスクリーンレンダリングの描画順は、カメラのDepthで制御できる。必要な場合にはカメラのHDRのチェックも忘れずに。

    • 本来は白黒のハイトマップ生成時にデプステストしないと一部描画が破綻するんだけど、描画パスやシェーダーを増やさずに済む上手いやり方が見つからなかったので保留

屈折を別パスで描画するのは背景オブジェクトが増えてくるとと負荷が高くなるので、レンダリングの途中経過やデプスバッファをテクスチャとして再利用したいところだけど、Unityでやるにはどうすれば良いんだろう?

どこかの設定でレンダリング済みのデプスバッファと背景だけを別のカメラに割り当てたりとかができるのかな。

追記:背景のテクスチャをつかって歪めたりするにはGravPassを使うらしい

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20121201

2012-11-21

[][]箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験 箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験 - Nao_uの日記 を含むブックマーク はてなブックマーク - 箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験 - Nao_uの日記 箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験 - Nao_uの日記 のブックマークコメント


箱に弾が当たった場所から8分木で再帰的に分割してみる破壊挙動の実験。派手に砕け散ってくれるとちょっと楽しい。


このやり方で地面まで全部再帰的に破壊して掘り下げたりできないものかと期待してたけど、画面に見えてる数個の箱を半壊させるだけでも激しく処理落ちしてる。破壊の絵面としては箱のサイズがもう半分くらい小さいものイメージしてたんだけど、個数が爆発的に増えてしまうので無理っぽかった


穴の中を掘り進むくらいの物量を出したいなら、Mincraftみたいなボクセルでやらないとやっぱり無茶かな。その場合、壊れた箱の当たり判定とかをどう処理するのかが悩ましいところだけど

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20121121

2012-11-04

[][]実写合成 実写合成 - Nao_uの日記 を含むブックマーク はてなブックマーク - 実写合成 - Nao_uの日記 実写合成 - Nao_uの日記 のブックマークコメント

昼間の日光が入る状態で基本機能だけでライティングを調整。やはりちょっと無理がある感じ


夜の室内照明で撮影。髪の毛の色が変わってしまった。

ソフトフォーカスを入れてみた。それっぽく見せるには質感そのものより、AA、AO、ライティングが重要っぽい感じが。



さぽてんミクを足してみた。体は未調整。

ライティングの複雑さが足りない感じ。やっぱりキューブマップは欲しい。

やはりある程度のジオメトリの複雑さがあったほうが奇麗。スペキュラーにノイズを入れると良くなりそう。


本物の影を参考に、影付きの平行光源を何灯か使うべきだった。でないと複雑な影が落ちない。一灯で無理してあわせようとしたのが失敗か。

部屋の蛍光灯くらいの距離感だと、人間サイズのものが立っただけで地面の影は恐ろしくボケてる。これを合わせるのはかなり大変そう。


あと、環境を変えて撮るだけで髪の毛の色がこんなに違ってくるとは思わなかった。ミクの髪の毛の色は青から緑までバリエーションがあるけど、同じ実物を写真に撮った時に出る差の範囲であれば違和感がなかったりとかするのかな


Webカメラでの撮影だと、肉眼では普通に見える環境でも、ライティングをきっちりやらないと飛んだり潰れたりで見れたものではなくなるのは何とかならないものか。どこに合わせるのがいいのかな


既存のシェーダーを使った強引な目合わせじゃなくて、周りの環境をHDR撮影してキューブマップにしたうえで、もうちょっと物理的なパラメータに近いシェーダーを使ったらどのくらい違いが出るのかも試してみたい

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20121104

2012-09-14

[][]2DのBGエディタ 2DのBGエディタ - Nao_uの日記 を含むブックマーク はてなブックマーク - 2DのBGエディタ - Nao_uの日記 2DのBGエディタ - Nao_uの日記 のブックマークコメント


Unityのエディタ拡張で、2DのBGエディタを作成中。

なんとか必要な要素の実装方法に目処がたってきたところ。ゲーム本編と似た感覚でUIを作れるのは便利。Unityはゲームじゃなくてツール作成環境としても使えそう。

それにしても、こういうエディタ内のデータってどう保存するのがいいんだろう?今回はBGマネージャの子供OBJの配置情報から毎回再取得することに。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120914

2012-08-26

[][]Unityで市街地をHDRで描画してみるテスト Unityで市街地をHDRで描画してみるテスト - Nao_uの日記 を含むブックマーク はてなブックマーク - Unityで市街地をHDRで描画してみるテスト - Nao_uの日記 Unityで市街地をHDRで描画してみるテスト - Nao_uの日記 のブックマークコメント

Unityで市街地をHDRで描画してみるテスト。写真ベースのテクスチャだとアルベドが高すぎておかしな絵になってる事が多かった。ライティングやマテリアルを延々と調整してみてたけど、まだ違和感がたくさん残ってる。調整難しい


Nao_u@Nao_u_

.@masakam1 シェーダーはデフォルトで入っている Refrective/Bumped Speculer をそのまま使いました。キューブマップは、くっきりしたものとボケたものの2種類を作って、素材ごとに張り分けています。


カメラの設定でレンダリング先をHDRにして、ディファードレンダリングでBeastで焼き付けたライトマップ+平行光の影で描画しています。あとはライトの強さやマテリアル(特にアルベド)のパラメータをいろいろ微調整して、今の形に落ち着きました。


ほぼ全てのマテリアルに環境マップを適用した事と、HDRのリニアライティングに合わせてアルベドを適切な値に調整した事が、特に見た目に大きく寄与したような印象でした。まだいろいろと違和感のある部分が残ってはいますが。


さっきのデモをちょっとだけ更新。空の色に合わせて天空光を再設定したり、ライトマップを焼くときの反射回数増加のなど、細かくクオリティUP。beastはCPUの8スレッドをほぼ100%使い切ってくれてるのに、それでも焼くのには時間がかかってしまうので心理的にも焼き直すのは結構面倒

Nao_u@Nao_u_

@masakam1 背景はアセットストア(http://t.co/pxvFPTkd)から購入して、そこに入っていたデモ用の地形をほぼそのまま使用しています。建物や道路は一個づつ別のプレハブになっていました。あと、それぞれのテクスチャに法線マップも含まれていたのは、嬉しい誤算でした

Nao_u@Nao_u_

@rockout77 そうですね。ちょっと建物を動かしたり、空の色と合わせようと微調整するだけでも10分程度の待ち時間がかかったりすると試行錯誤しにくい、という面はありそうです。最近のリアルタイムGIの流れは、このあたりを踏まえての効率化にもつながりそうでしょうか。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120826

2012-08-18

[][]『航空雷撃戦 Ver0.1』 『航空雷撃戦 Ver0.1』 - Nao_uの日記 を含むブックマーク はてなブックマーク - 『航空雷撃戦 Ver0.1』 - Nao_uの日記 『航空雷撃戦 Ver0.1』 - Nao_uの日記 のブックマークコメント

Unityで魚雷で空母を攻撃するフライトシミュレータもどきを作ってみた。上記リンクから、ブラウザで動作可能。

(要Unity Web Player)


航空魚雷の性質上、ある程度離れたところから撃たないといけないため、相手が動いてると命中させるのが難しい。リトライすることで編隊の機数が増えて、一応爆撃もできる。


画面右下の小さい枠内には魚雷視点の映像が映っていて、魚雷は着水後にしばらく水面下を深く潜るため、一時的に姿が見えなくなった後、航跡を残しながら目標に向かう。



航空雷撃ってどのくらい難しいのかを試してみたくなったので作ってみた。フライトシミュレータとしてはかなり適当な挙動だけど、一応は敵艦が約30ノットで魚雷は40ノット、航空機の速度は時速350km/hと、それぞれの速度比は実際のものにだいたい合わせてみた。


敵艦に近づいてしまうと猛烈な対空砲火が待っているため、普段は距離800〜1000mで発射した後に、敵艦前方に退避するらしい。実際、距離1000mだとまだまだ船とは大きく離れているため、移動目標の先を読んで当てるのはかなり難しい。


真珠湾攻撃のときは湾の水深が浅いため、距離300m高度5mからの雷撃だったそうで。ちょっと危険を感じるくらいの低高度ではあるものの、こちらは奇襲なので停止目標な上に相手からの反撃も非常に少ないので、命中率はかなり高そう。





当時の回顧録を読んでいると「見事な操船で左右に上手く舵を切って、魚雷を回避した」みたいな記述がよく出てきて、船って相当に鈍重な印象があるので、あんなものを見てから避けられるのか?という疑問があったんだけど、実際の速度比で動くものを作ってみて、納得した。


まず、魚雷の水中での速度は意外と遅く、直線的に動いてる敵艦を狙うだけでもかなり難しい。また、魚雷発射時にはかなりの時間まっすぐに飛ばないといけないうえに、発射後に命中まで数十秒から分単位の時間があるので、熟練した艦長であれば雷撃機の軌道や魚雷の航跡をみてうまく左右に舵を切って回避する余地は十分にありそう。


軍艦でも速度の速いものは全力航行すると30ノットを超える速度が出て、時速に直すと60km/hくらいになるので、想像してたよりはずっと速い。20ノット前後しか出ない鈍足艦と最高速が35ノットを超える高速艦では、爆撃や魚雷相手の回避能力もかなり違ってくるんじゃないか、と思った。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120818

2012-08-13

[][]Unityでフォトリアルっぽい絵を出してみるテスト Unityでフォトリアルっぽい絵を出してみるテスト - Nao_uの日記 を含むブックマーク はてなブックマーク - Unityでフォトリアルっぽい絵を出してみるテスト - Nao_uの日記 Unityでフォトリアルっぽい絵を出してみるテスト - Nao_uの日記 のブックマークコメント

f:id:Nao_u:20130903054131p:image


ディファードライティング+リニアライト、HDR、SSAO、Beast焼き付け、ライトプローブ、DOF、FXAAなどをためしてみた。一通りの機能は揃ってるので、あとは調整次第な感じ。


主にポストフィルタが処理を食ってそうだけど、このくらいなら一応MacBookでも実用的な速度で動いてる。Windowsで動かしてみたら、キューブマップの解像度が低いものが使われてるみたいで鏡面のオブジェクトがなんだかよくわからない質感になってる。なぜだろう


もやしパン@Moyashipan

「お兄ちゃんがUnityで作るゲームって、箱とか球ばっかりでつまんなさそうだよね」

UnityでMMDのモーションを再生しようとしたら、歩き、走り、コンボ攻撃のモーションを作るだけでも丸一日以上かかってた。短期間でなんとかしようと思ったら、箱と球だけで作れるととても楽。


なので、箱と球だけで構成されててもつまらなさそうに見えないようにできないだろうか、と模索中。ちょうど一年前に作った箱と球だけのゲーム(http://t.co/xi4kfmM9)もこんな風に変えてみたら少しは印象が変わったりしないかな、とか。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120813

2012-07-26

[][]Strumpy Shader Editorのテスト Strumpy Shader Editorのテスト - Nao_uの日記 を含むブックマーク はてなブックマーク - Strumpy Shader Editorのテスト - Nao_uの日記 Strumpy Shader Editorのテスト - Nao_uの日記 のブックマークコメント

Unityで、ノードを繋げてシェーダーを構築するStrumpy Shader Editorを使って錆シェーダーを作ってみた。複雑なものを作るなら普通にプログラムで書いたほうが楽かもしれないけど、慣れの問題かな


パラメータを変えて全身を錆させてみた。確かにちょっとホラーっぽい雰囲気が。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120726

2012-02-06

[]プロシージャルテクスチャ+雪山 プロシージャルテクスチャ+雪山 - Nao_uの日記 を含むブックマーク はてなブックマーク - プロシージャルテクスチャ+雪山 - Nao_uの日記 プロシージャルテクスチャ+雪山 - Nao_uの日記 のブックマークコメント

雪をPerlin Noiseで均等に積もらせるんじゃなくて、法線を見て特定の方向に偏らせるとちょっとそれっぽく見えるようになった。

風の影響で特定方向から多く積もったり、陽の当たる方向が溶けて、影の方向が残ったりするような感じを再現。

このあたりも自然に見せようとするといろいろ工夫の余地がありそう

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120206

2012-02-05

[]プロシージャルテクスチャ+地形 プロシージャルテクスチャ+地形 - Nao_uの日記 を含むブックマーク はてなブックマーク - プロシージャルテクスチャ+地形 - Nao_uの日記 プロシージャルテクスチャ+地形 - Nao_uの日記 のブックマークコメント

この前試してたプロシージャルテクスチャに地形の凹凸をつけてみた。次はここに岩のテクスチャを足していく予定


雪山。岩や雪のテクスチャはわりと誤魔化しが効きやすいみたいで、思ってたよりは簡単にそれっぽく見えるものになってくれた。空の色やフォグの不自然さが気になってきた


人間のスケールで見たときのクオリティを上げようと思ったら、テクスチャの詳細度が足りてないし地形のテッセレーションも必要になってきそう。課題が多い

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120205

2012-01-27

[]プロシージャルテクスチャ プロシージャルテクスチャ - Nao_uの日記 を含むブックマーク はてなブックマーク - プロシージャルテクスチャ - Nao_uの日記 プロシージャルテクスチャ - Nao_uの日記 のブックマークコメント

Perlin noiseをつかった草地のプロシージャルテクスチャ生成の実験中。周期の違うノイズに適当に色を付けたものをたくさん重ねて、やや荒いノイズで地面の高さを補正してみた


もう一枚。パラメータの微調整を繰り返してたらだいぶそれっぽく見えるようにはなってきたけど、まだまだ課題は多い。


@nabeshin 適当に色を付けたPerlin noiseにをたくさんスケーリングして、それっぽく見えるように重ねてるだけだったりします。いまはシェーダー内でリアルタイムで計算してますが、負荷を考えると素直にテクスチャに焼いた方がよさそうです

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20120127

2011-07-10

[]法線マップ煙 法線マップ煙 - Nao_uの日記 を含むブックマーク はてなブックマーク - 法線マップ煙 - Nao_uの日記 法線マップ煙 - Nao_uの日記 のブックマークコメント

f:id:Nao_u:20110812163049p:image


f:id:Nao_u:20110812163048p:image

shinriyoshinriyo2011/10/20 11:03すごいですね、左上の小さいマップはどうやってる作成されたのですか?

Nao_uNao_u2011/10/21 23:52上段はモデル位置の周囲6方向を毎フレームレンダリングして、下段は上段のテクスチャキューブマップ化したものをシェーダーで適当にサンプリングしてぼかして生成しています。
モデルのレンダリング時にIBLの反射とディフューズの環境マップとして使用しています。

トラックバック - http://game.g.hatena.ne.jp/Nao_u/20110710