脳の中の風船

ええと、諸事情により２日間で（！）、前回の状態からゲームとして動くレベルまでもっていかなければならなくなりました。（ホントは私がノープランだったせいなんですけど。）

速攻で壁の判定を実装します。やり方はグラベル作成と同様、配列を参照して、壁の外側エリアに入ろうとしたら壁内側まで戻すというもの。これだと判定がマス単位なので、斜め向きの壁は階段状の嘘判定になってたりします。
でも今はこれで我慢。CGの作り込みを優先しました。

判定にはこんな画像をを使いました。

getPixel メソッドで色情報から地面情報配列を作成していきます。処理自体は以前のと同じです。
車の大きさを考慮していない判定（点判定）なので、それをごまかすために黒い部分の方をひとまわり大きめに作っています。こうしないと運転席が壁にめり込んでしまいます。

コース外（黒エリア）に出ようとしたときの戻し方とかは超てきとーです。ちゃんと作ったらソースを公開します。
そんなわけで今回はここまで。次回、何とかカタチになってるはずのデモバージョンを公開します…！

レースゲーム制作記 | No Comments »

WordPress のテーマを改変中。PHP と CSS をせっせといじってます。
ころころサイトデザインが変わるかもしれませんがご了承ください。

WordPress は日本より海外で流行っているだけあって、テーマとか探してると海外のデザインに触れられるのがいいですね。

趣味・雑記 | wordpress | No Comments »

大変そうな壁判定はひとまず置いておき、それ以外の必要な要素を少しずつ作っていきます。

ハンドル動作

ステアリングホイールが動くようにします。
技術的には難しいこと無いです。でも、やってみて気づいたのが、キー入力 → ステアが動く → 車が旋回する …という流れのレスポンスだとか動きの細かい演出だとかって、結構ゲーム的に重要だっていうこと。0.1秒反応が違うだけで、かなり車の重さの感じ方とかは変わってきますね。それに初心者への敷居にも関係してきます。
ま、それはさておき、よくありそうなテクを使ったのでここではそのメモを。

まず、「中心を軸に画像を回転させる」方法。
別に中心じゃなくて任意の点でも同様です。
やりかたは、Bitmap > Sprite > Stage のように addChild していって、Bitmap 左上にずらした後、Sprite を回転させるだけ。今回のように常に同じ軸で回転すればいい場合は、この方法が使えます。

var steerSprite:Sprite = new Sprite();
var steerBitmap:Bitmap = new Bitmap();
steerBitmap.bitmapData = new steerImage(0, 0);
steerBitmap.x = -steerBitmap.width / 2;
steerBitmap.y = -steerBitmap.height / 2;
steerSprite.addChild(steerBitmap);
addChild(steerSprite);

steerSprite.rotation = myInputSteer;

もう１つは、「簡易トゥイーン」。
デジタルなキー入力に対して、自然な感じにステア舵角が動くようにします。

var targetSteer:Number;

//左ステア
if (keyPressLeft && !keyPressRight)
{
	targetSteer = -myFullSteer;
}
//右ステア
else if (!keyPressLeft && keyPressRight)
{
	targetSteer = myFullSteer;
}
//ステアを戻す
else
{
	targetSteer = 0;
}

//スナップ
if (Math.abs(targetSteer - myInputSteer) < 1)
{
	myInputSteer = targetSteer;
}
//目標に近づける
else
{
	myInputSteer += (targetSteer - myInputSteer) / 6;
}

なにやらいろいろ書いてありますが、要は、A を現在値、B を目標値としたとき、 A += (B - A) / n でトゥイーンさせているってだけです。目標値に近づいたときのスナップのさせ方は、もっとスマートにできるような。。。
ちなみに（疑似）荷重移動も、加速度や旋回角をもとにこのような処理をして、サスペンションっぽさを表現しています。

遠景の追加

空と地平線に絵を入れて、ちゃんと車の向きについてくるようにします。
この辺は案の定2D処理です。細長い画像を用意しておいて、車の向きに合わせてそれを横にスクロールします。車の向きは 0 ～ 359.9… 度までの値をとるようにしてあるので、図のようにループ部分を少し作っておけば、あとは自動で景色がパノラマになってくれます。

これで余裕…かと思いきや、Flash の描画仕様に起因する（？）妙なトラブルがあったのでその報告を。
このゲームでは荷重や車の揺れを表現するために、2Dも3Dもあわせて viewContainer というスプライトに addChild していて、それを傾けたり揺らしたりしています。もともとは背景画像も直接そこに追加していました。
が、そうすると viewContainer を傾けたときになぜか背景画像のスプライトだけ動きがフィットしない…！（数ピクセル上下にずれて表示されました。）

どうやら原因は、Flash の画質設定が「低」であったことと、スプライトが 3840 × 250 px とかなり変則的なサイズだったこと。（…だと思います。画質「高」にしたらずれなくなりました。）つまり、Flash の画質設定は描画を荒くしているだけでなく、内部処理の有効数字とかもはしょっちゃっているんでしょうね。

しかたがないので BitmapData.draw メソッドを使って、必要な範囲 720 × 250 px だけをキャプチャして addChild する、という回りくどい処理にしています。つまり配置するインスタンスを、あらかじめ切り取ってコンパクトなサイズにしたわけです。これで viewContainer が傾いても問題なく描画されるようになりました。細長インスタンスをX移動させるだけの方がはるかに高速なのにッ。

コース全体モデルの作成

最後にコースの3Dモデルを充実させておきます。
欠けたり歪みすぎたりしないギリギリのローポリゴンを目指してひたすらモデリング～。だけど壁衝突判定をどうしようか悩み中でして、壁のモデリングは見送ってます。モデリングが完了したら、以前紹介したシェーディングテクスチャ作成方法で、一気に陰影をつけました。

今回のデモ

いろいろ処理を追加したのと、遠方クリッピングしているとはいえ3Dモデル自体が増えてきたせいで、動作負荷が高くなっちゃってきていますね。Celeron D クラスだと処理落ちするかも。しかも壁ポリゴンは結構細かい分割になるから、壁追加後が少し心配です。

デモをプレイする　（要：Flash Player 9.0.115.0以降）

＊ソースファイル Main.as の全文はこちらから参照できます。
（試行錯誤中のソースなんで怪しい行がいっぱいです。）

レースゲーム制作記 | actionscript3 | No Comments »

路面／路面外の判定を作ります。
地面判定をして、グラベル上（というかグリーンとサンドか）だったら動きが鈍くなるようにしてみます。味付けに画面も揺らしました。

判定方法はコースを量産しやすいこと、判定処理が軽いこと、の２つを優先します。そこで。

1. 判定用のビットマップを作って Flash に読み込む
2. ピクセル色情報をもとに巨大な２次元配列を作成
3. 配列を参照して、今いる座標の路面判定をする

…という方法にしてみました。
判定用ビットマップは床テクスチャから簡単に作れるし、配列参照だけならどんなに大きくても負荷がかからないだろう、という狙い。メモリは浪費しちゃいますが。

今回は単純に、路面／路面外の２種類だけを作りました。ですので読み込むのは白黒２階調の画像。

ゲーム初期化処理の時に getPixel メソッドでピクセル色情報を取得して、配列を作成していきます。

groundData = new Array();
var groundBitmapData:BitmapData = new courseData01(0, 0);
for (var i:int = 0; i < 560; i++)
{
	groundData[i] = new Array();
	for (var j:int = 0; j < 420; j++)
	{
		if (groundBitmapData.getPixel(i, j) == 0xffffff)
		{
			groundData[i][j] = 1;
		}
		else if (groundBitmapData.getPixel(i, j) == 0x000000)
		{
			groundData[i][j] = 0;
		}
	}
}

メインループにて、座標情報をもとに配列を参照して地面情報を取得。

groundState = groundData[Math.floor(myPositionX / 5)][Math.floor(myPositionY / 5)];

あとはコース外だったら、加速度とかをコントロールして挙動制御すればＯＫ。そして例のごとく 2D 処理で画面を揺らし、それっぽい演出をしておきます。速度の絶対値の累計をカウントすることで、揺れ方が移動距離に合うようにしています。でもこの辺はあまりにもひどいソースになっちゃってるんで詳しいことは割愛。。

デモをプレイする　（要：Flash Player 9.0.115.0以降）

＊ソースファイル Main.as の全文はこちらから参照できます。
（試行錯誤中のソースなんで怪しい行がいっぱいです。）

レースゲーム制作記 | actionscript3 | No Comments »

お世話になっているサイトやインスピレーションを受けたものなど、ここでいくつかご紹介。
もっと追加するかも。

note.x

Papervision3DやAway3Dについて詳しく解説されています。ライブラリについて分からないことがあったら、とりあえずここを見れば何とかなるかも？

閃光的網站・弛緩複合体 -Review Division-

以前お世話になっていたサイト。Papervision3D 1.x 系列の情報が充実しています。

CgInstitute - blog | d5 さんのブログ

Papervision3Dでレースゲームを作ってます。私と違って、ちゃんとフル3D描画です。3Dならではのリプレイが羨ましい…！

flashゲーム作成記

Papervision3Dを使ったゲームとか技術ネタとかいろいろあります。

Flashゲーム講座&アクションスクリプトサンプル集

ゲームで使える小技たち。ActionScript 3.0 の使い方についてはコチラにあります。

マルペケつくろーどっとコム > 衝突判定編

物体の衝突を判定するプログラムについて。ホント勉強になります。

3D Rally Racing

疑似3D Flashだけでここまでやるとは…という感じのレースゲーム。でも挙動が。。。

Osram - Mörkerkörning

車でシカをひく、じゃなくって、よけるゲーム。別にたいしたことはしてないんだけど、「運転している感覚」を感じさせるための細かい作り込みが参考になりました。

レースゲーム制作記 | links, papervision3d | 2 Comments »

Lightwave 3D Layout でライティングし、そのシェーディング結果をテクスチャとして利用できるようにしてみます。
今回私は、レースゲームのシェーディング済みテクスチャを用意するためにこの方法を使います。ですので、精度よりも生産性を重視しています。キーワードは２つ。

• Ambient Occlusion（アンビエントオクルージョン）
• Surface Baking Camera（サーフェイスベイキングカメラ）

アンビエントオクルージョンで環境光を模倣

レースゲームのフィールドだから、「影」はくっきりとしたレイトレースのシャドウでも良いのだけれど、環境光を感じるようにするには、やっぱりやわらかい「陰」も必要でしょう。
環境光を再現する方法としてはラジオシティが正確ですが、とっても重い、と。そこでアンビエントオクルージョンを使います。ラジオシティは反射していく光を次々と追ってシミュレートするのに対し、アンビエントオクルージョンは周囲から光がどのくらい遮られるか、という陰係数をもとに計算するそうです。

まずはモデリングをして、UVマップを作成しておきます。

Lightwave v9ではサーフェイスはノード形式で制御できるようになっていて、アンビエントオクルージョンもノードを介して「サーフェイスに」設定してやります。レンダリングはレイトレースを使います。

標準でインストールされるアンビエントオクルージョン・ノードには Occlusion, Occlusion II の２つがありますが、どちらも精度がイマイチ。より細かく設定できるノードプラグイン SG_AmbOccNode を使いました。

サーフェイスのノード設定はこのようにしました。

モデルの大きさがどうなっても困らないよう、ライトはすべて Distant Light を使用します。場合によってはライトのプロパティで Ambient Intensity を高めに設定しちゃっていいかもしれません。
Render Globals のオプションで Ray Trace Shadows にチェックを入れ、レンダリングすると、環境光が再現されていることが分かります。

サーフェイスベイキングカメラでテクスチャ書き出し

ここからが本題ですね。レンダリングした状態のサーフェイスを、テクスチャとして保存します。
Lightwave v9 Layout では Surface Baking Camera というカメラが追加されていて、これは、メッシュとUVマップを指定すると、それに応じたUVテクスチャをレンダリングしてくれるというものです。書き出した画像をテクスチャとして設定すれば、簡単にシェーディング済みモデルの完成です。

やり方はとても簡単。
まずはModelerで、適用させたいポリゴンだけを選択してUVマップを作成し、それらのポリゴンを１つのレイヤーにまとめておきます。
Layoutに移ったら、カメラのプロパティから Surface Baking Camera を選択し、設定で Mesh に先ほどのオブジェクト、UV Map にさっきのUVを指定します。その他の項目を適当に設定し（出力画像のタテヨコ比に注意）、レンダリングすればUVマップ用の画像が取得できるはずです。

低解像度の場合は、UV Border の値を設定して、UVマップの輪郭よりレンダー画像が少しはみ出すようにしてやった方がいいかもしれませんね。詳しいチュートリアルは、公式のデモビデオで取り上げられています。

古いバージョンのLightwaveを使っている場合

アンビエントオクルージョンは、SG_AmbOcc プラグインが利用できます。
ベイキングは Surface Baker (LW_Baker) シェーダが利用できます。チュートリアルはこちら。
でも、どちらも使ったことなくて詳しいことは分かりませんッ。

ゲームで使ってみました

さて、レンダリング済みモデルをCOLLADAに変換し、前回作ったゲームサンプルに読み込ませてみました。
まあ相当荒削りなサンプルですが、少しは空間内の建物として見えてきたでしょうか。

デモをプレイする　（要：Flash Player 9.0.115.0以降）

レースゲーム制作記 | 3d, lightwave | No Comments »

今回は実はかなり大事な処理です。
ゲーム好きの方ならピンとくると思いますが、PlayStationのレースゲームなんかでよく見られる「走っていくと少しずつ遠くのオブジェクトから表示されてくる」という処理を実装してみます。
といってもありがたいことに、Papervision3D 2.0 Alpha にはこの機能が実装されているんですね。FrustumCamera3D です。でも今までの FreeCamera3D から FrustumCamera3D に切り替えるにあたって、実は結構つまずきました。。。そのときの備忘録です。

まず、「遠方モデルを表示しない」機能のメリットは、「とてつもなく広大なフィールドが実現できるようになる」こと。
カメラからの距離に応じてレンダリングするポリゴンを制限できるため、フィールドがどんなに広くなっても描画処理自体の負荷はほとんど変わりません。レースゲームには必須ですね。（逆に箱庭式の3Dには不向き。）
しかも私の作っているゲームは、遠方のスケール感をごまかすために疑似3Dの地平線の位置を下げて描画しているので、遠くの3Dモデルは宙に浮いて見えるんです。（→前回サンプル）
なんとしても実装しなければ！

FrustumCamera3Dについて

ざっくり Papervision3D 2.0 Alpha のカメラについておさらいしておきますと、次の３つがあります。
説明正確じゃなかったらすいません～。

Camera3D

常に3D空間の原点のほうを向こうとするカメラ。
よって Camera3D.rotationX とかで向きを変えたりはできない。またこのカメラを原点座標(0,0,0)に設置するとマズイらしい。視野角とかプロジェクションは、focus, zoom プロパティで制御する。

FreeCamera3D

座標や向きを自由に動かせるカメラ。
x, y, z, rotationX, rotationY, rotationZ プロパティが使える。要はフツーのカメラってことですね。プロジェクション方法は Camera3D と同じっぽい。

FrustumCamera3D

2.0 Alpha で実装された、視錐台を利用するカメラ。
ポリゴンを描画する台形錐？領域を空間上に設定して、その範囲を投影する。カメラの座標と向きは自由に動かせるが、rotation系のプロパティに不備あり。

FrustumCamera3D についてもう少し詳しく。

• 定義はほかと全然違います。

  FrustumCamera3D(
  	viewport3D:Viewport3D,
  	fov:Number = 90,
  	near:Number = 10,
  	far:Number = 1000
  )
  

• fov でカメラの視野角を設定します。単位は「度」。40～60度くらいが自然でしょうか。ほかのカメラとは違って、zoom, focus プロパティは使わないようです。
• near, far でカメラからどのくらいの距離にあるオブジェクトを表示するか、を決めます。（正確にはクリッピング平面までの直線距離。） near が 0 以下だと動作がおかしくなります。
• rotation系のプロパティは、取得はできるが代入しても描画に反映されないという現状です。しょうがないので pitch(), yaw(), roll() メソッドを使ってカメラを動かしました。それぞれ X, Y, Z 軸に対しての回転角度（←カメラの向きではない）を引数に与えます。
• かなりピンポイントな現象かもしれませんが、読み込んだのモデルデータのスケールによって、クリッピングの判定がうまくいかないことがあります。「明らかに画面に収まる位置のポリゴンなのに、カメラの座標によっては全く表示されない」という現象です。
  解決策は、「とにかく大きくモデリングをすること」！3Dソフトの時点でかなり大きめにモデルを作っておいて、Collada.scale で縮小しつつサイズ調整する方法にしたところ、正常に判定されるようになりました。

実装してみる

さて、ここまで把握できれば、後はモデルを作って配置して微調整するだけです。

まずはカメラ作成。
床よりも3Dモデルのほうが遠くまで見えるようにしています。

camera = new FrustumCamera3D(viewport, 55, 10, 16000);
camera.y = 250;
camera.z = -400;

camera2 = new FrustumCamera3D(viewport2, 55, 10, 30000);
camera2.y = 250;
camera2.z = -400;

COLLADAモデルの配置。
なかなか中途半端な微調整をしています。3Dモデルの四隅に適当なモデルを作っておいて、それが床テクスチャの端っこにフィットするように、スケールや座標を調整していきました。

courseObjects = new Collada("courseModel01a.dae");

courseObjects.x = 35100;
courseObjects.z = 46200;
courseObjects.rotationY = -90;
courseObjects.scale = 1/3;

カメラの移動。
（ひどい式。自機の座標と向きから求めればよかった。。。）

camera2.z += (12000 / 360) * 6 * (myCurrentSpeed / myMaxSpeed) * Math.cos(myDirection);
camera2.x += (12000 / 360) * 6 * (myCurrentSpeed / myMaxSpeed) * Math.sin(myDirection);
camera2.yaw(deltaDirection * 180 / Math.PI);

これでようやくゲーム描画の基本部分はできあがってきました。

＊ソースファイル Main.as の全文はこちらから参照できます。
（試行錯誤中のソースなんで怪しい行がいっぱいです。）

レースゲーム制作記 | papervision3d | No Comments »

DAEの3Dオブジェクトを読み込んで、前回作った疑似3Dのフィールドの上に合成します。
はたして上手くフィットするか。

3Dモデル作成～Papervision3Dで表示までのやり方はこちらのエントリ

3DモデルのスケールがPapervision3Dだとどのくらいの大きさになるのかは、結局よく分かりませんでした。というわけで、とりあえず合成した後、Colladaオブジェクトの scale プロパティを少しずつ調整しながら合わせていきました。
それとPapervision3Dは、Zソートというんでしょうか、「どちらの面が手前に表示されるか」の判定がかなりアバウトですので、床と3Dモデルの関係がおかしくならないよう Scene3D を２つ用意して、必ず3Dモデルの方が手前にくるようにしています。
最後に、3Dモデル用に使っている FreeCamera3D の z, x, rotationY プロパティを動かすようにしてあげれば完成。

疑似3Dの床テクスチャと、移動する3Dオブジェクトの接地部分が問題ないかちょっと不安だったけど、どうやらゲーム的に大丈夫なくらいの見え方はしていますね。地平線のパースをごまかすのは、FrustumCamera3Dで何とかする、と。

＊ソースファイル Main.as の全文はこちらから参照できます。
（試行錯誤中のソースなんで怪しい行がいっぱいです。）

レースゲーム制作記 | papervision3d | No Comments »

HTMLに埋め込んだSWFコンテンツをブラウザで閲覧すると、Flashで設定されているフレームレートよりも遅く再生されてしまうことがあります。Flashの動作負荷にかかわらず15%くらいフレームレートが落ちているので、仕様的な問題なのでしょうか。

これを回避するには、HTMLの <embed> タグに wmode=”opaque” 属性を追加しましょう。
Adobe Flashを使っている場合は、パブリッシュ設定 の HTML > ウィンドウモード を「不透明表示」に変えることで対処できます。

この方法でIE6、IE7、Firefoxでは正常になりました。
が、Safariでは効果がありませんでした。う～ん…。

技術ネタ | flash, flashplayer, html, swf | No Comments »

Lightwaveでモデル作成 → BlenderでCOLLADA出力 → Papervision3Dでレンダリング、と練習してみます。
PV3Dやってみる(5) 【DAEデータを読み込み】 | [FlaTech+]WebDesign Rainyday を参考にさせていただきました。やりながら気づいたこと、つまずいた点とかを書いておきます。

モデルの作成

Lightwave Modelerで適当にモデルを作ります。

UV投影方式は Atlas にしました。
データインポート時にトラブルのもとになる（気がした）ので、UV名やサーフェス名は、半角英数のみ・記号なしの短いものにした方が無難です。ちなみにUVマップされていないサーフェスは、Papervision3Dで描画できないっぽいです。単純なモデルでもUVマッピングしましょう。
マップ画像の形式は、JPEG か PNG あたりにしておけば問題ないです。ちなみにPNGに透明色があると、その部分はPapervision3Dで描画したときに透明のテクスチャとして扱ってくれます。自動で。これは便利！

そして、そのままネイティブのLWOファイルとして保存。ファイル名も box.lwo とか無難なものに。
私は最新版のLightwave 9.3.1を使用していますが、このバージョンのLWOでも、Blenderはインポートしてくれました。

COLLADA形式での書き出し

あらかじめBlenderをセットアップしておきます。
Blender起動時に、すでに余計なモデルやライトが置いてある場合は、[A]キーを使って全選択 → [Delete] で削除できます。
File > Import > Lightwave (.lwo) から、先ほどのLWOをインポート。アニメーションモードに切り替え（下図）、ブラウザパネルで書き出すオブジェクトだけが選択されているか確認し、File > Export > COLLADA 1.4 (.dae) を選択します。

エクスポート設定はこのようにしました。

ポリゴンを三角分割する／選択部分だけ書き出し／UVマップを使用する、の３つにチェックしています。「Disable Physics」もチェックしていいかもしれませんね。
この時点で三角分割しても、テクスチャマッピングがずれる…なんてことはありませんでした／今のところは。でも多角形の分割はあまり利口ではなかったので、複雑な形状は、モデリングの時点である程度分割しておくべきかも。まあ当然ですかね。
＊綺麗な分割でないと、Papervision3Dでポリゴン欠けやテクスチャ歪みが起こりやすいです。

これで、COLLADA形式のモデルデータが出力されます。
COLLADAはXMLで記述されたテキストファイルで、Google Earthなんかでも利用されています。拡張子は「.dae」。

さて、このまま利用してもとりあえずPapervision3Dでは使えますが、私の場合ではテクスチャ画像の参照を絶対パスで行っていたので修正しておきました。
DAEファイルをテキストエディタで開き、該当箇所を相対パスに変えておきます。

<init_from>f:\works\flashdevelop\pv3d\3dmodel_01\model\t_box.jpg</init_from>  （修正前）
<init_from>t_box.jpg</init_from>  （修正後）

（追記）
どうやらBlenderのエクスポートオプションで、「Use Relative Paths」をチェックすれば相対パスになるようです。

Papervision3DでCOLLADA表示

Papervision3Dでは、COLLADAを使用するためのクラスとして、

• org.papervision3d.objects.parsers.Collada;
• org.papervision3d.objects.parsers.DAE;

の２つがあります。
両者の違いは、ロードするときの書式だとか、拡張されたCOLLADA形式への対応状況だとか、オブジェクトのデフォルトサイズとかいったところ。note.xさんの記事にちょくちょくヒントが出ています。
使い方は、まずSWFが書き出されるディレクトリを基準に、COLLADAファイルとテクスチャ画像を移動。そしてスクリプトはこのような感じに。Colladaだと、

//クラスをインポート
import org.papervision3d.objects.parsers.Collada;
//宣言
private var colladaObj:Collada;
//定義して読み込む
colladaObj = new Collada("XXX.dae");
//Scene へ addChild
scene.addChild(colladaObj);

DAEだと、

//クラスをインポート
import org.papervision3d.objects.parsers.DAE;
//宣言
private var colladaObj:DAE;
//定義して読み込む
colladaObj = new DAE();
colladaObj.load("XXX.dae");
//Scene へ addChild
scene.addChild(colladaObj);

基本的な操作は、スクリプトで生成したPlaneとかと同様です。
なお私のモデルでは、同じファイルを扱ってもDAEの方がかなり小さく表示されてしまいました。そこで .scale を 100 に指定してやるとだいたい同じくらいのスケールに。

さてさて、これらをもとにサンプルを作ってみました。
＊ソースファイル Main.as の全文はこちらから参照できます。

技術ネタ | 3d, blender, lightwave, papervision3d | No Comments »