なんか最近のPrejudiceは視聴率(?)急上昇中ですな。平均アクセス数が一日平均130カウントから、いっきに350カウントまで跳ね上がりました。これはもう広告系サイトに移動するか？ま、それはさておき、ねっと飛飛の解析結果によると、いろんな人がご覧になっているのがよくわかりますが、傾向としては、大学経由のものが三分の一、プロバイダー経由のものが半分、のこりは全てメーカーさんというのは暇人が多いのか、仕事の時間に経費を使って小次郎ギャルとか眺めてるひと多数ってことですな。
プロバイダはともかく、メーカーの場合は社名がモロバレなので楽しいですな。日本電装、セガ、スクウェアなど、注目度うなぎ上りです。セガやスクウェアのゲームで、プログレッシブ・ランドスケープとかが採用されたら爆笑するしかないっすね(笑)。まープロの意地にかけて、そんなことはなさらないと思いますが(ねぇ)
さて、そんな視聴率急上昇中のプログレッシブ・ランドスケープですが、どうやらこういうネタを待っていた方は多いらしく、多数(でも三通)のお便りをいただきました。
先日の内容についてのものがメインですね。昨日から、念のためにトップページに「本サイト管理者に対して送ったe-mailは無断で転載する可能性があります」と但し書きをしておいたので、今回メールを送った人は文句を言わないでね(笑)。
まずはおなじみMitamexから前回このページで質問した内容の回答が送られてきた。
清水さんの方法はフラクタルでリアルタイムに地形を生成するって方法ですか？
私は既存の標高データを使うので、あらかじめ何種類かの詳細レベルの地図データを用意しておいて、それを距離で切り替える方式です。１２／２の一番下の図に似てなくも無いです。あれは整然と並んでいますが、視点からの距離（向いている方向も加わる）によって、動的に詳細レベルが切り替わります。うまいこと説明できません。でも、たいしたことはやっていません。
画面写真はないです。コンパイルもできません。x2TrueApexがOpenGLで動いていた時代のものです。いまはDirect3D用になっていて、その過程でいろいろ改良して構造も変わっていったので動かなくなったようです。昔のソースはとってあるのですが、展開してもコンパイルできません。困った。
|
うーむ。なんとなくわかっていう感じかな。御自分で「たいしたことない」とおっしゃるが、中々どうして、すごそうです。
ソースが動かなくなってしまったのは残念ですね。
次、掲示板ではお馴染みの黒田Dycoonさんから
いつも、Prejudiceを読ませていただいている
黒田 Dycoonです。
> ただし、確実に問題となるのは法線ベクトルの生成だ。グーローシェーディングをする以上、
>法線ベクトルをリアルタイムに生成する必要性は避けられない。これについては、まだいいアイディアはない。
>そしてたぶん画期的なものを見つけるのは難しいだろう。
隣の4つの頂点から互い違いに線を引いて、それをベクトルとし、
これの外積を取って、成分を大きさで割ればできそうな気がします。
私自身はやったことがないし、3Dはまだ初心者なので間違ったことをいっているかもしれませんが
黒田 Dycoon
mailto:dycoon@ceres.dti.ne.jp
http://www.ceres.dti.ne.jp/~dycoon/
|
このお便りですが、おっしゃることは間違っていません。だけど、それってごく普通のグーローシェーディング用法線ベクトルの求めかたなんですよね。
僕の言葉が足りなかったのかもしれないけど、問題は、フラクタルでポリゴンを自動生成しながら、グーローシェーディング用の法線ベクトルも自動的に生成するのはキツイなぁってことです。
この問題に関しては、仕方ないのでキャッシュで対応するしかないかなと思っています。キャッシュというか、モロに「法線ベクトル・ランドスケープ」みたいなもんですけど。ただ、もうちょっと頭をひねれば、自動的に(かつ、効率的に)法線ベクトルを生成できないかなぁと思ってます。
|
|
|
|
|
the innovation from KAMIYAN
|
さて、昨日はひさしぶりにお馬鹿なPrejudiceを書いたついでにかみやん大先生に「ごめんなさい怒らないで」メッセージ先制攻撃を仕掛けたところ、かみやん大先生からへんなファイルが送られてきた。
これはもしや勝手に小次郎ギャルとか浮かれポンチになっていた俺に対する報復攻撃？もしかしてかみやん特製小次郎ウィルス!?かと思いきや、単なるgifファイルでした。
かみやんから送られてきたgifファイル
おお、かみやん大先生も似たようなこと考えていたのね！
・・・まぁ今更いってもはじまらないんだけど、同じようなことは考えたんだよねーちょっとだけ。だけど果たしてこのようにビューポートを均一に割っちゃっていいのかなーっていう疑問があった。ある、ありまくる。っていうか、起伏がなければ完璧だろうけど、起伏をつけると単純にはいかないんじゃないかなーと思っていたのです。
でも、確かに、こうすると無駄な描画は一切なくなるので、そういう意味では効率的なんですけど。
だから、かみやん大先生がこういう方法を既に試しているというのはスンゲェ興味深かった。
さっそくICQ的通信手段でかみやん大先生に起伏のついた奴のクオリティについて尋ねたところ、まだ試していないそう。
しかし、さすがかみやん大先生、１２時間もたたないうちにおれのメールボックスにそのデモンストレーションプログラムが！やったぜ！
というわけで、みなさんも実行してみてください。
ちなみにKamyLand.zipの説明文はここに転載してあります(KamyLand.zip自体はここ)。
|
|
|
右がその実行結果だ
ちゃんと実装されているのはよくわかるが、同時に彼が「がっかりした」という言葉の意味もわかる。
通常の状態では、ごく普通のランドスケープ(少し妙な動きをするが)なのだが、ジャンプをすると、いきなり異次元に突入してしまう。
この現象はひとえに「読み飛ばし」に起因するのではないだろうか、
つまり、見えない部分の頂点を「読み飛ばす」ことによって、本来の地表の起伏表現が失われ、地面が流れてしまうのではないかと思う。
ルーチン自体が間違っていないことは、フラットなランドスケープが完璧に描画されることから確かめることができる。
この問題の解消は、いろいろと難しい問題を孕んでいそうだ。
(実際のプログラムの中身をみたわけではないのであくまで仮説だが)まず言えるのは、スクリーン上の座標点からランドスケープ上の座標点に変換するとき、ランドスケープ自体の「高さ」について全く考慮されていないのではないか。だとするとこれは深刻である。
なぜなら、かみやん法(インバース・ランドスケープ)の場合、例えば図中のA地点と交差、描画されるべきところを、実際には平面のB地点と交差したと判定し、C地点の標高データをもとに法線ベクトルを求めることになってしまうのである。
とすれば、視点が地面に埋まるほど低い位置(地表に近い視点)にいる場合は正しい描画に近くなっても、地面から遠ざかれば遠ざかるほど本来の描画とはズレてくることになる。
これではせっかくアイディアが台無しだ。
この方法を改善するには、やはりA地点をなんとしても求める術が必要になるのではないか。その場合のオーバーヘッドはどうなるのか、そう考えていくと、まだまだ検討の余地がありそうである(A地点の求めかたについては、また考えてない)。
でももしこの計算をしてA地点をもとめた上でこういう結果になっているのだとしたら、ごめんなさい(笑)。
|
|
|