324(2): 名前は開発中のものです。 [sage] 02/02/06 00:31 ID:??? AAS
>>322
イラディアンスってどういう技術かさわりだけで良いから教えてクレヨン。

332(3): 添削屋 [age] 02/02/06 01:05 ID:??? AAS
本当はもう添削しないつもりだったけど、
>>318の誇大評価に免じて大サービスだよ。

多くの現実のシーンにおけるライティングは複雑であり、エリアライトや、
天空光のような広範囲の連続的なライティング分布を含む様々な光源から光がやって来る。
しかし、今日のグラフィックスハードウェアは点光源や平行光源しかサポートしていない。
1つの理由は、一般的なライティング分布に対するシンプルな手続き的公式がないことである。
その代わりに、各ピクセルについて、上半球全体にわたって積分を行わなければならない。

我々は、拡散反射オブジェクト、すなわち放射照度に対する非常にシンプルな公式を提供する。
我々のアプローチで鍵となるのは、放射照度環境マップの解析的近似の高速な計算である。
レンダリングについては、インタラクティブなフレームレートで動作し、
かつハードウェアで容易に実装可能な、シンプルな手続き的アルゴリズムを示す。
このアプローチでは、放射照度の計算にテクスチャマッピングを使うは必要はない。

主な要素となるのは、ライティングの球面調和係数に関する放射照度の解析的な公式の
導出である。レンダリングについて鍵となる注目点は、ランバートのBRDFが
十分にローパスフィルタに近い振る舞いをするため、球面調和の最初の2つの次数、
すなわち9つのパラメータのみを考慮すれば十分であるということである。
この最初の9つの球面調和成分によるシンプルな形式によって、実装が簡単になる。

395(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.

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.

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.

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.

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

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.

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.

430(2): 名前は開発中のものです。 [sage] 02/02/09 14:21 ID:??? AAS
Hey 327, you made a great job for us!
(though there seem to be some minor mistranslations...)
Anyway, thanks a lot for your help.

433(1): 430 [sage] 02/02/09 18:49 ID:??? AAS
Hi 327, I'm afraid you have mistranslated the following sentences.

>>418 (last sentence)
これは、Tom's Hardwareでの最近のレビューで言及されていた
「Ｚ補正バンプマッピング」と関係があるのでしょうか？

>>420
うーむ、390の言ったとおりフィルタとしてうまく機能しているようだな。

>>421 (third paragraph)
「Ｚ補正バンプマッピング」が一体何を意味しているのか、
誰かわかる人はいませんか？

438(2): 名前は開発中のものです。 [sage] 02/02/10 06:38 ID:??? AAS
to 327
I think you did a very great job but it seems your
translation into the Japanese is calling some suck guys like as 436.
I highly recommend to stop your translating,sorry.

440(4): 名前は開発中のものです。 [age] 02/02/10 08:32 ID:??? AAS
>>434
OpenGL, the most popular graphics library in the world, requires that z value in
homogeneous clipping space be within the range between -w and w, as is the case
with your platform. Historically, I believe, this type of projection matrices
rather than DirectX-style projection matrices (0 < z < w) has been widly used.

>>437
You can use the upper-left 3x3 matrix of your transform matrix (from world space
to object space) to transform a direction vector into object space if and only if
the 3x3 matrix is orthonormal, which means the 3x3 matrix represents pure rotation
without any scaling or shearing. Otherwise (if the 3x3 matrix is not orthonormal),
you need to use the inverse transpose of the upper-left 3x3 matrix instead.

>>438
I agree. No Japanese translation is needed for us.
327, we hope you meet our request. Thanks in advance.