書籍には載っていない３Ｄ技術

書籍には掲載されていないけれども、実際には
良くぶつかるであろう話題など。

巨大ポリゴンのカリングはみなさんどーやってます？

視野座標系に落とした段階で
(a)視野四角錐で奇麗に切り取っているか？
(b)あるいは Z=0.0 平面で切り取るのみか？

ラスタライジングが賢ければ (b) で十分なのですが、
描画領域からはみ出したポリゴンでも左上だとかだと、しっかり
描画時間が食ってしまうタコなハードもあります（PS1とか以外にも）

うちは今、PS2で開発していますが、単純に 平面 z=0 で分断しています。
問題は全てのポリゴンにおいて、分断必要チェックをするわけには行かない
点ですね。（内周なだけに、zチェックだけでも痛い）
分断が必要そうなモデルと必要なさそうなモデルとで、ルーチンを２種類用意しています。

ただPS2でも明らかに分断していない市販ソフトがたくさんあります。
例えばファンタビジョンなど手前に来たポリゴンはポリゴン単位で
がつがつ消えていきます。
ゲームの用途に応じて使い分けるのが主流だと思います。

英語の書籍には載ってる技術じゃん

もっと進めるなら、階層的なBounding geometryを使って視錐体との交差,
包含判定をして、カリング、クリッピングが必要な面のリストアップなんかを
しますね。
クリッピングもTriangle stripを直接クリッピングする技法もあるし。
5氏のいうように日本語に限定せず資料を探すことをお勧めします。

ソフトウェアラスタライザで、パースペクティブコレクトを実装するとき、
1/z,1/u,1/vを32bit固定小数点で精度を維持する方法はありますか。
私の場合、精度不足に悩まされて
結局1/z,1/u,1/vは浮動小数点で持つことになりました。

間違い、1/z,u/z,v/zね。

>>2
>(b)あるいは Z=0.0 平面で切り取るのみか？
本気すか？
どうやって描画するんですか？

>>9
ゼロ除算になっちゃうよね（藁
普通Ｚ=1.0平面辺りで切り取るでしょ。

＞英語の書籍には載ってる技術じゃん
日本語の書籍きぼん！英語読めないし。
というかなんで国内の書籍って知ってることしか書かれてないんだろう

＞もっと進めるなら、階層的なBounding geometryを使って視錐体との交差,
＞包含判定をして、カリング、クリッピングが必要な面のリストアップなんかを
＞しますね。
ちなみに、モジュール単位ではなく、面単位の洗い出し？

>(b)あるいは Z=0.0 平面で切り取るのみか？
Ｚ=0.0付近という意味でわ？

でも視錐体によるカリングって実装したことないです。
やっぱおいしーのでしょか？

>>もっと進めるなら、階層的なBounding geometryを使って視錐体との交差,
>>含判定をして、カリング、クリッピングが必要な面のリストアップなんかを
い？ほんとですか？例えば数千ポリゴンからなる人体モデルが画面の端で半分
くらいしか見えてない状態で、カリングが必要なポリゴンだけ奇麗に洗い出せる
ものなんですか？

>>13
人体モデルといっても、手や頭など複数のパーツで構成されているでしょ。
パーツごとにバウンディングオブジェでまず交差判定をすれば、
かなり効率は上がるんじゃないの。

カリングとかでピックアップされたもの、とか、半透明時にポリゴン単位でソートしたリスト
とかって、どうやって管理してますか？

最悪時を想定すれば画面に出てるポリゴン数の数倍の枚数に分割されたりしますよねぇ？

＞パーツごとにバウンディングオブジェでまず交差判定をすれば、
＞かなり効率は上がるんじゃないの。
それはつまり、ブロック単位でのカリングでは？
そのブロックがカリングされる可能性がある場合、そのブロック内に
含まれている全てのプリミティブがカリングチェックを施すわけですよね？

＞最悪時を想定すれば画面に出てるポリゴン数の数倍の枚数に分割されたりしますよねぇ？
最悪でなくても結構あるシチュエーションだったりして悩みのタネです。

ところで半透明プリミティブはソートリストに登録せねばなりませんが、
要カリングプリミティブってどこかに保存しなければならないものなのですか？
その場で細切れにしてラスターに送り込む以外、考えられないのですが。

>もっと進めるなら、階層的なBounding geometryを使って視錐体との交差,
>包含判定をして、
矩形外に対する２Ｄラスタがそこそこ賢い環境（例えばPS2）の場合、
視錐体との交差でカッティングする必要性ってあるのでしょうか？
でかい２Ｄプリミティブを送り込んでも、矩形外フィルレートって
無料でしょ？だったらz平面カリングで十分のような気がします。（というか
うちの職場のＰＧではこのスレを今朝見るまで確信していて ^^;）

カリング演算コストやらカリング結果によるプリミティブ容量が増えてしまう
視錐体との交差カッティングって損するばかりのような気がするのですが。

>>11
この期に読めるようになりましょう。専門用語はほぼ英語で見聞きしていると思うので、わりと読める
もんですよ。共通日本語の書籍で得られる知識はどうしても限られてしまうと思います。
もちろん良書があれば紹介希望です。

>>12 13 16
16氏の解釈がこちらの意図に一番近いと思います。
極端な話、1ポリゴンに1Bounding geometry(BG)に対応させれば13氏の言うように要クリッピング(視錐体
平面によるポリゴンの切断処理)ポリゴン、カリング(描画処理の省略)ポリゴンのリストアップができます。
が、これは速度 空間ともに良くないでしょう。
普通は14氏の言うようにパーツ単位とか、数10ポリゴンに1BGに対応させたりするようです。
BGによって求めたクリッピング要 不要に基づいて、3氏のように描画ルーチンを切り替えるのが良いようです。

>>18
PS2なんかでは、Z near平面でのクリッピング以外はあまり必要ないと思いますね。測定はしてません。
表示シーンにもよりますが、カリングは大量の幾何演算を省略できるので、有効だと思います。

を！いつの間にこんなおもろそーなスレが！

でもカリングなんてどーでもいーっす。
今、コンシューマ業界のＰＧの頭を傷めているのはGSのVRAMの少なさでしょ？
さて、どうしましょ？

デザイナーに「全てのテクスチャを16色で書け。なら結構な面積あるぞ」と
押し切ろうとしているチームがあるよ。
頭わるそーだけど、これこそが最良の解決手段かもしれない。

いや、本当に頭悪いのはPS2の開発者連中なんですけどねぇ。
彼らに「バランス感覚」ってものがあるんですかねぇ？

>>21
16色にすると、Mipmapで困りませんかね?

PS2でMipmapって自殺行為かも。

パースペクティブコレクションってどうしてる？
ハード任せ？

>>24
ゲーム業界ではない方ですね？

現状、ハード任せです。
パースペクティブのみであれば、CPUで描画してもなんとかなるのですが、
バイリニア、アンチなども世間が要求していることを考えると、
ピクセル描画はハードにせざるを得ません。

描画処理に関しては
CPUと専用ハードの性能差は常に極端に開いています。

>>24
俺の場合、近隣のポリゴンは未だに分割してる・・・。

>>26
ＰＳ１、サターン時代のなごりですか？

最近のハードは賢そうだなあ……。

>最近のハードは賢そうだなあ……。
いや、ゲーム業界では昔からハードは常に賢かったっす。
用途を絞った専用ハードにはソフトでは絶対に勝てないです。

ＳＣＥＩな人がココを見ていることを希望して、カキコ。
まじ、GSの容量を16Mだとか32MにしたPS2のリビジョンアップ、真剣に検討した
方がいいっすよ。あんな描画速度いらねーし、そんなVRAMじゃ描画できねーし。
だから、連射できないマシンガン なんて呼ばれちゃうんだよ〜
一度に装填できる弾数が少なすぎ。ドキュソ

次世代機なのにClippingのコストを考えなくてはいかんとわ

いや、だから考えなくていいんぢゃない？

>>31
クリッピングコストは無料だってば。

PS2のテクスチャ容量の少なさを世界中のPS2ソフトメーカは
頭を傷めている。

>30

　ま、今更言い尽くされた事だしね。今から対応されても
しょうがないよ。完全な設計ミス過去ハード。

　やっかいなのはやり様によっては凄いポリゴンが出せたり
する事。Demoっぽいところならリソース制限かけて極限まで
使いこなせるけど、いざゲームパートになるとショボーンな
事しか出来ない。で、ユーザもその落差が理解できずにプロ
グラマの腕が悪いと思い込む。む、おれもドキュソだな。

　ま、しかしある程度以上ポリゴンが出せるなら画面の質は
デザイナさんの技量が全てだわな。ちょいツマラン。

>>27
現在進行形でPS1の開発ということでは？

>>30
今度出るゲーセン用PS2は増えるらしいですねぇ。
PlayStation2SuperGraphics (ﾌﾟ

>>36
4本しかソフトでなさそうな名前だな・・・

>>36
マジですか？　３２ＭのＧＳってチップだけで数十万するんじゃ
ないのかな？　そんなの出せるメーカーって・・。Ｔ社か？

確かにPS1時代も、ナムコからPS互換基盤 System11 が出てて
主な違いはサウンド周りとVRAMが2倍になったこと。
けど、あの基盤、いまいちその実力を発揮しなかったね。
VRAMも実は1Mだけ使ってたりするソフトが多かったらしいし。

当然だよね。
アーケードからコンシューマへの移植が困難になるだけだし

え？国道２４６がどうしたって？

ところでみなさんにとってＤＣってハードはどうでした？
開発した人あまりいなさそうですけど

↑アーケードＤＣ基盤にて下請け開発経験が一度だけありましたが
現状、PS2をも凌ぐ最強のハードウェア

圧縮した状態でテクスチャを置ける上に、その容量は8Mと、VRAMの
サイズが豊富。
結果的にミップマップも現実的に可能。

また、テレビの解像度は640*240なのだが、640*480でレンダリングし
色補完で640*240を毎VS、生成しても無傷。

これらと同じことをPS2でやろうとすると、VRAMがまるで足りなくなり
痛いどころか致命傷。ミップマップは可能であるものの、VRAMを圧迫
する上にキャッシュシステムを構築しても、CPU<->VRAM のバスをさらに圧迫
してしまう。
現状、PS2でミップマップを使った市販ソフトがほぼ皆無な理由。

ただ、あくまでも現状ＤＣ最強なだけ。
PS2も上手な使い方が見つかれば、そのうち逆転すると思う。

あと、テクスチャがVRAMに置ききれるという条件下だと
PS2の初期発表のような画像が生成可能。

>>38
16Mバイトですな。
http://www.zdnet.co.jp/gamespot/gsnews/0102/21/news03.html

>>42
どんだけ凄いのかと思っちまったよ。
PS2が酷すぎるだけじゃねーか。
テクスチャ圧縮?ミップマップ?640x480?何がどう最強なんだ?
それならまだxboxの方がよっぽど強力じゃん。まだ出てないけどさ。

出てなければなんとでも言えるわな(藁

お値段いくらになるかもわからねーし。
って、これハード・業界板行きだな。
http://cheese.2ch.net/ghard/index.html

もう出てるNV20でも楽勝だわな（ｗ

うーん。みんな語気が強いのは結構なんだけれど
テレビゲーム機叩きは他所の板で楽しんでくれな。

＞もう出てるNV20でも楽勝だわな（ｗ
そこが素人の陥りやすい罠なんです。
数多くの２Ｄ描画プリミティブコマンドをMainRAMから2Dラスターに
送り込むその転送量こそがネックになる時代なんです。
いくらラスター側が強力でも、コマンド転送が遅ければそこでネックになるわけです。

ハードウェアというのはあくまでもトータルな性能でみる必要があり
NV20だのたかがラスター単品で決まるものではありません。
もちろん、最近はビデオカード側にも最近はラスター以外にも
ジオメトリエンジンを搭載するようになってきていますが、CPUから
離れたところにあるぶん、融通も効かなくなります。

NV20は曲面描画できるよ

>>42
ただ、DCはフィードバックやブラー系のエフェクトに弱いよな。
半透明機能も使う分にはお手軽なのだが、パフォーマンスがでない。

PS2は癖ありまくりだけど、使いこなせればポテンシャルは
非常に高いハードだよね。

>>49
転送量を減らすためにハードウェア頂点バッファとか
曲面がつかえるようになってんだろ（ｗ

つかねー、コマンドとかの転送がネックになってんなら、
ラスタライズには逆に余裕が出るってことなんだけど。
ミップマップとか高解像度とか、ラスタライズに
負荷をかける処理をしても、他がネックになるなら早さは
変わらないってこと分ってる？

＞ミップマップとか高解像度とか、ラスタライズに
＞負荷をかける処理をしても、他がネックになるなら早さは
＞変わらないってこと分ってる？
あの〜質問なんですが、ミップマップがなぜ速度的な負荷になるのでしょうか？
DC(PowerVR)にせよPS2にせよ基本的にはノーペナルティです。（ミップマップの定義にもよりますが）
ミップマップして痛いのはVRAM容量を圧迫することくらいでは？
（※nVidia系も本家の資料を見る限りではノーペナルティっぽいが未確認）

＞つかねー、コマンドとかの転送がネックになってんなら、
＞ラスタライズには逆に余裕が出るってことなんだけど。
ラスタへの大量なコマンド転送がもたらす最も大きな懸念は
MainCPUのバスをも封じ込むことでしょ？
コマンド転送をしている間、CPUは次のFrame作成の処理の
真っ最中なわけです。バスがDMAによってロックされている間に
発生したCPUのR/Wは、全てブロックされるのが、一番の懸念材料。
かといって、ハードウェア頂点バッファでは融通が効かないことが
しばしばなんですよ。UVアニメ、頂点アニメ、環境マッピングなど。

書籍には載ってない現場のノウハウの話をしてくれ〜

ちょっと疑問なんですけど、

＞しばしばなんですよ。UVアニメ、頂点アニメ、環境マッピングなど。
ハードウェア頂点バッファでできません?

>55

その為の頂点バッファですよねぇ・・・。
８からは頂点シェーダーも付いたし。
転送量がネックにならないように凄く神経を使ってる仕様だと
思うけど＞DirectX8

>56
頂点シェーダー使ったら,
アニメーションや環境マップなんてお手の物ですよね.
頂点シェーダー無いなら融通効かないことも多いけど.
# できないって意味じゃなくて融通効かないって意味ね.

ところで、頂点シェーダーって、
・スキニング（頂点のブレンドなど）
・TexGen系（テクスチャ座標のアニメーション、環境マップなど）
・ライティングのカスタマイズ
・タンジェントスペース系セットアップ（PerPixelBumpmapの下準備）
以外になにか面白い使い道あります？いや、これだけでも組み合わせ
によってはいろいろと便利そうではあるんですが…。

>>55
アニメってのがミソなんじゃない？
頂点固定な場合は最初にハードウェア頂点バッファに転送しときゃ後々
バス占領せんけど、毎回頂点CPUで計算して頂点バッファに送ったら…
てな事を53は言いたいんじゃないかな…。
>>57
頂点シェーダーってアニメにどの程度使えるのかな…。なんでもかんでも
こなせるとは思えないけど…。詳しく勉強してないから想像なんだけど＜ボケ

>>59
だからスキニングアニメーションや頂点アニメーション,
UVアニメーションとかをハードウェア頂点バッファで
効率的に実行するために頂点シェーダーを使えるんですよ.
例えばスキニングなら行列（ボーン）だけを,
頂点アニメーションならウェイトだけをCPUでセットすれば済むんです.
頂点単位で固定にできる情報は全部ハードに置いとくんですよ.
そりゃ万能って訳ではないんだけど,これでも相当のことができますよ.

>>58
他には高さを基準にする等のカスタムフォグとか.
自分の好きなデータを好きなように加工できるから,
他にもいろいろ面白いことはできそうですけど.

ピクセルシェーダが可能な環境なまだない上に（ほぼ皆無）
自分の場合、ペーパー知識でしかない（商品化経験ゼロ）ので
コメントなしな状態。実際に使ってみてメリットもデメリットも
出るものなんで。

どちらにせよ、頂点バッファを使ったソフトってテスト実験デモも
含めて極めて少ないんでよね･･･

ピクセルシェーダとバーティクスシェーダは別物ですわ。
バーティクスシェーダなら現段階で大半の環境で動きます
よ？

　どちらにしても特に凝った事を考えない場合DirectX8の
頂点シェーダ仕様で事足りるんじゃないかと。
　ディスプレートメント系は駄目なのかな？（無知

>>61
頂点バッファなら、以前から使えますし、DirectXのソフトなら
今では結構一般的につかわれているような気がしますが…。

既存スレの経験から用語を統一した方がいいような。

>>62
ディスプレースメント系は現在のPixelShaderでは無理だと思います。
Shaderと聞いて私もそういったPRMan的なものを想像していたんです
が、どうやら、テクスチャステージのプログラム的な柔軟性をもたせ
たものと考えてよさげなきがします。

texkillとか、使い方によっては面白いエフェクトを実装できそう
（たとえば、PowerVRのモディファイヤボリュームみたいなやつとか
できそうな気がする）な命令もあるんですけどね…。

PS2のミップマップが痛いワケ

VRAMの容量が厳しくなる、というのもひとつの理由だが、
ミップマップによって、GSの描画時間が減る可能性があること
を考えれば、決定的な理由にはならない。ミップマップに
よって得られる品質は、無視できないし。

それよりも、GSがアニソトロピックフィルタをサポート
してないことが大きい。これと同じ効果を出すためには、
VUレベルで処理する必要がある。すると、VUはすぐに悲鳴
をあげてしまう。ポリゴン数も抑えなくてはならないくなる
ので、非常に痛い。

＃使えるとするなら、レースゲームくらいじゃないだろうか。


MGS2の体験版。テクスチャの多くは16色。512*512を3枚使って、
テクスチャ領域は1MB。割り切った使い方をしたものだ。
あんな作り方をしたら、お金がかかるだろうに。

MGS2を見た業界関係者は、色々な意味で暗くなってることだろう・・・

>>65
ほんとの意味でのディスプレースメントじゃありませんけど,
高次サーフェスとかNパッチで生成した頂点を何らかの情報で
いぢくってやれば（VertexShaderで）,
ちょっとは似たようなこともできそうです.

別に高次サーフェスじゃなくてもいいですけど.

＞ミップマップによって、GSの描画時間が減る可能性があること
＞を考えれば、決定的な理由にはならない。
逆、逆。
PS1の時もそうだったけど、ミップマップすることによって処理速度が
劇的に向上することもあるんですよ。テクスチャキャッシュヒットの関係で。

PS2のGSのVRAMは混載RAMだから、4M全部がキャッシュだというのは誤解です。
GSにはあの4Mとは別にさらに高速なキャッシュも搭載しています。
ミップマップすることで処理速度が高速化される可能性が十分にあるわけです。

>>68
個人的には、ミップマップ使ってＧＳのキャッシュにヒットしやすく
なるメリットより、ミップマップでテクスチャサイズが増えた事に
よってＶＲＡＭへのテクスチャ転送が増えるデメリットのが大きそう
な気がする。

＞MGS2の体験版。テクスチャの多くは16色。512*512を3枚使って、
＞テクスチャ領域は1MB。割り切った使い方をしたものだ。
↑あ、そうなんですか･･･やっぱ、頭わるいよーで、実は賢いかも。
でも、それって、優秀なドッター職人がいるメーカでないときついよねー。
処理速度を一番稼ぐのはPGではなくドッターなんだよな。

GSのメモリが少ないことが叩かれる原因になっているけど、
混載RAMすら搭載できない NV系ではキャッシュヒットが命だよね。
参照される全てのテクスチャが特定矩形内に納まっていると
フィルレートはGSの1/3にまで達するわけだし。

あのーＭＧＳ２のＶＲＡＭ使用状況ってどうやって分かるんですか？
他のＰＳ２タイトルの利用状況も参考にしたいのでよろしくです

>>68
描画時間が減る＝描画が高速化される
という意味だったのだが、書き方がまずかったかな？

それを踏まえた上で、69が書いてあることと同じ
考えを持っている。

実際のゲームでミップマップを利用する場面といえば、
大きなフィールド内を歩き回るようなものが考えられる。
試してみれば分かるのだが、地面と正面の壁で、あきらか
に見栄えに差が出る。ポリゴンが傾くことによって、
サンプリングされるテクスチャの間隔が大きくなるからだ。
私の感覚だと、許せる範囲ではなかった。GSのフィルレート
よりも、むしろVUの処理能力がネックになっているPS2の
現状を考えれば、ミップマップによる品質向上を期待する
ためには、ポリゴン数を減らす、という品質低下を要求される。

品質を向上させるための方法はミップマップだけではない。
PS2の特徴を生かした方法を使えば良い(GSのフィルレート)。

ほとんどのメーカは同じ結論に達しているはず。

>>70
つたない文面から、私の言いたいことを汲み取ってくれて
いることに感謝。私もあなたと同じような感想を持った。

>>71
会社の人に聞きなさい。別に難しいことは何もやっていない。
あなたが想像している通りのことをやっただけ。あなたが
今間で真面目に開発に取り組んでいたなら、それを実行するのに
１時間もかからないはず。結局は自分の会社(開発規模)に
合ったスタイルを見つける必要があるので、それほど参考には
ならないだろう。

参考にするなら、GT、鉄拳TT、MGS2あたりが良い。
鬼武者は見てないので知らない。

>72

　71じゃないけど、テクスチャ総量なんかソフト見ただけ
じゃわかんないと思うけどなぁ。一応真面目にGS飼いなら
してるつもりですけど。
640＊480＊4（32Bit）＊２＋640＊480＊２(ZBuf-16Bit)
って計算かな？

>>73
総量はわかんないかもしれないけど、一瞬一瞬のＶＲＡＭの状況は閲覧
プログラムをちゃちゃって組めば見れるわけだし。
いろんな場面で見てみれば、だいたいのそのゲームでの使い方はわかり
ますよ。

>>73
74が書いてある通り。

MGS2は512*512*4(場合によっては24Bit)を表示レンダ用に2枚。
Zバッファについては512*512*3(上位8Bitはテクスチャ領域)
残りの1MBがテクスチャ領域になっている(厳密に言えば
テンポラリ領域と言った方が良いか)。

全ての場面で当てはまるわけでは無いが、まずキャラクタを
レンダリング。その後背景。そして、半透明を使ったエフェクト。
この３つの処理で構成されていると思われる。
リアルタイムムービーでは、さらにフィルタ系の処理
も行っている。

処理の過程をステージとみなして見ると、テンポラリ領域の
使い方が簡単に推測できる。そのステージの切り替わり時で
ザックリと入れ替えているのだろう。

お金がかかるだろうに、と書いたのは、シーンの作り方に
大量のマンパワーを感じから。16色のテクスチャ
であったり、フィルタ処理のために、一度レンダリング
した結果を、テンポラリ領域にコピーしたり。

しかし、ユーザはそんなことは分からないわけで、
MGS2がやってるのにできないはずがない。企業努力
が足りない、などと言うわけだ。

中小企業に、そんなところまで時間とお金を割く余裕が
あるわけないだろうに。やってることが分かっても、
できるかどうかは別次元の問題なのだから。

#あれを全て自動で最適化されてるなら話は別だが、
#そうはみえない。

これを見て暗くならないなら、その根拠が知りたくなるよ。
(VRAMなんか覗いちゃったよxxx)

＞しかし、ユーザはそんなことは分からないわけで、
＞MGS2がやってるのにできないはずがない。企業努力
＞が足りない、などと言うわけだ。
実際、できなかったら企業努力が足りないのかも.
16色ゆうてもバイリニアフィルタかかるから、文面ほど
ちゃちくならないんだよな.（ただし職人が書けば）
実作業は実写なり取り込んだものを減色するんだけど、16色とも
なると手修正が絶対必要だし.
こんな状況下で、segaがps2業界に参入となると、さらに脅威

segaの出すプロダクトが世間では標準レベルと認識された瞬間、
逝ってしまう企業続出だろうな

３Ｄモデル作る人でも「厨房」と「職人」がいるよね。

「厨房」だと、モデラーが持っている球面マッピングなどでベタ！と
張って、はい納品。

「職人」であれば、ポリゴン一頂点単位でUV修正。
例えば、帯などの表現も、本当に帯のテクスチャを貼り付けるのではなく、
横幅1Dotのテクスチャを引き伸ばして貼ったり、地の色で済む場合は
テクスチャ貼らずに、カラード生ポリゴンにしてみたり。

vu1 はイッテヨシ。あれなくても、意外となんとかなるよ。
うちら零細組はミドルウェア買う金もないんでね。
EEとvu0だけで自力で頑張るのさ。
あ、ついでだから ps2 ごとイッテヨシ っていうのは禁句ね。

ps2がなくなると、もううちらゲーム屋の市場がなくなるのよ。
任天堂の外様は特に。もう、ライセンスのラの字も貰えないんです。

3DMark2001を見て非常に鬱だ。
結局はマンパワーの所産らしいのは、ありがたいのかそうでないのか。

3dmarkはメガデモ系のフィンランド人が小人数で作ってる。
マンパワーではない。

>>78
さすがにＶＵ１無しでなんとかなるとは思いません。
その考え方あんまりですよ。

やはりゲーム業界は時代と逆行しているような気がする。
職人1人よりDirectXで妥協出来る奴10人の方が良い。

＞DirectXで妥協出来る奴
？？極めて意味不明なんですが。
DirectXで妥協･･･とは？
これは、PC/ATで妥協という意味ですか？

>>83
82ではないけど、ＰＳ２のようなＶＵアセンブラでガリガリとか、ＤＭＡ
スケジューリングでガリガリとプログラム組むのは、世間一般のプログラム
思想の流れとは逆行してるでしょ。

失礼ながら、ここ読んで納得しました。
「だからＰＳ２のソフトは大したことがないのか。」

それはココの会話レベルが低いという事か？
「失礼ながら」ってことはそうだよな？

>さすがにＶＵ１無しでなんとかなるとは思いません。
>その考え方あんまりですよ。
今、発売されているかなりの市販ソフトがvu1を一度も叩きません。
あと某社（ミドルウェアライセンス）の発表しているOpenGLも
vu1を一切叩きません。

EE(300MHz)+vu0 の組み合わせで、そこそこ行ける、というより
現状、最強の汎用演算装置だし。やっぱレジスタがあれだけ豊富に
あると、x86陣営では歯が立たないことはx-boxで実感。
だからこそ、融通性を削ってまで、頂点バッファをVRAMに逃がしたわけ
だし。（でもなぜかx-boxではVRAMには逃してないらしい）
ハードウェア頂点バッファ(in MainRAM)演算時にMainBUSがロックされて
いるか否か？なんてDirectXからじゃ絶対に見えないし。

んにゃ、実際のホンネとしては３Dエンジンなんかカリカリ組んでる間に
ゲームの部分作りこみたいんだよね。いや、最初のうちはパフォ上げるの
にワクワクしたけど、もう飽きた。DirectXでいいよ俺は。

あと、77氏のカキコみて思ったけど、デザイナにリソースポイントが渡っ
てる時点でプログラマの苦労なんて意味なかったりするんだよねぇ。
いや、16色で頑張ってくれてるのは解るけどさ。

>ＰＳ２のようなＶＵアセンブラでガリガリとか、ＤＭＡ
>スケジューリングでガリガリとプログラム組むのは、世間一般のプログラム
>思想の流れとは逆行してるでしょ。
ＤＭＡのスケジューリングといってもガリガリ、ややこしいことは
ではないですし、ＰＳ２固有の問題でもありません。
あとピクセルシェーダなど、最近は再びアセンブラをプログラマーに
さらけ出す傾向があることは確かです。（PS2環境ではないですが）

＞世間一般のプログラム思想の流れとは逆行してるでしょ。
３Ｄ描画にはプログラム思想のみならずハード思想の多少の理解を
必要とされているから、一見、逆行しているように見えるのだと
思います。

ＰＳ２市場はなぜこれだけ冷えているか？

これは、ゲームのアプリをデザインする前段階の
ブラックボックス作成に時間を賭かりすぎるからだと思う。

>>90
ゲーム関係の掲示板は、ふざけた悪口ばかりなので開発者は
いたたまれないでしょう。

でも、やはり画像で凄いなぁと思うことが少ないのは買う側
としても辛いです。
ナムコなどの大手と、大手ではない所の差がこれほど大きい
とは愕然としてしまいます。

>91

　一番痛いのは画像が凄い事が売上に直結しなくなった事。
作り手としてどこに力を入れるべきか見失いがち何でしょうね。
難しいもんです。

＞一番痛いのは画像が凄い事が売上に直結しなくなった事。
ですね。でも直結しなくても、とりあえず画像はそれなりに
凄いことしとかないと、流通がイニシャル渋るんですよね。
で、流通に渋られると雑誌媒体からも足元見られて、露出度も減ってしまって
悪連鎖。

ＲＰＧやなんかでデバッグモードでいきなりクライマックスの魔法イフェクトを
敵にぶつけるデモを無理矢理見せたり、それはもう大変です。

みなさん応援してますので頑張って下さいね。

Quaternionの勉強でいろいろ探していたら、
こんなの見つけました。
http://www.gamedev.net/reference/articles/article1199.asp
「ホントにQuaternionって必要なの？？」で、
「いらないっしょ？ つーか数学の歴史的に見ればQuaternionは敗者で、
ベクトルと行列使った代数が勝者っしょ？ プログラマーってアタマ悪いね（藁」
って内容だと思います。（英語弱いんで自信ないですが・・・）

この内容ってどうなんでしょ？
やっぱり皆さん使ってるんですよね＞Quaternion
がんばって勉強するしかないのかなぁ・・・

Quaternionはいらん。

>>96
そうはっきり言い切ってもらえると、ちょっと安心です。
でも、やっぱり流行ってるっぽいですからね＞Quaternion
流行りモノには弱いからなぁ・・・

Quaternionは流行りモノじゃないよ。
数学では知ってて当たり前の概念。

>数学では知ってて当たり前の概念。
そうなんですか？
今まで理系一筋だったんですが（情報系ですが）、
クォータニオンは最近知りました。3Dの勉強中に。
「知ってて当たり前」ってのはどうかと思うのですが・・・

しかし、クォータニオンについての日本語の書籍やwebページって
少ないですね・・・お勧めの本やwebページありましたら
教えてください。（日本語がいいです）

あああ、、、検索すりャいいだけっすね・・・
あ、でも、お勧め！ってのがあったらお願いします・・・

数学の歴史でQuaternionの発見は大事件。

地球物理の授業ではよく使ってたな<クォータニオン

真相を教えてくれ。っていうか、そういえば数学板かなんかあったっけ？
今忙しいので誰か話題振っといて。

数学板は大間違いな答えを堂々とかいてることがあるんで注意
だれも読んでないのか正しい答えを書かないのも異常だが・・

>>96
Quaternionを使わずに、
ジンバルロックを回避する方法を教えてくれ。
ついでにslerpも。

>>105
任意の回転軸周りの回転行列を活用しませう

>101
よく知らないから、ネタだと思ってしまうのだけれど、
それは本当なの？

>>106
それ、既にQuaternionの概念が入っていると思うんだがどうよ？

私ヘタレでQuaternionよく分かんないので、
使わないでいいものなら使いたくないにゃー（苦笑）

>>109
安心せい、それはほとんどのヤツが思っていることだ。

>>107
本当。

>>108
入ってるがQuaternionを意識しなくてよい。

クォータニオンは覚えたけど使ってない。

そんなにQuaternion難しいか? なにが難しいのか説明してくれよ。

使うだけならむづかしく無いけど、理解不能
文系のオイラには ２乗でマイナスになる虚数ってなによ って感じ

虚数っていう日本語訳自体わかりにくいような。
英語だと imaginary number だべ。

どうせ座標系の概念も完全に理解して使ってるわけじゃないんだろうから、
Quaternionだって理解してなく立って使えばいいんじゃないの?

>>116
>どうせ座標系の概念も完全に理解して使ってるわけじゃないんだろうから、
それはマズい。概念くらいは完璧に理解した方がよい。っつーか理解出来る。
とか言いながらQuaternionに関しては理解しないで使ってるけど・・。

>>114
iをかけると90度回転する直交した座標系って考え方でもだめ？
しかし、虚数とか考えた人は偉いな〜と思う。

例えば宙返り可能な飛行機の姿勢の表現方法としてPLY角だと
破綻するので、クォータニオンによる姿勢表現は必須になるのでしょうか？

>>119
http://member.nifty.ne.jp/Mukai/3d.htm

>>115
ギャワワーー！ 誰やねん「虚数」とか日本語訳したバカは！
ちょっと殺意を覚えたぞ。

imaginaryだって十分数学的じゃないぞ。
complexだって一般化しすぎ。

>>121
じゃ夢数にでもするかい？
実数の対局として虚数とするのはものすごくわかりやすいと思うが。

虚数って文字的にも響き的にも美しくない？

ideal gusを理想気体と訳してあるのも変だね。
この場合のidealは「観念的」が適当

ってスレ違いだね。

要は訳語は変なのがいっぱいあるぞって言いたいだけデシ

クォータニオンなんかいらないってっ人達は、アニメの補間とか
どうやってるのでしょうか？
いろいろな問題が、クォータニオンなら楽に（何もしなくても）
解決できるからかえって簡単だと思うのですが。

>>126
Matrix補完など。
ツールによっては「間接->間接」はPLY角で出力する
ものがあります。さすがにキーフレーム間をPLYだけで補完すると
破綻するので、PLYからMatrixへコンバートしたもMatrix同士を
補完させる手法。
もちろん、キーフレームの取り方次第で妙な補完がかかることがあります。

Matrix補間(補完は誤字ですか?)の詳細きぼん。
線形補間したものを正規直行化するんですか?

>>126
そのへんも >>95 のリンク先に書いてありました。
結局クォータニオンって必要なんでしょうか？
なんか、海の向こうのプログラマーの方々も>>95の意見には
反論してるみたいだし・・・

>>120
リンク先、簡潔に書かれていて分かりやすそうだけど、
実際考えると、「むむむ！？」となってしまう私はまだ修行がたんないのかなぁ・・・

>>128
まさかとは思うが行列の4x4のそれぞれの要素を補完するとか・・・そんな事は無いか。

他の方法では、回転行列から抽出したxyz軸を補完して最後に単位化するって
方法がある。あまりメリットは感じられない。
説明が無茶苦茶で分からなかったらすまん。

クォータニオンでできることは全部行列でもできます。
クォータニオンの方が処理が簡単な時もあるということですな。

>>130
ジオメトリブレンドって、
「行列の4x4のそれぞれの要素を補完」そのものだよ。

クオータニオンなんか中身わかんなくても「便利な座標系」と
して使っちゃえばいいんじゃないかなー？使う分には難しくも
ないと思うけど。
行列なりベクトルの方が楽ならそっち使えばいいと思うし。

とりあえず、実はみんなQuaternionよく分かってないらしいことが
分かったので安心（？）

>>130
その方法だと、ジンバルロックの問題はやっぱり起こりそうな気がしますね。

>>132
ジオメトリブレンド(=Matrix補完?)って正規直交性も失われちゃう(=軸が
互いに直交しない || 軸の長さが1ではない)ってことですか?
うーん、結果の予測が難しそうだなぁ。

オレは>>133に同意だな。Quaternionも、他の技法も使うことにするよ。

あ、えっと、姿勢表現する最適な手法は当然ですがMatrix（行列）です。
これはもう、情報量も多いですし、直行座標以外も表現できるという
点で絶大なのです。（メモリ消費量が激しくても気になりません）

では Quaternion がなぜ登場したかというと、
二つの姿勢の間を表現する段階では Matrix->Quaternion へと
コンバートして、Quaternionレベルで補完した方が、奇麗に
補完がかかるからです。（奇麗にというかどんな状態でも補完可能）

つまり、単純に姿勢だけを表現したければ Matrix、
複数のMatrix間を表現したければ 一度 Quaternionへコンバート。

という感じになります。

虚数が登場するのは、Quaternionへのコンバート段階での証明する
際のツールとしてです。所詮、係数同士の掛け算をどのようにするか？
と考える段階で虚数を用いて考えるというだけであり、Quaternionへの
コンバート、（或いは逆コンバート）を考えるだけならば完全に
ブラックボックス化しても構いませんし、実際、そのまんま商品化して
しまったプロジェクトも見たことあります。

>>136
その補間はQuaternion使わなくてもできるって話では？

任意の3x3の正規直交行列は単位行列をある軸を
ある角度方向に回転させても得ることができます。
（右手系か左手系かは決めておく）
これは行列をクォータニオンに変換するときと同じ処理です。
同様に任意の3x3正規直交行列と3x3正規直交行列との間には、
回転軸と回転角度が存在しこれを求めることができます。
ですので、これを求めて後は回転角度を線形補完することで
クォータニオンを用いずともSlerpできますがクォータニオンで
処理するのと比べてメリットがありません。

実はクォータニオンを使わない方が高速なのだが、
今の時代、どっち使っても全体の速度には影響しない。
好みで選ぼう。

ちなみにクォータニオンがここまで騒がれた理由はなんででしょうか？
任意軸回転するだけなのに、なんでクォータニオンが出回ったのでしょうか？
ちょっとした疑問です。

>>140
いや、任意軸回転がとても重要だからでしょ。
ＩＫの計算なんかもクォータニオンだと楽だよね。

確かモーションカメラとかの制御にも使われてたと思うけど・・・クォーターニオン。
違ったかな？

えと、ＰＣ系プログラマに質問です。
DirectXに巨大な三角形ポリゴンを与えたりした時などで
透視変換直前の時点のｚ座標が負なものがある場合、
どのような振る舞いしてくれるんでしょうか？（ハードウェア頂点バッファ使用時）
xyはもちろんのこと、rgbだとか、tu,tv なども切断面で奇麗に
分離してくれるものなのでしょうか？

俺はIKも行列のが楽（笑

任意軸回転そのものはできるのですが、
二つの行列があって、その両者を補完するその任意軸そのものって
どうやって求めるのでしょうか？
ネットで調べたり、書籍でも調べたのですが、この知りたい情報がどこにも
なくて困ってます。

VooDoo とかのＷバッファって何ビットなんですか？

話題になんないけど、KYROってどうなん？

>>145
回転行列から、回転軸と回転角度を取得する
ってところがポイントでいいのかな？

回転行列から座標系のx軸、y軸、z軸がわかるから、
その３つのベクトルを足したベクトルが、
(1,0,0)、(0,1,0)、(0,0,1)の３つを足したベクトルから
どのように任意軸回転されているかを調べればよさそうな気がする。
自信ないけど、どうでしょ？
詳しい方、よろしく。

あちゃー、ダメダメじゃん。
ぜんぜんダメだ・・・
まじで鬱だ・・・スマン・・・

それ面倒。素直にクォータニオン使えば？

＞話題になんないけど、KYROってどうなん？
触ったことすらないけど、実際に動いてる画面見ると
「PS2の最低ラインって当初はこんな予定だったよな」って感じ。

＞VooDoo とかのＷバッファって何ビットなんですか？
ニセ浮動少数で、16Bitです。内訳は4Bitの指数部と12Bitの仮数部。

どこでコンバートしているかは不明。
ソフト（ドライバ）かもしれないし、ハードかもしれない。

>>150
外積で一発ちゃうの?

>>152
すみません、やり方教えてください。。。

age

>>153=154
自分で調べろ

回転行列ってサー、結局は３つの直行するベクトルなんだよねー？
だから線形補間なんて、それぞれのベクトルごとに線形補間すりゃーいじゃん。
正規化が必要かな？。

QuaternionのSlearpの軸って固定じゃないんじゃないの？
外積で求めた軸回りの回転と同じ軌跡を書くの？

同じだったらQuaternionの存在価値ないような、、、
外積の場合は比較する２軸の選び方の問題があるか、、、
（一度やってみようとおもいつつ、実験してないよ）

>>145
任意の回転量の間を任意軸周り回転１回で現すことはできません

>>155
いや、別人なんだけど、このスレなくなって欲しくなかったからあげてみただけ

>>156
そのやり方だと、球面上での線形補間にならないと思うんですけど。

>>160
なんか、話の流れがよくわかっていなかったようです。
これだと行列>行列間のLERPですね･･･

だけどSLERPって一体なにに使うの？
quaternionのスプライン補間のときつかうぐらいしか思いつかないんだけど。
だけど、これも行列で計算したほうが早いような気もする。

>>161
QuaternionだとQuaternion同士の合成は高速にできる。
姿勢情報を取り出すのにいちいち行列からxyz軸抽出して正規化
なんてしてたら遅いでしょ？
まあキーフレームアニメーションに対してはそんな無理して使う
必要はないかと。それでもxyz正規化x2よりはQuaternionの方が速い
んじゃないかなあ。

>162
>quaternionのスプライン補間のときつかうぐらいしか思いつかないんだけど。
>だけど、これも行列で計算したほうが早いような気もする。

のレスとして受け取っていいのかな？
quaternionの補間ってsinとかacosとか使うと思うんだけど、
この辺のコストってどれくらいなのかな？
確かに行列でやると掛け算だけで２００こえるけど････

>>163
acosとsinは確かにコストが高いけど、行列間の場合、
補間前の正規化でxyz軸に対して正規化(sqrt)、補間後の正規化
でまたxyz軸に正規化、計6回のsqrtが必要だからこれに比べたら
幾らか速いでしょう。
補間前の正規化は、各軸が単位化されているという前提なら必要無し
だけど、そんな回転のためだけに行列を用意するのはいささか冗長
な気が。
それに、Quaternionを使うと逆回転の計算が凄く簡単なのも利点かも。
回転行列からだと逆行列を求めないといけないし。

>回転行列からだと逆行列を求めないといけないし。
回転行列の逆行列は、転置するだけだが…

>>163
オレは「Quaternionなど要らん」派だけど
最短コースの算出は行列では難しいぞ
最短＝最適ってわけでもないし、無制約＆最短コースが必要な
場面なんてほとんどないから特に困ることも無いが

>>165
あ、そりゃそうだ。失礼。

>>162
え、Quaternion同士の合成なんてするんだ
quaternionをMatrixに変換して、Translation情報を乗っけた4*4MATRIX
同士を掛けてるんだけど、それって馬鹿？

つか、4*4Matrixって、あんまり使わないの? PS１は3*3Matrixだったよね？

＞それに、Quaternionを使うと逆回転の計算が凄く簡単なのも利点かも。

スマソ。逆回転なんて何に使うの？

>>168
キーフレームアニメでキーとキーの間の補完はQuaternion同士でやるといいよ。
と言うかそれがQuaternionの真骨頂・・・。
4*4は標準的だよ。
PSは3*3+平行移動だったっけ？あれはいい加減だった。

>>169
ピッキングとかIKとか結構用途は限られてるけどね。

回転角度制限とかってｲｲ方法ないですか？
Quaternion→行列に角度に戻して、、、しかないんでしょうか？

>>171
行列のところでストッパー仕込んだら？

>>164
そっかー補間前にも正規化が必要なのを忘れてたよ。
じゃーキーフレームにはquaternion＋locということで・・・・・

挌ゲーみたいに、モーションの途中でキャンセルして
他のモーションに滑らかに繋ぐ、なんてのをやると、
やっぱquaternionマンセーですな。

試しにXYZでやってみたりすると、めちゃくちゃ面白い
アクションが見れたりもしますが。

sin()cos()の複雑な式を立ててがんばった人に合掌

>>174
>試しにXYZでやってみたりすると、めちゃくちゃ面白い
>アクションが見れたりもしますが。

最初と最後は合ってるんだけど、途中で回り道をすると言う事でしょうか。

>>176
そのたうり

>>177
そりはバグ

>>176
まわり道なんてレベルではない事も多々あります。
角度制限も付けなかったりすると、もう人外の動きです。

>>177
バグではなくXYZで補間するという事は、そもそも
そういうものなのです。

間違えた、
>>177は>>178宛てです。

>>180
XYZって角度のこと？
それなら納得

俺、クォータニオン使ってないけど特に困ったことないなぁ。なんでだろ？

>>182
補間とか使ってる?
ただのアニメーションの補間だけなら、デザイナーさんが
破綻しないようなキーを打ってくれてるのかもね。

アニメ間補間すればすぐに問題出てくるよ。スロー再生でも
出てくる場合あり。

>>182
たいした仕事をしてないと思われ

>>139 に激しく同意
最近クオータニオン使っていろいろ、ライブラリマクロ作ってたのですが。
クオータニオンでできたアルゴリズムがすぐにそれより高速な行列の計算になってしまう。
どうにも原因は、

１．回転角度１／２問題
　クオータニオンは回転角度を１／２で設定する必要がある、これがクセモノ。
　倍角公式とか使って駆使しないとどうにも高速化しない。
　直感的でもなくなって、式が下品になる。

２．並列計算できると最速アルゴリズムが変化してくる
　ＶＵみたいに大量に並列計算できると、それを有効に使ったほうが効果的。

というところですかね。

クオータニオンがどこまで速くなるか、いろいろやってみたところ・・・
外積＋内積＋スケーリングで１３クロック、これ以上はならんって感じでした。
まあ、回転だけを連続計算するならクオータニオンがちょっと有利って感じを受けます。
平行移動まで考えたら、私は素直に行列つかってます。
回転軸割り出しとか、こちらからの方でもできますし。
場所によって分かりやすい方使うのが理想的とおもう。

＃やっぱり外積と内積は数学の歴史がたどったとおり、バラバラの方が使いやすいと思った。

でもＰＣならクオータニオンもありかな・・・

>>185
同じく激しく同意
最終的に行列に帰結するのは必然のような気も・・・
適材適所も必然

オイラー角 --> プログラマ以外がデータを打つ時
クォータニオン --> 回転情報のみで済む時
行列 --> 平行移動＆スケーリングとかも持たせたい時

って感じかなー

>>185
>１．回転角度１／２問題
????どう言うインターフェイスで扱ってるの？
あるベクトルからあるベクトルに向けるQuaternion？
任意軸回転行列で表わそうとすると余計に計算が大変じゃ無いかな。

>188
あくまでPS2の話なんですが。

１．任意軸回転行列を作った後に回転＋平行移動する。
２．クオータニオンで回転＋その後平行移動する。
３．クオータニオンで回転その後行列になおして計算する。

の三つで試してみたのですが、回転ばかり連続計算しなければ１が最速でした。

さすがにインターフェイスは普通の角度です（そうでないとやってられません(^^;）、内部の式がそうなのです。

あと、倍角公式つかうというのは、クオータニオンをいじくり倒すときです。
回転するだけらは 0.5 かければすむ話です。

>>188
ひっとして直角方向が分かっているケースでしょうか、もしそうなら異論ないです。

よし、漏れもSSEで挑戦って気持ちにはならんな
こんだけやる気の出ないアーキテクチャも大したものだ
スループット２、水平演算不可、２オペランド、レジスタ８本
梗塞パイプ、貧弱デコーダ、これらを補って余りないクロック
鬱だ

>>189-191
なるほど。simdで処理すると行列の演算は高速ですからね。
まあ私の場合あくまで利便性でQuaternionを使っているんで
速度に対してはあまり期待してません。
最終的に行列にして座標変換するんで最初から座標にしておくのが
一番なのかも知れないけど、姿勢情報なんかはスケールが付いた
行列から一々抽出するのはなんかイヤなんですよ。
>ひっとして直角方向が分かっているケースでしょうか、もしそうなら異論ないです。
直覚方向はベクトル同士の外積です。で、角度は内積。
実際はバンクを付けたく無いから多少複雑になるけど、それなりに
すっきり組めます。

>>192
それが普通の人の感性なんで、気にしないことにしよう。
少数派でいいなら、PowerPCのAltivecなんかは好きです。

>>184
俺のこと？

最近Direct3D8をはじめた者ですが、
多くの人は数値演算系のライブラリをどうやって作っていますか?

1. 自作
2. D3DXライブラリ
3. 誰かが作った強力なライブラリ

自作が一番勉強になるとは思いますが、使い物になるものが何時できるのやら…。
いつまでたってもゲームが完成しないことになりそうで恐いです。

>>192
pentium4はスループット1だよ
gf3でvertex shader,pixel shaderした方が楽しいか

＞いつまでたってもゲームが完成しないことになりそうで恐いです。
ゲームを作るのが目的ならば、素晴らしいlibをネットで検索して
使うのがいいと思います。

ゲーム作りそのもの、lib構築そのものを楽しみたいのならば
その手の演算系libは自作するのがいいかと。
ゲーム用のlibなんて一人でもなんとか構築できる範囲内です。
もちろんlib構築そのものに楽しみを感じれる人ならばの話だけど

ひときわ濃ぃ 185 の方は一体・・・（まぁ、ええか）

> 最近Direct3D8をはじめた者ですが、
> 多くの人は数値演算系のライブラリをどうやって作っていますか?

演算系 lib は、環境に依存しないものを一つ持っておくと、
作業環境の引越しをするときはラクチンでいいですよ。
私は自作のモノを一つ用意してあります。

>>196
DirectXのソースを参考にして自分で組むべし
ライブラリに自分の欲しい関数があると思ってはいけない
ベクトルの回転だけは自力でこなせ

クオータニオンって、外積＋内積なんですか？
その辺り、もうちょっと詳しく知りたいです。

射影変換とビューポート変換ってなんですか？
DirectX使ってマターリ組んでたら、自分でワールド座標をスクリーン座標に直すことができません。どなたか助けてください。

>>202
それは書籍に載ってる３D技術だから

これがまた載ってないんですよ。
ワールド座標に直した座標を視点座標に直して、スクリーン座標に直して
うにょうにょってやりますよね？
ここまではワールド座標にカメラの行列を掛けてやって、射影変換行列
っていうのを掛けてやればできますが、問題はその後なんですが、
ここからのビューポートの変換ってどうやるのですか？
っていうかですね。射影変換のところからさっぱりわかっていません。
射影変換については一応本で解説されていて
要はカメラ座標からスクリーン座標に直すものって書いてありましたが、
入ってくる値を見るとどうもそれらしい値ではない感じです。
別に使っても使わなくても大して変わらないような値が入ります。
ちょっとした誤差のような感じです。
スクリーン上の座標にはなってくれないのですが。
それで射影変換とビューポート変換ってなんだ？ということなんですが。
ビューポート変換については何者かすらわかりません。
ＤｉｒｅｃｔＸに設定したものはスクリーンの幅とか高さとかいれたような
気がしててそのときはただクリッピングでもしてくれるだけかと思ったんですが。
違うみたいですね。

>> 204

線形代数の教科書を読もう。

>>204を読んで思ったのだけれど
DirectX(&OpenGL)使っている人って
ブラックボックスのまんまプログラミングして人多いの？

最近プログラムを始めた者です。
ゲーム制作に興味があって2Dや3Dの絵のことを色々調べてたり、
ちまちまと勉強プログラムを書いたりしているのですが、
VoodooのAPIだった「Glide」の開発キットはもう手に入らないのでしょうか。
Direct3D8がやたらと難しくて困っていまして、webで読んだGlideの
シンプルさに惹かれてます。2Dの表示にも便利そうですし。

>>204
DirectXのヘルプに詳しく書いてあると思います。

いえ、書いて無いようです。
書いてあるのは射影変換までだったと思います。しかも行列だけ。
ここのところの解説ってありましたっけ？

書籍に載ってないとは言え、
付録CDのサンプルソースにあるような気がする。
少し古いDirectXSDKのサンプルにもあるんじゃ？

>>208

ちゃんと探せよな。

クリッピングで検索すれば見つかる。

ほんと射影変換行列とビューポート行列の関係ってどうなんだろうね。

どう考えてもWorld*View*Projection行列で一旦
クリップボリュームに変換してクリッピングしてから、
Viewport行列でスクリーン座標系に変換することになるよね。

2回座標変換が必要になるんだけど、これでいいんだろか。

もしかして、
クリップ平面をWorld*View*Projectionの逆行列で変換して、
オブジェクト座標系でクリッピングを行ってから、
World*View*Projection*Viewport行列で座標変換するのか。

>>204, 208
OpenGLの赤本とか、Mesaのソースとか眺めると良いかもよ。
DirectX8のヘルプにものってた筈。

>>207
Googleでg3sdk.exeとでも検索してみ。

>>208
絶対載ってる
書籍にもよるが
載ってない本ならヤバイ本だと思う
http://www.realtimerendering.com/
でも読んどけ
たまには英語の書籍もｲｲｿﾞ

行列が載ってるなら
それが影響されるベクトルのどの要素にどう関わってくるか
整理して考えろ

DirectXの行列のスケーリングについて質問です。
Matrixを２倍に拡大するように設定して、
SetTransform( D3DTRANSFORMSTATE_WORLD, mat );
みたいにしてるんですが、法線情報にまでスケーリングが影響するらしく、
拡大すると物体が暗くなってしまいます。
現象自体が通常考えられる逆なので、なにか致命的なミスを犯してると
思うのですが・・・よろしくお願いします。

>217
頂点が2倍遠くに行く事になって、フォグで暗くなるってこと?

>>218
いえ、フォグかけて無いので、単純に法線の長さに影響がでてしまっているみたいです。

今更射影変換についてわかったり、
自分が考えていたものより変なものだったりして。
Bio100の過去ログでも見つけましたり。
hヌイときました。別にどうでもよさそうだけど。
ttp://www.bio100.co.jp/cgi-bin2/3df/flashviw.cgi?mode=set&no=3636
付き合ってくれた皆さんありがとうございました。

世間のゲームではライトマップの生成をどうしてんの？
LightWaveのAtlas展開+LWBakerを利用できたらお手軽だけど実用になる？

>>221
ほとんどのゲームは頂点カラー焼付けな気がする。

QUAKE系だと複数枚のライトマップを一枚のテクスチャに入れ込んでるけど、
あれのフィッティング（？うまく収める）アルゴリズムってどうやるの？

>>214
おかげさまで見つかりました。
ありがとうございます。

http://www.newtek.com/products/lightwave/tutorials/rendering/lw_baker/images/atlas_cow.jpg
ATLAS展開の場合はこうだね

昔の宇治社中にQUAKEのライトマップの解説があったけど・・・.
実用性とかはやっぱり不明。

フリーの頂点カラー焼付けできるツールないすか？
ラジオシティまで言いませんから

ねえねえ、
class Vector {
public:
　　Scalar x;
　　Scalar y;
　　Scalar z;

　　Vector(Scalar x=0, Scalar y=0, Scalar z=0);
　　void Set(Scalar x_, Scalar y_, Scalar z_);
　　...
}
これってスカラーって語の用法のひとつとして適切ですか？
てきとーにfloatにtypedefしてあるんですけども。

>>227
http://aoki2.si.gunma-u.ac.jp/lecture/misc/sva.html

むむ、結局これでいいのかにゃー。
よくわかんないや（ぉ

>>229
間違っては無いと思うけど、あまり適切ではないと思う
幾何学でスカラって言うと、>>228のリンク先の説明よりも
方向を持たない量を表す意味合いが強いと思うし

うむ。やっぱなんかヘンですナリね。
サクッと全部floatに置換しちゃいます。どうもありがとー。

>>201
>クオータニオンって、外積＋内積なんですか？

外積＋内積＋ベクトルスカラー倍×２かな？

こういう仕掛け
クオータニオン x + yi + zj + wk の虚数部をまとめて ( w , v ) 見たいな
ベクトルとスカラーの組で表現するとして
Ｃ言語の構造体っぽく '.' でこんな風に表現しておきます。

C.v ＝ A.v × B.v ＋ A.w * B.v ＋ B.w * A.v
C.w ＝ A.w * B.w − < A.v , B.v >

ただし
× 外積
<a,b> 内積
* はただの掛け算

詳しく知りたいならベクトル線型代数やらの数学史関係の本が面白いよ線型代数の生い立ち良く分かるし。
ただし暇なら。(^^;

> 詳しく知りたいならベクトル線型代数やらの数学史関係の本が面白いよ
> 線型代数の生い立ち良く分かるし。

本の名前とか知りたいっす。
良かったら教えて〜。

数学史の本に関しては図書館でよんだから書籍名までは良く憶えてないです。

で、ちょっと手元を探したのですが、超複素数という本がありました。
これは、数学史については余りかかれていませんが、かわりに
複素数からハミルトン四元数（いわゆるクオータニオン）さらに
ケーリー八元数さらに多元環へと順次拡張する過程がかかれています。
外積とかにちょっと難しいがなどというコメントなぞ入っていますが
３Ｄゲーム作ったことある人ならぜんぜん平気です、むしろそれ以外の部分が
難しかったりする（といっても、他の本と比べればかなり噛み砕いた説明になってます）。
面白い本ではありますが、３Ｄ処理で参考になるようなところは無いかも(^^;
回転方法くらいは書いてありますが・・・
この種の代数の全体像を理解するにはちょうどいいかも、説明はこの種の本では
とてもやさしいです。

もし、実戦で役立てたいなら群・環・体論（これは大きい本屋にいけば大量に
あると思うので合いそうなので適当にどうぞ）
の本でハミルトン四元数とかいう項目が入っているのをどうぞ、
ただしちょっと抽象的な数学なので難しいかもしれません。

実戦であればＣＧ関係の本でなんか直接的な説明のある本も
あった記憶がありますが、ちょっとなんだったか忘れました。
確かOpenGLの本で、そこのサンプルでかかれていたような気が・・・

実戦なら、ウエブ上のこってり屋のとことかもいいですよね。
リンク忘れた、どこだっけ？

ん、
良く考えたら 群・環・体はクソ理屈だけだ、ごめん。
やっはＣＧやら物理やらの本でクオータニオン取り扱う本がいいですかね？
物理なら慣性主軸とかっといったキーワードで探してみてはどうでしょう？

>>234
超複素数良いよね。
４元数の計算式が一通り乗ってるから、ソース起しやすいし。
秋葉の書泉数学コーナーにたまに置いてる。

>>234 >>235
本の紹介、ありがとうございました。

四元数quaternionは航空宇宙技術の分野で姿勢行列の表現として
六十年代から使用されています。慣性誘導・航法及び姿勢制御の
分野です。四元数とは要するに三次元ユークリッド空間上に於ける
八次元クリフォード代数のeven partのスピノル表現に他なりません。
これが四次元時空上ですと、十六次元のスピノル表現になり、
Dirac代数sedenionともよばれます。しかし、スピノルとして
統一的に理解した法が良いでしょう。クリフォード代数をよく勉強
して下さい。

http://www.amazon.co.jp/exec/obidos/ASIN/4627061110/qid=989459950/sr=1-1/249-4222275-7090728

超複素数検索したけど、微妙にタイトル違うけどこれでいいの？
アマゾンは今送料ただらしい〜

そうそう、ソレ

>>238
そこまでやるっ(^^;

>>238
クリフォード代数のやさしい本紹介してもらえませんか？
当方、群論とかが一通り使える程度、いまリー代数で悪戦苦闘中というところです。

>>242
http://modelingnts.la.asu.edu/html/NFCM.html
価格（税別）： ￥33,015

http://channel.goo.ne.jp/download/search/search.php3?MT=Quaternion&CD=1&SW=1&OS=3&category=1&search_num=10

>>243
できれば和文の方がうれしいのですが、ここは気合で読んでみます。
どうもでした。
すばやいレスありがとう御座います。

quaternion＝八次元クリフォード代数のeven partのスピノル表現

クリフォード代数＞＞＞＞＞＞＞＞＞＞＞＞＞quaternion

I've been reading up on Clifford Algebra (heard about it from
a link on your site), and it's REALLY cool. While I haven't
done significant programming with it yet, the symbology of
common vector and matrix algebra operations with Clifford Algebra
is a lot nicer than with matrices. I think this is definitely
valuable to hardcore 3D programmers.

Two really good books I've found on the topic are:

http://www.amazon.com/exec/obidos/ASIN/9027725616
http://www.amazon.com/exec/obidos/ASIN/0471608394

Though, the books are fairly hardcore...one probably needs to
have studied mathematics up to vector calculus to really make
sense of the terminology.

This subject is addictive... :) Here is another good introduction:

http://www.mrao.cam.ac.uk/~clifford/introduction/intro/intro.html

I'm just getting started on writing some code to represent geometry
using Clifford algebra (i.e. in 3 dimensions, a multivector is an
array of 8 components: a scalar, a 3-component vector, a 3-component
bivector, and a pseudoscalar). I'm not sure how useful this will
really prove to be for rendering, but it's interesting research.
It neatly explains things that matrix algebra obfuscates, like "why
normal vectors transform differently than points.

>>247-248
sageてる辺り、手馴れてる外人さんだな（藁
っつーか、既に数学板の内容っぽい。＞http://cheese.2ch.net/math/index2.html

くっ、くそっ、NOVA に行って英語の勉強したくなってきた。
いつも行き着くところは英語の壁です。

>>234
こってり屋
http://village.infoweb.ne.jp/~tsuyozou/index.htm
ってゆうかどうなってんだよこのスレ
鬱だ死のう。

つまり、３Ｄとは、２＊２＊２＊２＝１６Ｄのクリフォード代数なのであり、
我々は１６次元のクリフォード代数の中で踊っているにすぎない。
（書籍には載っていない３Ｄ技術）

>つまり、３Ｄとは、２＊２＊２＊２＝１６Ｄのクリフォード代数なのであり
ああなるほど、そういう多元環な訳ですね。
なんとなく構造が想像できてしまいました。

うわっ、なんか妙な展開になてるよ！
>>240 本の名前の件さんきゅ〜。早速オーダーします

>>247-248
どっかのコピペだよね？
じゃなかったら…あわわわ。

256、も〜らい。

>>255
そりゃそうでしょう、こんなとこに来る外人なんかいないって。
テンソル目がチカチカしてて嫌だったんでちょっと便利かも。

>>248 このリンクいいね。
クオータニオン反対派だったけど宗派変えしようかな。
まあ、微積がかかわななきゃどうでもいいか。

ラジオシティやりたーい

>>258
おれも〜

ガイシュツではないと思うので書きます。
以前Dual Quaternionなるものを使ったことがあります。
通常のQuaternionは回転しか扱えませんが、
こいつは並進・回転を同時に扱えます(拡大は出来ない)。
確かパラメータは8つ(よってDualらしい)です。

もう2年くらい前なので中身はほとんど覚えていませんが、
探せばPerlとJavaのソースがまだあるかもしれません。
それ以降は行列とQuaternionで生きたので数学的な中身もサッパリです。
ただ計算コストがかかるなぁ〜と当時は思いました。

以上、まだ行列をまともに扱えるように前の思い出です。

>>260
そんなのもあるんだ、それは
RV^R
の形式でしたか？

＃^R <- これ嫌い。

>>260
Quaternionでもスケーリング出来ます。
w, x, y, z 全てにに sqrt( scale ) 掛けるだけ。
各成分ごとの拡大は出来ないみたいだけど。

>>261
QuaternionとVectorの掛け算はコストが大きいので、
QuaternionからMatrixに変換してからの方が良いです。
Quaternion同士の掛け算は高速なので、多関節の演算だけQuaternionとかにしてます。

>>261
ゴメンなさい。不勉強なためRV^Rが何を表すのかわかりません。

>>262
説明不足ですいません。拡大、といったのは行列でできる成分ごとの拡大を意図していました。

一応DQのPerlソースがあったんですけど、古い作なので恥ずかしい表記ばかり。
希望があれば多少リファインして挙げますけど…ココは流石に(^_^;

>>261
あ、もしかして並進・回転の行列の順番のことなのかな?＜RV^R
だとしたら多分VRです。

>>264補足
コマだしスマソ。補足です。DQでV・Rになってて
DQ・DQだとV・R・V・Rと等価になります。
で^DQは^R・^V…となったハズ。
# でないと当時、使わなかったので

えっとクオータニオンって計算するときに、回転軸いれたベクトルR
に頂点Vをかけて、さらに1/Rで割ります。
この 1/R のことを言いたかったのです。
ちゃんと説明しなくてすみません。
なんですが、どうでしょう？

＃移動してから、回転という事ですか？
＃なるほど。

あらら、同時に書いてしましましたね。

上の265 、266 です。
書くとこ間違えた。スマソ

...用語の統一が必要ですね(^_^;
以降私はT:移動行列, R:回転行列, V:ベクトル, D:dual quaternionで書きます。

DはTRと等価になります。つまり原点で任意軸を中心に回転してから移動です。
D同士の掛け算DDはTRTRになります。掛けた結果はもちろんDです。
VをDで変換する時(つまり行列で言うところのTRV:僕は後ろから掛ける派なので…)には、
VをTとみなしRを適当(Z軸0度回転とか)なのを入れ新たなD1を構成しD・D1を計算します。
その計算結果のDからT部を取り出すとTRVと同じになっています。

こんなんでうまくいくのかいな?と思いましたが当時はやりたいことが出来ていました。
いまならこの程度、行列でやりますけどね。
# もしかしたらDQの補間とかあったのかなぁ?

>>269
QuaternionとVectorを一緒に持ってるクラスなり構造体なりを使えば良いんじゃないの？
クラスなら演算子オーバーロードすれば済む訳だし。
演算コストもそうたいしたもんでも無いだろうし。
数学的な価値は失われるが、ライブラリ的な価値は十分にあると思われ。

>演算コストもそうたいしたもんでも無いだろうし
そうか？(^^;
平行移動成分ではまりそうな気がするのは私の気のせいか？

>>270 そうだと思います。もっとも
当時やりたかったことと同じこと(階層構造の組替え)をするなら行列があれば充分です。
敢えて言えば「拡大」をしない分、行列に比べメモリが半分で済むくらいかも。
# それでも3Dに使うということで行列をダイエットさせるならせいぜい3分の2
確実に演算コストとのトレードオフがあるので要検証です。

一応、本に載っていないかな?と思ったので紹介してみました。
# って、実際にソースを紹介したほうが良いのかな?

>>269
演算結果が再び D ですか、かっこいいですね。
ひょっとして、DQって、ケーリー八元数か、八次元クリフォード環か
のどちらかも知れないと思うんです。
どのように演算すればそうなるのかちょっと考えてみたいですね。

＃それとも行列の固有・固有ベクトル値並べ立ててあるのかなぁ？

>>272
あらら違うんだ・・・残念。

私にDQを紹介してくれた人は、きっと数学に詳しくなかったはずです。
# 詳しかったらDQなど見つけて来ずに行列で解決する方法を喋ってくれたハズ(藁
私も決して数学は得意でないですがその後の精進の甲斐あって、
Quaternionはホボ(←強調)理解できました。が、DQまでは勉強する気になれず。

>>273, >>270
いまちょっとDQ掛け算部分を眺めてみると、どうやらQuaternionはそのまま持っている模様。
Vector部に細工をしているようです。どんな細工かまでは理解できませんが(^_^;

>>275
いえいえ、いろいろ参考になります。
なにか分かったら私にも教えてくださいまし。

ざっくり検索してみたら次のようなサイトがでました。

http://www-as.dse.ibaraki.ac.jp/Paper/Master/M_00HS.html
修論のアブスト。日本語だけど詳細はなし。

http://vienna.eas.asu.edu/~wagner/academic/vrml98/dualquat.html
VRMLが重い。数式とVRMLによる利用がかかれていて3Dのスライドパズルが遊べる。
但し英語。私、今はこれを読む気力がありません(藁

>>271
平行移動部分はVector成分になるんで、掛け算の場合、
RV^Rが１回、RRが１回発生します。
実数の掛け算の回数を数えると、RR = 16回、RV~R = 24回、計40回。
Matrix同士の掛け算の場合、64回の実数の掛け算が発生するんで、
単純に比較した場合、４割弱有利です。
ただ、ホントに単純になんで、結果的には意味があるほど変わらないと思ってます。
それよりは、任意軸回転の有効性の方が大きいかと。＞scaleとのトレードオフだが。

>>272
メモリは確かにちょっと有利かもしれないですね。
少ないメモリしか食わないと言う事は、キャッシュヒットにも有利だろうし。

>>278
行列の４列目は無用なんだから掛け算は実質36回では

36:40と、ほぼ同じですね、PCの場合は要検討ですね。
PS2の私はアウト(笑)

>>279
確かに。失敬。

だれか暇な人らじおしちぃの問答やってよぉ。
という私はラジオシティーできない(泣)

あげ

ついでにLightWave6.0Loaderソース
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=COTD-LW6Loader&forum=cotd&id=-1

age

age

>>282
基本的なものなら簡単だと思いますけど。
むしろ難しいのは、最適なパッチの構築だと思う。
そこを疑問に思っているならすんません。

>>286

Ｃマガのdevilmanさんの連載が参考になる。

でも、俺には階層パッチ分割がよくわからなかった。
誰か教えてage

なんか3Dっていうとサーフェスレンダリングばっかりなんですけど
ボリュームレンダリングやってる人いませんか？

>>286
Cマガのは確かに参考になると思うよ。
階層パッチ分割はどの号だったかちょっと覚えてないんで、
（つまり読んでない）今はよくわからないです。スマソ。

>>288
VolumeRenderingってSurfaceRenderingに比べて
利点が少なすぎるからじゃないですか？例えばデータ量とか拡大縮小の際のエイリアシングとか。
VolumeRenderingやるよりも、nVidiaのサンプルとかにある、
スライスしてSurfaceRenderingを利用するやつとか、
MarchingCube法を使ってやった方が良いと思う。

>>288
RT?

なんか3Dというとハイソでコンサバなんですが、
ステレオグラムやってる人いませんか？

ハイソーデスカ（ﾌﾟ

>>286
ゲーム等ではSurfaceRenderingで十分だとは思ってますけど，
VolumeRenderingを必要とする物理や医用の分野があるじゃないですか．
512の3乗ボリュームでも今のPCでも十分メモリ足りるようになってきたけど，
その割にはあまり表に出てくる情報無いなぁ，と思いまして．

>スライスしてSurfaceRendering

これってSGIのOnxy2でも実装されている方法ですよね？
この方法，スライス面の間がアーチファクトとして出てきて
あまり画質良くないんですよね．

>MarchingCube法を使ってやった方が良いと思う

閾値処理の設定の問題と，
アルゴリズムが特許とられてるという問題が・・・

ということで，高速度かつ高品質でやれるようなもの，または
やっている人いないかなぁ．

>>290
RealTime，ってことですか？

ちょっと思い出したのでこれだけ。
VolumeRenderingはちょっと調べてみます。

>階層パッチ分割
見てみたけど、パッチとエレメントの事だったのね。
要するに
パッチ：ラジオシティの投光最小単位（基本となるポリゴンを分割した物）
エレメント：ラジオシティの受光最小単位（パッチをさらに分割した物）
と理解してますけど、これじゃわからんですか。

定期上げ

hage

整数演算で幾何計算をやるにはどうしたらよいのでしょう？

>>297
物によって精度足りなくなると思うけど、固定小数点じゃだめ？
64bit intで下48bitを少数にすれば、かなりいける気が。

>>297
全部有理数で計算するとか。線形要素ばっかりならなんとかなるのでは？

浮動小数点は遅いという思い込みをしてるドキュソの方ですか？

レスありがとうです。

>>298
あー、固定小数点のこと考えていました。
・・・固定小数点使えば何とかなりますね。

>>299
>全部有理数で計算するとか。線形要素ばっかりならなんとかなるのでは？
線形要素･･･チンプンカンプンです。

>>300
FPUついていないプロセサを使おうと思っていましたので。
それでも浮動小数点を使った方が速いのでしょうか？

FPUついてねーんじゃ余計な計算しないように
場面場面でどっちが速いか確かめなければ駄目。
STGのスレにもでてきたが正規化と媒介変数は鬼門だな。
ちなみに媒介変数とはSinやCosみたいなもの。
大抵これだけだとテーブルを作って逃げてしまうが
まさか媒介変数使うたびにテーブルを作るわけにはいくまい。

FPUがついてないということは・・・。もしや・・・。

すまん、わかりにくかったね。

線形要素のみってのは、直線とか平面とか、式で書いたときに線形に書けるもの、
もっと感覚的にいうなら真っ直ぐなもののことのつもりです。
これなら幾何演算が加減乗除で閉じることが多いから、整数の加減乗除で有理数を
表現すればイケるんじゃないかと思ったわけ。

ま、どっちにせよメンドウですよ。

>>302
>場面場面でどっちが速いか確かめなければ駄目。
うは。そんななんですか。そりゃ大変そうですね。
わからないのですが、浮動と固定で混ぜるとすると、
固定小数点で使われるよな、整数部と小数部で分けた形式で
浮動小数点を表現するのでしょうか？

>>303
携帯機(PDA)を狙っているのですが、その「もしや」でしたか？

>>304
それだと有理数で何とかいけるんですか。勉強になります。

>>305
コンパイラに浮動小数点のエミュレータついてないの？
よっぽど遅くて使い物にならないんならしょうがないだろうけど。

FPUを持たない環境で
整数演算と浮動小数点演算で
速度的に比較対照になりえるなんて話は
聞いたことも無いし、予想もつかない。
FPU無しで浮動小数点演算をやるなんて
速度を度外視して良い場合でもない限り
自殺行為のはず。
環境によっては容量的にも痛い目を見る。
って言うか、浮動小数点演算に
そこまで固執する必要って無いと思う。

定期age

>>306
やってみれば分かりますが、思わず有り得ない！！
とか叫びそうなほど遅いです。
デバックとかアルゴリズム確認程度にも使えないのが普通です。

>>309
んなこたぁない。
386, 486SXの頃はエミュで動いてた。
バリバリ演算する訳じゃなければ問題ない。

>>310
当時は遅いのが当然でしたからね。
しかし、悲しいかな時代が違いますよ。

あげ

えみゅ自体がヘモくなってるんですかね。
S社の某 math.h は凶悪だった・・・
移植性重視でCで書いてあるとか(笑)

>>304
要素を全部有理数にすると大変です
整数を使った同時座標系ってどうだろうか？
やったこと無いけど、いけそうな気がする。

っと考えてみたけど
オーバーフローしないように時々正規化する必要があるんが面倒かな・・・

書籍にはのっていそうだけれど、よくわからなかったので質問。

BSPによる陰面消去ってのは、
http://reality.sgi.com/cgi-bin/bspfaq/bsp?9.txt
に書いてあるようにfront to back, back to frontの二つあるみたいなんだけれど、
eyeから向いている方向に対してview frustumを分割して、
それぞれ近い方から遠い方、遠い方から近い方に描画していくということですか？

ちょっと、わかりにくい日本語かもしれませんが･･･。

>>297 もしかしてＰＳ１でプログラムしてるんですか？
って激遅レス

しかもage

おたすけを

ここの内容を本にしたら売れるかな？ｗ

>>319
ネタとしてなら

>>313
math.hはCで書かれていますがなにか？

>>316=318
いや BSP によらなくてもそうだから、皆何を聞いてるのかナゾだったのでは
ないかと。俺は今初めて見たので。。。

要はその BtoF なリストを作るためにprecalculatedなBSPtreeが有ればO(n)で
いけまっせ。しかも視点方向無視できまっせ。ってことです。

すみませんシャドウイングについて質問なんですが､
DirectXでステンシルバッファを使わないで影を表現する方法について
参考になるページ等がありましたら教えてください。

ページはパッとは浮かばないが、ドロップシャドウでは
ダメなの？

解説HPはないんじゃないかなぁ
ソース公開してるのはあるけど（MS SDKにもあるし）
最近出た本の Game graphics gems(だっけ？）にも説明はあるよ

あぁ、でも、ちゃんと実装するには説明が足りないかもね
大抵サンプルってオブジェクト数少ないもんね

>>323
該当するページが見当たりません。

キーワードを変更するなどして再度検索してみてください。

いろいろ調べてみたんですけど、とりあえずPlanar Projected Shadow
（平面投影シャドウ）でやってみます｡
いや、なるべく多くの環境で影を見せたいんでステンシル使わない方法を探してました｡
それにしても、コンシューマと違ってＰＣで開発やってると低レベルなマシン環境に
合わせなきゃならないのが鬱です・・・

オプションで切り替えてのシャドウボリュームモードもやりたいんですが
時間があまりないんで楽な方で逝きます。

>>328
低スペックなマシンなんか切って良いと思うが。
3Dやろうってヤツが低スペックマシン使うこと自体が間違ってる。
いくらでもないんだから買い換えろよナー。

そうなんですけど、低スペックのわりに普及しているi810とかを
切り捨てる訳には逝かないってところが一番鬱ですね。
インテルのビデオカード逝ってよし！っつーか。

保全age

>>330
アレは3Dカードに入りませんので切ってよいです

まあ、PCで3Dゲーやりたいヤツは
最低でも１万円出してGeForce2MX買うでしょう。

CedecでNVidiaのセミナー出たけど
破綻しないシャドーボリュームってムヅイつか、面倒つか、重そう、、、

http://www.kakaku.com/prdsearch/detail.asp?ItemCD=055028&MakerCD=254&Product=Tornado%20GeForce%202%20MX200%2D64%20%28AGP%2064MB%29
こんなの安いんですが、これでもいいんですか？
ゲームってあんまりやらないもので正直、よく分かりません。

GeForce2MXってこんなにやすいんかー！！

MX200はTNT（ULTRA?)並みじゃ無いっけ？
MX400にしとけ

せこいこと言わずGTSにしとけ
３なら尚良し

>322
レスどうもです。
>316はなんだか正しいように見えますが、実は間違っていますｗ
きちんと勉強したらわかりました。

ところで、BSPtreeでsortしたら、どう描画していくべきなんでしょう？
FtoB? BtoF?
でそのどちらかだとして
BtoFだとPainter's Algorithmってことになりますよね。
FtoBだとmaskか何か用意して描画するのでしょうか？

どれが最善なんでしょう？

flat shadingであればPainter's algorithmで良さそうですけれど、
gourandやphongだとFtoBでmaskが良いのですかねえ？

おいおい
Painter'sはZバッファ要らずって奴だろ

BSPは無駄なZバッファ＆スレームバッファへの描画を減らす為なんだから
FtoBに決まってるだろ

>>341
レスどうもです。
>スレームバッファ
って検索にかけても出てきませんでしたがフレームバッファのことですよね？
もし違うものであれば教えてください。

ちょっと良くわからないのですが、
FtoBで書くとして、それはmask bufferの用なものを用意して
書くんですよね？

hage

>>334
詳細喜望峰

>>344

いやぁ面倒でちょっと無理。
基本的にはステンシルバッファ＆nearClipにフタをする方法なんだけど、

いくつか注意点があるので その辺の確認みたいな内容だった
図がないとちょっと無理っす

PowerPointのデーター後日公開されるのかなぁ？
参加者も紙だし。ファイルもくれよ〜

やっぱしシャドウボリュームをカメラの前でちょん切るですか？
うー、面倒そうやなあ。

http://www.r3.nu/~cass/shadowsandstuff/
これについての日本語解説とかないですか？
英語＆OpenGLなんで全然わからん・・・
カラーバッファってなんですか？ＤＸ８でも同じことができるのかな？

>>325
× Game graphics gems
○ Game Programing Gems

ちなみに２もすでにあるが、栄語が読めん俺は逝ってよし。

>>348
ソースと式と絵を追うべし。

モンテカルロ・レイトレーシングとか
フォトンマップとかの話も聞きたいっす。
お願いします。

ちなみにわたしは普通のレイトレースレンダラーすら書いたことがありませんので、
やさしくしてね。

>350
■■■■■■ 終了 ■■■■■■

>>351
終了かよっ！！

>>352
　∩＿∩
（　 ´_ゝ`）←フーン
（　　`Д´）←モウコネエヨ
（.　・∀・）←モララー
（.　´∀｀）←モナー
（.　　.ﾟДﾟ）←ギコ猫
（.　-＿-）←ヒッキー
（ 　´ー`）←シラネーヨ
（. ；ＴДＴ）←モカー
（.　´⊇｀）←モヒャ
（.　＾×＾）←モネー
（.　´曲｀）←テナー
（.　‘∀‘）←ガナー
（.　 ´ω｀）←ショボーン
（.　・＊・）←アナラー
（.　・≧・）←フェラーチョ
（. 　冫、）
（..　`　　）←アンソニー
（. つ.　 つ
〈.　〈＼. ＼
（.＿_）（.＿_）

ところで、
３Ｄのモデルデーターを扱うのに
一番イイと思われるフォーマットって何よ。

一応、モデルデータと、アニメーションデータは別で持つとして。
夜露死苦

モロ、無修正画像サイト発見！

http://www.sex-jp.net/dh/01/
http://www.sex-jp.net/dh/02/
http://www.sex-jp.net/dh/03/
http://www.sex-jp.net/dh/04/

無いのかなぁ

>>356

lwo2

>356
厨房か？せめて何(ゲーム？レンダラー?)作りたいかぐらいは
書きなよ。

>358
SPACE SATAN FANTACYというゲームを作っています。
西暦3499年、惑星コルドロンは邪王サタンに支配されていた。
悪逆の限りを尽くすサタン。それを阻止するために、
現代の地球人・アスカが召還された！ アスカは機動騎士
タイガードラゴンを駆り、サタンを滅ぼすために立ち上がった！
というストーリーです。

>>359

あなたは良い味を出しているので、この先どんなに
辛いことがあってもその調子で頑張ってほしい。

>>359
タイガードラゴンを操作するのですか？
アスカを操作するのですか？
コルドロンはどこにあるのですか？

西暦3499年のコルドロン星に召還されたアスカたん、ﾊｧﾊｧ･･･（；Д｀）

>>359
がんばれ。ぜひ完成品を見たいので。

スペースサタンファンタジー、略して、スペサタ。
大ヒットの予感。。。

>>359
なんとなく懐かしい気分にナタヨ

アスカ＝アムロ
機動騎士タイガードラゴン＝ガンダム

>>362
>（；Д｀）
的確に表情が伝わってくる

なぜアスカﾀﾝは召還されたの?

ああ、偽物が出てる。
まあイイや。

まあ、作りたいのはゲームなんですけど、
とりあえず　六角大王表示したら
内部データに　法線の情報が入ってなかったってんで、
そう、出来ればバイナリーが良いかな？
そう、バイナリー

Ｘファイルとか、モーションデーターも一緒になってるような
気がするから、何かとかね。

って、俺
厨房やな。

すんません
自分で調べます

鬱だ死のう。

この際、>>369が偽物であって欲しいなぁ、(;´Д`)ｶﾞｯｶｰﾘ
つか何言ってるかワカラン、汎用フォーマットの話じゃないのか？
とりあえずXファイルでいっとけば？別にバイナリにもできるぞ

どんどんどんどんどんどんどんどんレベルが下がってるぞこら。
ぼくげーむつくるよんスレじゃないぞこら。
最後に鬱だしのう言えばいいってもんじゃないぞこら。

>>370
モデル表示のみに特化したデータ形式のスタンダードが有るかと思い、
質問してみました。
僕の脳みそのレベルが低いのは、確かに認めますが。

ゲームだと言ったのは、
必要な情報が、テクスチャーのＵＶ値とマテリアルの質感
後は座標情報、
それも、トライアングルストリップと、トライアングルリストのみで良いからです。

それと、モデルデータとそのアニメーションデータは別で扱いたいため、
Ｘファイルを解析して、それを分離すると言う方法よりも、
別々で持てる形式の方が嬉しいと思ったからです。

>>371
ごめんなさい


もう来ません。

>>354
＞３Ｄのモデルデーターを扱うのに
＞一番イイと思われるフォーマットって何よ。

ゲームなら独自形式でっち上げて好きなようにやればいいよ。
どうせ自前のツールやプラグインで必要になるんだし。
それに、ユーザが困るわけでもないし。

市販ツールの吐くデータの仕様は買えばすぐ分かるから
とりあえずバイトでもして。資料手に入れたら後はperl
とかpythonで適当にコンバータでも作って。

>>369
＞とりあえず　六角大王表示したら
＞内部データに　法線の情報が入ってなかった

六角は両面描画＆フラットシェーディングが前提だから
.rokは法線情報省いてるよ。(少なくともフリー版は)

＞そう、出来ればバイナリーが良いかな？
＞そう、バイナリー

任せる。

>>372
あやまるなよこら。
罪悪感感じてしまうじゃないかこら。

>>354
ようやく>>369理解。漏れもちと後味悪し。みんないい人。

その用途ならとりあえずＸファイルで良いと思う。>>372も標準テンプレートで全部賄えるよ。
で、モーションデータだけ別にしておけば良いのでは？モーションデータに
特化したＸファイルでも良し、あるいは独自ファイルにしても良し。
DXSDK付属のconvxでバイナリ<>テキスト変換もできる

慣れてきたら>>373さんの言うとおり独自フォーマットに移行するとか。
あと六角の法線は自分で計算して出そう。

ただし市販ソフトでデータ使い回す場合はXファイルではトホホです。

>>354のこれはコピペなの？

SPACE SATAN FANTACYというゲームを作っています。
西暦3499年、惑星コルドロンは邪王サタンに支配されていた。
悪逆の限りを尽くすサタン。それを阻止するために、
現代の地球人・アスカが召還された！ アスカは機動騎士
タイガードラゴンを駆り、サタンを滅ぼすために立ち上がった！
というストーリーです。

ﾓﾌｧ ﾍﾌｧ
((( ⊂⌒~⊃｡Д｡）⊃ ＜>>359桜玉吉の「アコンカグア」思い出しちゃったヨ。

>>375
レス、有り難うございます。
六角のデーターの表裏判定は、なかなか巧くいかなかったので、
メタセコイアＬＥを使って見る事にしました。
利用しているのがＯｐｅｎＧＬだった為に、
Ｘファイル使いたくないと思ったのですが、
ネットを探してみると、いろいろなモデルからＸファイルに
コンバートしてくれる物が多数ありまして、
なるほど、正しかったんだ、と、思い直しております。

それと、今までも多数の３Ｄゲームが世の中に出ているので
てっきり、ゲームに適したフォーマットがすでに作られていると勘違いして
居ました。

いろいろ済みませんでした．．．．。

レンダラ屋だけど、なんかある？

>>379
ねたふってください。

>>380
守備範囲はソフトウエアレンダラ
何でも聞いて

レンダラ屋って 具体的にはどんなアプリ作ってるの？

>>382
レンダラだよ。エンジンだけでGUIはなし。

レイトレ、スキャンライン、ラジオシティ、フォトンマップ、
モンテカルロレイトレ、なんでも一通りOK。

>>383
それでお金稼いでいるの？

>>384
うん。まあ、今のところ。
GUIもそのうちやるけど。

＞レンダラ屋さん

>>350の質問に答えてやってよ。

>>386
ちょっと広すぎるなあ。
具体的な質問にしてくれれば答えられるけど。

レンダラ屋って儲かる？

>>386

http://graphics.stanford.edu/courses/cs348b-01/course8.pdf
俺は英語読めないんでパスな。

>>388
うちはレンダラだけやってる訳じゃないけど、
エンジンだけだと儲かんないね。

>>389
それ、読んでみ。簡単な英語ばっかだから。

リアルタイム処理で、
グーローではなく、グロー、
つまり自己発光したいのですが、
さて、どうしたらよいものか？

>>391
法線方向に拡大したモデルを半透明で重ねる、とかかな。
面倒だからそういうモデルあらかじめつくっておいた方がいいと思うけど。

？

??

>>392
単に拡大したモデルじゃだめ？

なんで拡大すると光るように見えると思うのか理解に苦しむなり。

>>391
光源を物体内部に持ってくるんじゃ駄目？

グローってどんな処理でしたっけ？
拡大して輪郭をぼかしたものを合成するのでしょうか？

駄目か。テクスチャーをフィルターにして方向によって光源の色を
変えないと・・・。

自己発光つうんだから、提灯みたいなものじゃないかな？

発光物体の表面が散乱ありか、散乱無しの透過かでも違うし。

普通は錯乱ありをグローっていうんじゃないの？
錯乱なしなら問題はないような気がしますが。

>>402
一人で錯乱しててください。

>>398
>>402
ﾜﾗﾀ

漏れはリアルタイム系に詳しくないけど、>>391はどんな自己発光を
想像してるの？発光してるオブジェクトが他のオブジェクトを照らす
状態？それとも光源を目で見た時のフレアみたいなやつの事？
その両方？

もうすぐボリュームテクスチャがサボートされた
チップがでるからそれまで待てや。

＞光源を目で見た時のフレアみたいなやつの事？

これだけならテクスチャー貼り変えるだけだから、他を照らすんでしょうね。

>>407
？？
この場合テクスチャを張る相手は誰？

ちなみにソフトウエアレンダラはこういう場合2次元的に合成しちゃう．

グローって物体の周りにぼやっとしたものが
まとわり付いてる状態じゃないの？

こんな感じに物体のまわりをぼやっと発光させたいです。
http://travel.nifty.com/fworld/psp/image/grw0106.gif
これは2Ｄですが、3Ｄでキャラなどを。
見た目のみで、実際に他を照らす事はしなくていいです。

>>408
うん二次元のつもりだった。

>>410
あべし。

３Ｄなのか？ｗ

>>410

藁田

>>410
え〜（ｗ
その程度のフェイクぐらい創意工夫でやってみそ。
いや、真面目な話ムッチャ簡単な２Ｄエフェクトだから。
２ちゃん見てないで頑張れよ。ｵﾚﾓﾅｰ

やっぱりね(w
これだと思ったよ。でもさあ、これってリアルタイムでオブジェクトが
スピーディに動いてるときって結構辛いんじゃないの？
今のボードだと平気なの？リアルタイム厨房＞漏れ

ソフトウエアレンダなら楽勝だけど。

>>410
何度も重ね描きする以外には無理なんじゃないかな？

円形の半透明グローテクスチャ作って該当モデルの前に表示。

furで似た感じ作れないかな？

>>418
あまりにもインチキすぎるＹＯ･･･

>>419
リアルタイムでfurってどうやるんだＹＯ！

>>421
はなげさん資料がわかりやすいNE！
http://www.geocities.co.jp/HeartLand/8281/journal.html#20010820

直毛ウサギ
http://www.geocities.co.jp/HeartLand/8281/chokumou.jpg
もじゃもじゃウサギ
http://www.geocities.co.jp/HeartLand/8281/moja.jpg

>>422
へえー、リアルタイムにしては良く出来てるね。
質はソフトウエアに及ばないが。

>>423
ひとこと多い性格だのう...

>>424
すまん(w
漏れはﾔﾊﾟｰﾘきれいな方が好きなもんで。

ウヒョッ

FFXの敵が死ぬときのモワァーってやつってどうやってんのかな？

辛口レンダラ屋萌え(;´Д｀)ﾊｧﾊｧ

>>424
技術的な一言が多ければ文句ないんだけどな(笑)

>>429
なるほど。どんな話がいい？

>>429も一言多いﾖ

>>430
422のうさぎのモコモコとか、
ソフトウェアで綺麗に描画するとして、
方法が根本的に違うのか、
それともリアルタイムで描画する方法の延長線上に過ぎないのか、とか
お願いします。ぺこり

>>432
考え方によると思う。
目的とする用途によって実装の方法が変わる、と言えば良いか。
映画の特殊効果なんかでの毛は、正確なアニメーションをしないと
いけないからほとんどの場合形状を置いている。
で、その形状をサブピクセル単位で幾何学的に評価(つまりそれぞれ
のサブピクセルでシェーディング)するから当然きれいになる。

そんなに正確さが要求されない場合は2次元的に合成してしまう
方法もある。これは多分リアルタイムの方法と似てると思う。
ソフトイメージについていたメンタルレイ用のファープラグインは
この方法。ShadeのMarimoもこれだろうな。
この方法だとセルフシャドウとかが出来ないけど、ピクセル単位で
評価してる分、リアルタイムよりはきれい。

ＣＧソフト産業不毛の地　日本でレンダラだけで食ってる人は何人いますか？
レンダラ屋さんは実は外人？

>>434
自分もそうだけど、レンダラだけで食っているわけではないよ。
そんな人日本にいるんかな？

Shadeのレンダラ書いてる人とか？

>>436
Shadeってレンダラだけ書いている人がいるの？それはすごいな。
なんか技術の話じゃなくなってるぞ(w

みんなお互い詮索せんとこ。

>>438
同意(w
純粋に技術の話しようぜい

age

クリフォード代数ってどうよ？

（・∀・）がいしゅつでした

このスレでクリフォード代数のこと書いたが全然話題が広がらなかった（泣

ていうかwebでも資料があまりない気が

期待age

billboardって何ですか？
Computer Graphics: Principles and Practices in C
みても載ってないれす。

＞446
　billboard n.
　1 《米》(通例屋外の)掲示板,広告板: a notice on the 〜掲示.
　2 〔海〕錨床（びょうしょう）,錨座.
小学館プログレッシブ英和中辞典より。

>>446
常にカメラ方向を向く板のことです。

レンダラ屋さんの書籍には載っていない３Ｄ技術をききたいのだが

>>449
正確には書籍に載っていない技術というのは無いかもしれん。
英語の文献にはほとんどの事は載ってるからな。

ちなみにゲーム関係とかリアルタイム系は厨房なのでそこんとこ
よろしく（ｗ

今はレンダラといってもプラグインやシェーダ書いたりすることがほとんどではないですか？
独立したアプリを作ってるのですか？

あげ

>>451
そろそろ詮索は止めてよ（ｗ
ちなみに独立したレンダラを作ってます。

フリーのPOV-Ray使ってる人いますか？

POV-Rayの紹介ページ
http://www.win.ne.jp/~kom/povray.html

こんな画像も作れちゃいます。
http://www.povray.org/hof/index.html

POV-Ray使ってる人はこの板にはいないと思う。
POV-Rayみたいなソフトを作りたいと思ってる人が多い。

メタセコイヤって凄くない?

当方もレンダラ屋

>>456
それはモデラでわ…

>>457
GI系のレンダラ？

グローバルイルミネーション最高age

モンテカルロレイトレの実験してます。
レンダラ屋さん、細かい注意点とかポイントとかtips教えてー

>>459
アーキテクチャの種類は？
ﾌｫﾄﾝﾏﾌﾟ？

FF映画のフォトンマップひどかったな…
「とりあえず使ってみました」以外の意味がない

>>461
FF映画って、レンダーマンだからレイトレは使ってないのでは？

>>462
ハイン将軍が持ってたブランデーグラスが
机に落した影の部分はフォントマップだと
思ったんだが。

>456
　個人であそこまでシステムを作り上げた苦労が凄い
ね。フリー版をありがたく使わせて貰ってるけど、作者
が暇になったら、レジストするつもりだよ。でも、特殊な
技術はほとんど使ってないのではないかなぁ。メタ
ボールとか面白いけどね。

クリフォード代数ってどういうものか勉強したいのですが、
日本語で基礎から学べる良書はないでしょうか？

ちなみに、
理工系数学のキーポイント行列と変換群：ヤン・ソンキル
って本は読んだ事があるのですが、
この本に書かれている事とクリフォード代数って関係はあるのでしょうか？

ない。

日本語良書もない。

ないないずくしです。

実は今日本屋に行って、
訳のわからない本をいくつも手に取り、
その索引にクリフォード代数という文字を探してたんですよ。
そしたら、ゲージ理論とトポロジーって本にようやくその文字を見つけたんですが、
私なんかにわかるはずもなく…。
機械科の僕にはこの本を読むためにどの分野の基礎を必要にするのかも解らないのです。
で、とりあえずトポロジーとホモロジーって言葉を見かけたんですが、
これの日本語訳を教えて欲しいです。
全く勉強したことはありませんが、トポロジーっていうのは位相幾何学って意味であってますよね？

電子情報の私にもサッパリですので、まあガンバろうやって感じです。

出身学科なんて関係ないよ。
数学科でも教えてないし。

同じクリフォード代数でも、本屋で売ってる数学や素粒子物理の本に載ってる
クリフォード代数とは意味合いが違うので要注意。
遠回りになる。
この人らが再発見したことだから原文に当たるしかない。
http://modelingnts.la.asu.edu/GC_R&D.html

レスありがとうございます。
やはり私にとって今やるべき基礎は英語のようですね。とほほ…
数学にも強くなれるよう、もっと視野を広げなければと思います。