[過去ﾛｸﾞ] 統一３Ｄスレ (558ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
401: 327 [sage] 02/02/09 00:30 ID:??? AAS
>>395395(5): 名前は開発中のものです。 [sage] 02/02/08 23:09 ID:??? AAS
Generally speaking in todays we must calculate and get
z-value for every vetexes when converting the view coordinate
to the screen one but I heard there is a good method which doesn't
need to seek concrete z-value (or w).
If there is,we can omit division-calc for every vertexes.
Also I heard that using this method we will be able to clip or cull
polygons by Z-near/far plane but I couldn't understand at all!
help me.
概して言えば、今日、ビュー座標系からスクリーン座標系に変換する場合、
我々はすべての頂点のz値を計算しなければなりません。
しかし、私は具体的なz値(あるいはw)を求める必要のない、よい方法があると聞きました。
もしそうであれば、すべての頂点に対する除算の計算を省略することができます。
さらに私はこの方法を用いることで遠近のＺ平面でポリゴンをクリップしたり省略したりすることができるようになると聞きました。
しかし私は全然理解することができませんでした。
誰か助けてください。
＃ちょっとは訳うまくなった？
402: 327 [sage] 02/02/09 00:35 ID:??? AAS
>>395
外部ﾘﾝｸ[html]:spin.s2c.ne.jp
んで、この記事の内容が理解できないってこと？
403(1): 名前は開発中のものです。 [sage] 02/02/09 00:35 ID:??? AAS
>>395
Perhaps you mean triangle scan conversion
using 2D homogeneous coordinates,don't you?
I can't tell exactly but I've found a quick explanation
when came across the university of north Calolina's
pages a few monthes ago.
The important thing is that every homogeneous triangles can be
defined or showed as a ratio linear combination of
three vertexes.
404: 名前は開発中のものです。 [sage] 02/02/09 00:46 ID:??? AAS
395=403
英語厨房は自作自演らしいな。
405: 名前は開発中のものです。 [sage] 02/02/09 00:54 ID:??? AAS
>３２７
俺、英語で書けないんで日本語で書くけど、
確か、なんだかんだでｚは求めなければいけないんじゃなかったっけ？
求めなくても使えるよ〜ってだけで。
406: 名前は開発中のものです。 [sage] 02/02/09 00:58 ID:??? AAS
>327,395327(19): 名前は開発中のものです。 [sage] 02/02/06 00:36 ID:??? AAS
>>324
環境マップのディフューズ成分（低周波成分）を用いてライティングするということかな。
で、
今翻訳した論文では
ディフューズ成分についてなら、テクスチャマッピングではなく、
９つのパラメータによる計算で同じ結果を得られるよってことなのかな。
い？マジで？
407: 327 [sage] 02/02/09 01:26 ID:??? AAS
>>403
おそらく２次元同次座標系を用いた三角形の走査線変換を意味するのですよね？
私には正確にはわかりません、
しかし、数ヶ月前北カロライナ大学のページを訪れたとき迅速な説明をみつけたことがあります。
重要なことは、すべての同次三角形は３頂点の線形結合比率で定義される、または示されるということです。
408: 名前は開発中のものです。 [sage] 02/02/09 01:34 ID:??? AAS
英語で書かれると挑発するような煽り文章が
減るねぇ。
これからはネタ振りも英語でやってくれ。
読むだけなら出来るから。
409: 名前は開発中のものです。 [sage] 02/02/09 01:37 ID:??? AAS
chinpo!
410: 名前は開発中のものです。 [sage] 02/02/09 01:39 ID:??? AAS
>>327のおかげで英語が身近に感じられるよ。
翻訳ご苦労様。
411(1): 名前は開発中のものです。 [sage] 02/02/09 03:24 ID:??? AAS
Does anyone know any efficient method of ordering polygons
those are once coordinated by VU1's micro-programs and out
to the VU1's local memory.Ofcource in this case these
polygons must be sorted without using Z-Buffer.
#I'm ps2 linux usr.
412: 327 [sage] 02/02/09 04:09 ID:??? AAS
だれかポリゴンのオーダリングの効果的な方法しってるやついる？
>>411
ポリゴンを一度VU1のマイクロプログラムでコーディネートして、
VU1のローカルメモリに出力するんだけど。
もちろんこの場合ポリゴンはＺバッファを使わずにソートしなくちゃならないんだけど。
ちなみに俺PS2 linuxユーザー
413(4): 名前は開発中のものです。 [sage] 02/02/09 04:30 ID:??? AAS
I'm having some questions about mipmap maybe which doesn't
matter where the plat-form is.
I would like to dynamically load mipmap levels only if they
must be needed and also would like to delete them just when they
aren't needed anymore.
The question is that I must compromise to delete some textures
when many maximam size of texture are requested at the same time,you know,
if the sum size of tex becomes more than VRAM can cover.
How can I get to solve this problem even if allowed to compromise.
414(1): 名前は開発中のものです。 [sage] 02/02/09 04:43 ID:??? AAS
Can I use trianlge strips when using octrees algo?
If a strip goes through several nodes and for
example only one node is visible should I clip the strip?
Or shouldn't I use such a long stip ?
415(3): 名前は開発中のものです。 [sage] 02/02/09 04:50 ID:??? AAS
Dynaminc texture loading suppose to be done by rather dynamic texture management than mipmap. I do NOT think a specialized texture management for mipmap is worthy.
416: 名前は開発中のものです。 [sage] 02/02/09 05:34 ID:??? AAS
３ｄがんばろー！！
417(1): 名前は開発中のものです。 [sage] 02/02/09 11:15 ID:??? AAS
>>415 I quite agree with you.
Although I have no idea what platform >>413 is targetting,
I guess that loading and offloading individual mipmap levels would
generally be very inefficient and easily cause CPU or GPU to stall.
418(3): 名前は開発中のものです。 [age] 02/02/09 12:17 ID:??? AAS
I have a question regarding GeForce4 Ti.
Does someone have any idea what GL_DOT_PRODUCT_AFFINE_DEPTH_REPLACE_NV does?
This new token seems to be defined in GL_NV_texture_shader3 OpenGL extension,
which is available only on GeForce4 Ti series. Does it have something to do with
"z-correct bump mapping" mentioned in the recent review at Tom's Hardware?
外部ﾘﾝｸ[html]:www.tomshardware.com
419(2): 名前は開発中のものです。 [sage] 02/02/09 12:41 ID:??? AAS
>>418
>z-correct bump mapping" mentioned in the recent review at Tom's Hardware?
No.
420(4): 名前は開発中のものです。 [sage] 02/02/09 13:18 ID:??? AAS
Umm,it seems to be working fine as a filter as 390 said.
421(2): 名前は開発中のものです。 [sage] 02/02/09 13:22 ID:??? AAS
>>419
Have you seen the movie clips posted at the Vmag.Online?
The Tidepool demo explains the effect of z-correct bump mapping.
外部ﾘﾝｸ[html]:www.vwalker.com
It seems that whereas the actual geometry is not displaced, the depth value of the
water surface is replaced on per-pixel basis according to the height of the surface.
I think that the demo is using AFFINE_DEPTH_REPLACE operation or something.
Anyone knows what "z-correct bump mapping" means at all?
>>420
Yeah, I think so :)
Thanks.
422: 327 [sage] 02/02/09 13:25 ID:??? AAS
>>413
私はミップマップについていくつかの疑問を恐らく持っています。
たぶん、どのプラットフォームかは重要では在りません。
ミップマップが必要とれるか、今はもう必要ない場合にそのミップマップを消去したいときもまた、
私は動的に各ミップマップレベルをロードしたい。
質問は、ご存知のように多くの大きなサイズのテクスチャが同時に要求されたとき。
もしその合計サイズがVRAMがカバーできるよりも大きくなったなら、
いくつかのテクスチャの消去を妥協しなければならないことです。
たとえ妥協したとしても、どうすればこの問題を解決できますか。
423: 327 [sage] 02/02/09 13:31 ID:??? AAS
>>414
オクトツリーアルゴリズムを使用する場合、トライアングルストリップを使うことは可能ですか？
ストリップがいくつかのノードを通り抜ける場合や1つのノードだけが目に見える場合に
ストリップを切り取るべきですか？
もしくは、そのような長いストリップを使用してはなりませんか？
424: 327 [sage] 02/02/09 13:38 ID:??? AAS
>>415
動的テクスチャローディングは、ミップマップよりはむしろ動的なテクスチャ管理によってなされることになっています。
私はミップマップのための特別なテクスチャ管理が価値があると思いません。
425: 名前は開発中のものです。 [sage] 02/02/09 13:45 ID:??? AAS
>>413
I had faced to the similar case as you.
There is a good solution for running short of VRAM when using like as mipmap
but still it is not a ideal method.(as 415 said it can be remarkely
said dynamic texture management)
If you don't have to sort polygons such as no-semitrans polygons,
sort these polygons not by Z-value but by texture,yes as you guess it is
oftenly called "Texture sort"
To do like this , we can strongly decrease the traffic
between MAIN-RAM and VRAM.
上下前次1-新書関写板覧索設栞歴
あと 133 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.011s