たけなか制作日誌

とりあえずいくらピクセル負荷を軽減しても一定以上下がらなかったので
頂点シェーダがFPS低下の根本になってることが分かりました。

それで、どうしたもんかと色々頭を悩ませた末、一度本家スーファミの
方ではどうやっているのかと色々調べてみましたが。。どうやら敵は
画面内に3体までしか表示してできないようにしていたらしいんです。
子供の頃にプレイしてたときは全然気づきませんでしたよ苦笑。

それでさっそく自身の方でも導入してみましたが。これが意外と
違和感無くプレイできます。ただこの手法、例えばFPS視点で
使用すると今まで後ろにいた敵が振り返ってみるとパッと消えて
いた！なんてことになったりするので、鳥瞰視点の操作に
限定したほうがよさそうです。しかしこれでようやく30FPSが
無事に持続できるようになりました。よかったよかった。

そういえば、後から宝箱を取ろうと思って後から取りに行ったら
無くなってた、、なんてこともあったっけ笑。プレイヤーが突然
いなくなってそのまま現れないバグとかあるらしいですが、
それもおそらくこのカリング手法が原因なんだろうなと、ふと思いました。

今まで速度を計らずにトゥーンインクを使用していたんですが、
実はトゥーンシェーディングよりもトゥーンインクの方が重かった
のでした。。(といっても、これはもちろん環境に依るんですけど；)

そこで、ちょっとくらい早くなるかなと思い、if文の部分をif文を
使わずに記述してみましたが、、うーんほとんど変わらないなあ。
現在トゥーンインクを使用した状態で6体以上表示させると一気に
25fpsまで下がってしまうのですが。せいぜい1fps程度向上して
いるような、していないような。まぁ、if文はまだ１つしか使用して
いないので微妙な感じです。

とりあえず、if文を使わない書き方を少しだけメモしてみます。
・aを1.0以上の場合は0.0にループ丸めしたいとき
→端数丸めを使う：a -=trunc(a);
・ブールbによる値切り替えb ? z=c : z=dをしたいとき
→z = b*c + (1-b)*d;

if文くらいだったら使わずに記述できるのかもしれないですね。
というか、そろそろ日記の分類がいい加減になってきました。
今回の分類をC++にしたけど、全くC++と関係ないからなあ苦笑。

モノトーン表示とトゥーンインク機能を新しく追加してみました。

線が入ったことで、ちょっと独特なよさがでたような気がします！
ちなみに線の実装は処理速度を考えて、法線方向押し出しという
一番単純な実装でやってみたのですが。それだけだとカメラからの
距離が遠くなるほど線が細くなってしまうので、今回はカメラからの
距離にあわせて線の太さを一定になるようにひと工夫しています。

それと、今まで導入していたトゥーンシェーディングは重い割に
あまり見た目が変わらないということもあったので…苦笑。
一旦トゥーンシェーディングの機能をOFFにしてみました。画像では
トゥーンシェーディングOFFですが、おそらくトゥーンインクだけで
大分それらしく見えてると思うので、それほど必要でもないかなと
思いました。環境に応じてON/OFFできるようになればいいかな。

ちょっとScreen Space Fluidという技術が目に留まったのでメモ。

なにやらスプライトをZ値、ディフューズ、法線等を別ターゲットで
描画した後、スクリーンスペースでそれらをぼかしてうまく
サーフェイス上にして、合成して流体表現を行うとかなんとか。

法線等をどうやって滑らかにするのかあまり分かりませんでしたが、
成分別の画像を見る限りやはりスプライト単位でギザギザに
なっていますね。。しかし最終画像を見てみると意外と綺麗な
流体が表現できているから不思議！そそられるなあ。

少し前からスクリーンスペースやボクセル表現が自分の中では
旬なのですが。こういう、「ねばねばぶにょぶにょ」したものが
リアルタイム3Dでもっと普及すると面白いだろうなと思いました。

ひさしぶりの投稿ですじゃ。

最近めっきりと日記を書く機会が減っておりましたが、ここ1ヶ月くらいは
プログラムの方を進めてました。え？そんな変わってないって？苦笑

具体的には壁沿い移動、パーティ歩き、それと新しくキャラクターの
位置にスプライトを表示できるようにしてみました！
実質的には壁沿い移動にほとんど時間がかかってしまいましたね…。
ようやく壁抜けしない壁沿い移動を実装できて、色々と反省するべき点が
多かったので以下に少しまとめてみたいと思います。

まず壁沿い移動の実装を考えてみたときに、大抵の方が
真っ先に思い浮かぶのが、
0．壁との内外判定で衝突判定テスト
1．衝突予定の壁と移動線分を順番に衝突判定
2.1で衝突した壁で壁沿い移動
3.壁の範囲を超えていたら補正
だと思うのですが。ここでこのまま思いついた通りにプログラムを組んで、
for(衝突予定リストを順番に) {
if(衝突している) {壁沿い移動;break;}
}
としてしまった場合、なんと。壁抜けが発生してしまうんですねえ；

ここで問題になるのが2の線分と線分の衝突判定での精度の
問題でして。この衝突判定、ちょうど線分の頂点で衝突していた
場合、衝突していないとして返される可能性が高いのです。
つまり、壁の辺の間でぐりぐりと移動していると衝突していると
判断されるべきが衝突してないよウフフ、として判定されるために
壁抜けしてしまいます。

じゃあどうすればいいかと色々と考えてみましたが。このままだと
どうしようも無いので第３者の情報を借りてきてそれと比較することで
解決することにしました。具体的には、現在壁の実装方法は
地面のポリゴンが存在していない部分については壁という風に
実装しているのですが。。この地面の情報を元に、自身の
真下の地面のポリゴンの３辺とまず一度内外判定を行い、
２辺以上外に判定された辺が存在する、且つ１辺が壁の場合は
強制的に２辺で共有する頂点位置に設定することで無事
解決できるようになりました。(他にも色々と条件分岐が複雑
なのですが、ここでは面倒臭いので抜きにします苦笑)

それにしても、これにたどり着くまでに大分試行錯誤してしまいました。
途中「floatからdoubleにすると精度上がって直るかな？」なんて
考えたりもしましたが、現在既にほとんどの関数でfloatによる実装を
してしまっていて変更がとんでもなく大変な上に根本的な解決に
ならないと思うので。とりあえずやる前に解決できてよかったのでした笑。

LW標準のグローがどうも、ニッチもサッチもいかない感じだったので、
ノードを使って表現してみることにしました。

画像の上部分が標準のグローで、下半分がノードによるグローです。
標準のグローだと、どんなに頑張ってもオブジェクトのエッジが
はっきりと浮かび上がってしまうのに対して、ノードで組んだものは
際が滑らかに表現できるようになりました。今回は思ったよりも
効果的な演出になったので、よかったのでした。

意外とすんなりできたので、今度はNode Item Motionを使って
ノードでモーションをコントロールしてみようかと思ったんですが。
これ、自身のモーションパラメータを取得して、また自身の
モーションパラメータに返した場合、計算の基準が分からなく
なってしまうせいなのか、意図した値が入らないみたいですね。。

別の例で、ノードによる法線とマテリアル・スポットノードの
関係だと、先に最終的な法線計算を済ませた後、その法線結果が
ノードエディタの全てのマテリアル・スポットノードに渡されている
といった仕様になっているので、ひょっとしたらNode Item Motionでも
同じように、最終的な結果をMotionノードが受け継いでいて
それで不正なループが働いているのかもしれません。

うーん、なんだかいい方法がないものかな。

ヘッダー画像をまた新しく更新してみました。

フォグ計算だけだと物足りない感じでしたので、ディフューズや
スペキュラ計算も算術ノードを使って独自に実装してみたのですが、
ノードが多くなるにつれて、レンダリング時間もものすごく
大きくなることに気がついてしまいました。。

これはおそらく、ノードには頂点シェーダ/ピクセルシェーダといった
概念が無い(あるソフトはあるのかもしれないが、少なくとも
LWでは無い)ため、計算を全てピクセル単位で行っている、
つまりプログラマブルシェーダでいうところのピクセルシェーダ
のみで計算しているためなのかなと思いました。

LWの標準レンダリングだとどうしても味気ないものになって
しまいますが、ノードで全て計算してしまうと正直いって重く
なりすぎてしまいます。今回の画像だと、ノード無しの場合
数分で済んでしまうところがノード有りの場合１時間もかかりました。
うーん、こりゃ考え物だ。ノード計算もほどほどにしないといけませんね苦笑。

SIGGRAPH2010で気になった技術の動画を少しまとめてみようと思います。

・Technical Papers Trailer

テクニカル系のまとめ動画。これひとつでうれしい。

・Programmable Motion Effects

カートゥーンで多用される、線によるモーションブラー表現。
PS3ナルトでは静的生成でしたが、こちらでは動的生成してます。

・Discrete Scale Axis Representations for 3D Geometry

3Dオブジェクトから自動的にボーンを取得するための技術。
スケーラブルな境界球を用いて作成しているみたいです。

・Matching Fluid Simulation Elements
to Surface Geometry and Topology

動的なサーフェイスによる流体シミュレーション表現。

ついでなので2009年度のものもまとめ。

・Motion Field Texture Synthesis

テクスチャによるパーティクルのモーション制御。
デザイナにとっては、こういう技術はかなりうれしいと思う。

・Deforming Meshes that Split and Merge

3Dオブジェクトを粘性のあるサーフェイスとして変形。

お次はEuroGraph2010の動画を紹介。

・Fast and Efficient Skinning of Animated Meshes

ソフトボディシミュレーション結果を元に近似のボーン＋モーションを
作成するという、まさに逆転の発想技術。

SculptrisのマテリアルテクスチャをそのままLWで使えないかなあと
前々からへんてこな願望を抱いていたので。とりあえずノードで実装
してみることにしました。

実装のアルゴリズム自体は以前HLSLでトゥーンを実装したときと
ほぼ同じなので、始めのうちはすぐに出来るだろうと高を括って
いたんですが、予想以上に手間取ってしまいました。

後になって、「そういえばDirectXとUV座標系が違ってたり
したんだっけ」ということを思い出したのはよかったんですが、
それより前に、いじる必要の無かった部分を余計にいじって
しまったのが長引いた原因でした。。痛いなあ。

それと実はまだ設定がおかしいのか、テクスチャの見え方と
少し違うUVのマップ位置になっていたりします。実装の説明を
少しすると、法線が外を向いているほどテクスチャの外側を
利用するのですが、その外側のとる領域が予定より小さくなって
しまっています。まぁこれくらいならば、ほとんど気にならない
程度なので、個人的にはこれで満足です。

とりあえず出来てよかったのであった笑。

この日記のヘッダー画像を新しいものに変更してみることにしました。

実は前まで使っていた画像は、個人的にはヘタクソなりに
結構気に入っていたり、思い出深いものがあったりしたのですが。
最近になってもう少し綺麗な画像で魅せていかないと、なんだか
駄目かもしれないと思い始めていたので、とりあえず今日作っていた
画像が運良くヘッダー画像に使えそうだったので、さっそく
使ってみることにしました笑。

ちなみに画像の元々の素材はここからお借りしました。
なんだか、自分でも見慣れない感じになってしまった苦笑。
自分で作った画でヘッダーに使えそうだったら、またすぐに
変更するかもしれません；