3Dを使ったり使わなかったりする制作日誌。
今回も背景のつづきです。
背景はキャラクターに比べて、色々なオブジェクトを組み合わせて
完成させることが多いので、これがなかなか難しいです。
そういえば、よく3Dゲームだとやたらフィールドが広いことが多いですが、
2Dだとドット(スプライト)単位でまとめるのに対して、3Dだと
ポリゴン単位でまとめるので、テクスチャのタイリングを
目立たないように考慮して作っていると、どうしても
背景がだだっ広くなってしまうことが分かってきました。
このまま進めるとMMOのように広いフィールドになってしまいそうなので
これから少し修正しようかと思います。
最近なぜかすごく眠たいのですが、それでもぼちぼちやっております。
鳥瞰視点だとキャラクターの手前の木も高いと、キャラクターが
隠れて全然見えなくなってしまうので、小さい木も作成してみました。
とりあえずテクスチャは使いまわしという笑。
背景、ちょっとずつ出来てきました。
そういえば、最近不思議だなあと気になることがふたつ。
・ひとつはMMD等でみかける初音ミクさんの3Dモデリングなのですが、
なぜか髪の分割数が少ないなあと気になってしまうことです。
腕や足よりも面積が大きいんだから、セオリー通りでいくなら髪の方が
分割したほうがいいんじゃないかなあと、気になってしまう今日この頃。
まあ、好みは人それぞれなので、あれはあれでいいのかな。
・もうひとつは、最近よくみかけるBL系の男の人のデザインに
ついてなんですが、何でどれも胴体が異常に長いのか、
気になってしまう。サラッとした髪や切れ長の目がいいって
いうのはなんとなく理解できるんですが、胴体がすんごく
寸胴なのだけが、よく分からない。。
これだけは、前々から気になっているのですが。。未だに謎です。
BL好きの人や自称BL研究家の方がいましたら、是非
詳しく教えてほしいものです笑。
…あ、ちなみに僕はBLを読んでいる訳ではないですよ苦笑。
○月×日、晴れ。
今日は家のお庭に大きな草がたくさん生えました。
娘も腕を広げて大喜びです。
という一枚。…はい、嘘です。
お庭に崖なんてありません。。あったらいいけど笑。
モデラー上の一枚なんですが、LWはビューポート上では
Zソート描画なのか、半透明のポリゴン描画がうまくいかないのが悩みどころ。
ポリゴンの最適化には便利なんだけど、レンダリングしないと
ちゃんと確認できないのは面倒だな。あと、頂点カラーを
ONにするとなぜか異常に処理が重くなるのもむず痒い。
今回は画像とは少し関係のない話。
サイトに画像をアップするために日にちを確認しようと思い、
携帯の電池が切れていたので充電してみると。。
携帯の調子が悪かったため今まで届いていなかったメールが山のように来た。
まあ、そのほとんどがいつも通りのチェーンメールだったりする訳だけども。。
中には昔の友達が久しぶりにメールを送ってくれたりしたものもあった訳で。。
さらに高校の友達の結婚式という晴れ舞台のお誘いのメールもあって。
とても嬉しかったわけだけど、同時に今の自分がすごく恥ずかしくなって
素直にお誘いに乗ることができなかった。。
この現状をなんとかするために。とりあえず、今は自分ができることをやろうと思った。
少し試したいことがあったので、今回はバジリコの超ローポリモデルの
テクスチャを制作してみました。
試してみたことは、ズバリ。LWで、XSIのGATOR機能のような
マテリアル転送ができるかということです！
以前から、サーフェイスベイクカメラを使うとマテリアルの
透過部分はそのまま前後の近接オブジェクトのマテリアルを
取得しているなと思っていたので。。ひょっとしたらと思い、
それを利用してバジリコの超ローポリモデルで試してみたところ。。
ある程度テクスチャコピーが綺麗にできることが分かりました！！
ただ、UVの範囲外は真っ黒で描画されてしまうので、ある程度
後で修正する必要がありますが、これを利用すれば
プログレッシブモデルの制作はある程度簡単にできそうです。
制作ではプログレッシブモデルの導入は考えていませんでしたが、
以前まで考えていたモーション用頂点バッファの複数確保を行うより、
距離に応じてローモデルに切り替えたほうがメモリ消費を
抑えられるので、こっちの方がいいなと思いました。
ただ…モデリング・テクスチャ制作共に作業が増えます笑。
今日はひさしぶりに昔制作していたバジリコのモデルを修正しておりました。
ウェイトの設定もある程度完成してきたので、さっそく適当に
ポーズをつけて遊んでいたところ、なかなか俯瞰のアングルが
ダイナミックで面白かったので、記念にキャプチャ。
ただ、体のラインを見せようと思ったんですが、スカートを
外すと完全にお尻が丸見えだったので、急遽パンツを作成笑。
なんとなく陸上競技の１シーンのような感じになりました。
お尻の部分は前からウェイト付けがすごく苦手だったので、
綺麗にできて、とりあえず嬉しい。
あとはパッと見で気になるところは足の甲位です。
けど、依然テクスチャが中途半端なのは相変わらずだな笑。
微調節作業は今回も続きます。
今回は、キャラクタのポリゴンを削減したり、テクスチャを修正したり、
ウェイトを1頂点1ウェイトに設定したりしておりました。
キャラクタのポリゴン数は2000ポリゴンから1800ポリゴン以下まで
削減することができました。地球にやさしい１０%カットです！笑
テクスチャも表情を大幅に修正。ちょっとだけ雰囲気が
でたような気がしますが、何だか別人になってしまったというか。
まだ納得いかないですね。
ポリゴン数を削減したことでプログラムがちょっとくらい早くなったかなと、
さっそく試してみたのですが。。前回28FPSだったのが
30FPSまでしか回復しませんでした。
まあ、全体でたかだか1000ポリ分の頂点計算が減っただけなので
こんなものです。1FPSを笑うものは1FPSに泣く、と。
エコといえば。今の鳩山さんの政権、すごい国債発行することに
なるらしいじゃないですか。あれだけ負債をこれ以上増やさないと
謳っていたのに。。
なんだか世界全体の景気は除々に回復してきてるそうなのに、
日本はまたデフレ経済に逆戻りしてるそうで。。
なんだかなあ。何とかならんもんかね。
前回の惨事を踏まえて。頂点ブレンディング数が４つだったのを
減らしてみるとどうなるかという実験を行ってみたところ、
・ブレンディング数4：19FPS
・ブレンディング数3:23FPS
・ブレンディング数2:28FPS
という結果になりました。よかったー、そこそこ回復して。
けどブレンディング数を１にしてみると1頂点1ウェイトに
なるかなと思ったのですが、基本ポーズになってしまいました。。
自分のプログラムなのに、あまり把握できていないという苦笑。駄目だな。
ちなみにこの計算を踏まえると、モーションの毎フレーム計算を
12FPS程度にすれば、一応今のクオリティのままで１０体まで
動かせるということが分かりました。
12FPSとか。。超ギリギリですね。というよりアウト？
そういえば、試しにテクスチャサイズも小さくしたり圧縮テクスチャを
使用したりしてみたのですが。これが全然FPSが変わらないんですよね。
E3Dを使っていたころはテクスチャサイズを変えただけで
ガラッとFPSが変わったりしたのに。。なんでなんだろ？
それと後々になって気がついたんですが。
僕の自作モーション関数はCPUで処理させてるから、それが
一番のネックになってるんじゃないかと思いました。
普通だったら頂点計算はGPUで計算させると思うので。
DirectXでモーションをやる場合、ほぼ９割近くの人は
ID3DXAllocateHierarchyインターフェイスというのを
扱うと思うのですが。ネットで調べてみてもなんだかとっつきにくそうで
今まで避けてたんですよ、こいつ。。けれどこれ以上の
クオリティを求めようと思うと、やっぱり覚えないといけないですね。
まあCPUでモーション計算できたっていうのはそれはそれでよかったかな。
状況によってはCPUよりもGPUの方が負荷が大きくなることもあるので、
状況に応じてモーション計算をCPUとGPUに分散できるように
なれば。。今までやってきたことも無駄ではないはず！
ドドドドドド。
って感じでキャラを複製させようとしてみたのですが。なんと
３体目にして処理落ちが顕著になってしまったので、５対表示中、
モーションを行うモデル数を変えながらFPSを測定してみたところ、
・モーション１体：57FPS
・モーション２体：55FPS
・モーション３体：30FPS
・モーション４体：23FPS
・モーション5体：19FPS
という惨々たる結果になってしまいました…。
うーん。テクスチャサイズが大きいからというのもあるけど、
やっぱりある程度モーションの頂点バッファをあらかじめ生成しないと
駄目なようです。かといって全てのモーションの頂点バッファを
メモリに格納してしまうと、少なく見積もっても300MB以上はいきそうなので、
アイドリング・走り等の指定した基本動作だけあらかじめ生成した
頂点バッファを利用できるようにしようかな。
まあ、結局は容量を考えるとビデオメモリではなくシステムメモリに
格納することになっちゃう訳で。ビデオメモリに転送する手間を考えると
あまり効果がないような気もしますが。。
それと、メインの1体以外のモーションをOFFにした状態で
色々テストしていて気がついたんですが。どうもZバッファへの書き込み
というのはかなり処理速度が重いということが分かりました。
僕のプログラムではメインキャラを一番先に描画して、その後に
順番にオーバーライドモデルを描画してるのですが、メインキャラが
オーバーライドモデルより手前にいる場合と後ろにいる場合では
それぞれ56FPSと40FPSという差がでてしまいました。
これはおそらくメインキャラが後ろにいる場合、メインキャラをZバッファに
書き込んだ後、オーバーライドモデルを描画する際、同じピクセルに
結局また同じようにZバッファに書き込むことになるので
その分のロスによるものだと思います。
なので、一番効率のいい描画順序で行いたい場合は、
前のフレームで描画した際のモデルごとのピクセル数を格納しておいて、
描画する前にそのピクセル数を要素としてモデルの描画順序を
ソートしてあげればいいわけです。
て、まあ理屈は単純なんですが。描画したピクセル数なんて
どうやって取得すればいいのやら、さっぱりです。。
最近になって、少しずつシェーダを勉強し始めてるのですが、
ピクセルシェーダで取得でき…たらいいんですけどね。
まあ、そんなことしなくても単純にカメラ距離でソートする
っていうのもありかもしれない。
モデルをオーバーライド読み込みできるようにしてみました。
よく分からない人のために説明すると、頂点バッファを新しく確保せずに
前に読み込んだモデルのデータを使いまわそうぜ！ってことです。
なのでその分読み込みが早くなります。なんせ、読み込まないので笑。
とりあえずキャラクターを２人表示させてみたのですが、
表示させてみて改めて分かったことがあります。それは、
表情がすごく堅くて怖い…。
こんなゲーム、僕だったらやりたいとは思いません苦笑。
とりあえず、なんとかしませう。
そういえば、UNREALエンジンに続いてCRYエンジンも
アカデミックの場合は無料になったそうです。
まあ、僕は学生ではないのですが。CRYエンジンのサイトを
色々見てみると。やっぱりすごいですね、クオリティが。
色々参考になると同時に、なんだか少し脱帽してしまいました。