NVIDIA's UltraShadow in Doom3

[Randell]

also most things on teh net are .rar'd now

Most 'warez' you mean?

nope most tweaks/shareware programs/demo's/no-cd cracks (which doesn't automatically mean warez, I use a no-cd on all my games - often it speeds the game up over cd-checking) I mean, but of course your whole agenda with picking up on the use of 'Winrar' was to imply that wasn't it?

 

[SteveHill]

As I said before, R200 can implement the falloff-function through a texture (that is what I use anyway), so it doesn't have any constraints, really, it's purely NV1x/2x that has the tight constraints.

Right, I was just musing about the performance delta between using a LUT and using math with the R200, not the added flexibility that a LUT can provide. On that note, I suppose the biggest constraint that NV1x imposes is it's tricky to support a variable exponent, which is doable with the NV20 and certainly R200 in OGL. Of course, then artists have more to deal with .

I find it a rather strange choice to base everything on the lowest common denominator.

Yes it is perhaps a little ideological, but it does mean that it's WYSIWYG for artists.

He's had 5 years to experiment, I find the things he comes up with at release time rather poor to be honest.

Personally I'm not at all disappointed. He's probably been spending the last year R&Ding The Next Big Thing too.

 

[thana]

Winrar should be used by most computer enthus in the know, as has much better compression than winzip.

Then why aren't they using WinACE?

Because RAR has better overall compression than ace since version 3.0. the only alternative that has better compression than rar and comparable en- and decoding speeds is 7-zip. (yes, there are many other compression programs out there that have better compression than both, but those are generally several orders of magnitude slower).

 

[Cryect]

Winrar should be used by most computer enthus in the know, as has much better compression than winzip.

Then why aren't they using WinACE?

Because RAR has better overall compression than ace since version 3.0. the only alternative that has better compression than rar and comparable en- and decoding speeds is 7-zip. (yes, there are many other compression programs out there that have better compression than both, but those are generally several orders of magnitude slower).

Ahh haven't seen recent comparisons. Really though I find the compression differences between the best compression programs to the worse isn't enough to worry about oftentimes (for anything less than 100 megs I don't really care about +/- 10 megs difference since that normally means +/- a minute at most oftentimes on a fast connection, and anything of larger size is normally in a compressed formed for its usable format). Definately matters though to those who host files and pay based on amount transferred.

Anyways I guess back to more on topic ^_^ which this thread hasn't seemed to be for at least a page

 

[Scali]

Right, I was just musing about the performance delta between using a LUT and using math with the R200, not the added flexibility that a LUT can provide.

Since the R200 has a very strict instruction-limit (and no pow() instruction), a texture-lut seems like the obvious thing to do.

On that note, I suppose the biggest constraint that NV1x imposes is it's tricky to support a variable exponent, which is doable with the NV20 and certainly R200 in OGL.

How do you do it with the NV20 in OGL then? In D3D it's simply not possible to normalize a vector, do a dot3 with a normalmap texture, and then use the result for a texture lookup in a single shader in ps < 1.4.

 

[SteveHill]

Since the R200 has a very strict instruction-limit (and no pow() instruction), a texture-lut seems like the obvious thing to do.

Agreed and it can give you more flexibility as mentioned (plus below).

How do you do it with the NV20 in OGL then? In D3D it's simply not possible to normalize a vector, do a dot3 with a normalmap texture, and then use the result for a texture lookup in a single shader in ps < 1.4.

You're correct, it's not doable in ps1.1*, but it's possible to pull off the old (N.H,H.H) lookup using texture shaders with NV20:
http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=010159 (see Eric Lengyel's post).

* Oh actually, in searching for the above link, I was reminded of Matt Halpin's ShaderX^2 approach. It gives you an approximate variable exponent plus normalisation in ps1.1, although the half-angle basis hack probably lacks robustness: http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/009403.html

 

[Scali]

Ah, that cubemap with precomputed exponent is quite a nice trick. Sadly it seems to waste 2 extra texcoords for interpolating the lightspace axes (that could get tight with only 4 texcoords anyway), and the cubemap itself is also less compact than a simple exponent texture.

I wonder how good that other method looks, the screenshot is gone, sadly.

 

[SteveHill]

Ah, that cubemap with precomputed exponent is quite a nice trick. Sadly it seems to waste 2 extra texcoords for interpolating the lightspace axes (that could get tight with only 4 texcoords anyway), and the cubemap itself is also less compact than a simple exponent texture.

Yes there's a bit of texture and unit waste unfortunately, which probably means spilling things over into yet another pass (assuming that's workable).

I wonder how good that other method looks, the screenshot is gone, sadly.

I believe I originally saw the (n.h, h.h) trick in some ATI presentation or two a while back. There's also an article in GPG3.

 

[Humus]

Why not just say "unzip it" then? Some people might go to the trouble of downloading WinRAR when they already have XP/WinZip/pkunzip/infoZip etc .

WinRAR pwns all those apps. 8)

 

[Humus]

But where in the .pak files is it? At least, that's how I read digi's post. I'm going to start looking myself...

Thanks Steve and Ostsol, that does help me understand it a bit better...but Chalnoth nailed me question, I'm really curious just to see this table.

I believe this texture is the one:

(Expanded it to 16 in height so you can see it better)

 

[SteveHill]

I believe this texture is the one:

(Expanded it to 16 in height so you can see it better)

Strange, when I dumped it only the red component was set, which, now that I think about it, is at odds with the way it's used.

I PM'd it to digitalwanderer earlier, although he doesn't seem to have noticed .

 

[KimB]

How did you get this texture, Humus?

 

[Humus]

GLIntercept.

 

[Humus]

Strange, when I dumped it only the red component was set, which, now that I think about it, is at odds with the way it's used.

Yes, it was red for me too. Don't know if that's the real texture or if it's just GLIntercept that extracts luminance textures to red only. Would make more sense to use a luminance texture than RGBA8 but only use the red component.

 

[digitalwanderer]

I got the PM Steve, I just thought there was an error since it was just a red line.

So the "chart" is just a little blurb of color? I was expecting a huge table filled with numbers or something, thanks for showing/explaining it to me.

 

[Humus]

Well, here it's in hex if you so prefer:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 02 02 03 04 05 07 07 09 0b 0c 0e 10 12 14 16 19 1b 1e 21 23 27 2a 2d 31 35 39 3d 40 45 49 4e 53 58 5d 62 67 6d 72 79 7f 85 8b 92 98 9f a6 ad b5 bd c4 cc d4 dc e4 ed f6 ff

 

[KimB]

Hmm, thanks. Nabbed GLIntercept myself, and I'm currently attempting to decipher one of these display lists that has a Register Combiner program in it, to see if this is the calculation for specular, and what the calculation actually does (I executed the NV20 path).

Edit:
Man, it's a damned good thing nVidia moved away from Register Combiners. Wow, they're hard to read. Anyway, this is the combiner that I think does the specular calculations:

glNewList(4,GL_COMPILE)
glCombinerParameteriNV(GL_NUM_GENERAL_COMBINERS_NV,3)
glCombinerInputNV(GL_COMBINER0_NV,GL_RGB,GL_VARIABLE_A_NV,GL_TEXTURE1,GL_EXPAND_NORMAL_NV,GL_RGB)
glCombinerInputNV(GL_COMBINER0_NV,GL_RGB,GL_VARIABLE_B_NV,GL_TEXTURE0,GL_EXPAND_NORMAL_NV,GL_RGB)
glCombinerOutputNV(GL_COMBINER0_NV,GL_RGB,GL_SECONDARY_COLOR_NV,GL_DISCARD_NV,GL_DISCARD_NV,GL_SCALE_BY_TWO_NV,GL_BIAS_BY_NEGATIVE_ONE_HALF_NV,true,false,false)
glCombinerInputNV(GL_COMBINER1_NV,GL_RGB,GL_VARIABLE_A_NV,GL_SECONDARY_COLOR_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glCombinerInputNV(GL_COMBINER1_NV,GL_RGB,GL_VARIABLE_B_NV,GL_SECONDARY_COLOR_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glCombinerOutputNV(GL_COMBINER1_NV,GL_RGB,GL_SECONDARY_COLOR_NV,GL_DISCARD_NV,GL_DISCARD_NV,GL_SCALE_BY_TWO_NV,GL_BIAS_BY_NEGATIVE_ONE_HALF_NV,false,false,false)
glCombinerInputNV(GL_COMBINER2_NV,GL_RGB,GL_VARIABLE_A_NV,GL_SECONDARY_COLOR_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glCombinerInputNV(GL_COMBINER2_NV,GL_RGB,GL_VARIABLE_B_NV,GL_TEXTURE3,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glCombinerInputNV(GL_COMBINER2_NV,GL_RGB,GL_VARIABLE_C_NV,GL_ZERO,GL_UNSIGNED_INVERT_NV,GL_RGB)
glCombinerInputNV(GL_COMBINER2_NV,GL_RGB,GL_VARIABLE_D_NV,GL_ZERO,GL_UNSIGNED_INVERT_NV,GL_RGB)
glCombinerOutputNV(GL_COMBINER2_NV,GL_RGB,GL_SECONDARY_COLOR_NV,GL_SPARE0_NV,GL_DISCARD_NV,GL_SCALE_BY_TWO_NV,GL_ZERO,false,false,false)
glFinalCombinerInputNV(GL_VARIABLE_A_NV,GL_CONSTANT_COLOR1_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_B_NV,GL_SECONDARY_COLOR_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_C_NV,GL_ZERO,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_D_NV,GL_E_TIMES_F_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_E_NV,GL_TEXTURE2,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_F_NV,GL_CONSTANT_COLOR0_NV,GL_UNSIGNED_IDENTITY_NV,GL_RGB)
glFinalCombinerInputNV(GL_VARIABLE_G_NV,GL_ZERO,GL_UNSIGNED_IDENTITY_NV,GL_ALPHA)
glEndList()

Now I just have to figure out what it does.

 

[Quitch]

Winrar should be used by most computer enthus in the know, as has much better compression than winzip.

Then why aren't they using WinACE? And really besides 'warez' I rarely see items rarred. I would say roughly less than 10% of things I download are not zipped.

More things I download are tgz compressed than rarred...

Crap interface? General all round inferior to WinRAR product? Yep, that's why.

I don't know where this "most things aren't zipped" came from. Any files for Windows is zipped 99% of the time. This might not be true for warez, I don't know, but I can't recall the last time I saw a RAR file. It's ZIP or TAR GZIP file.

 

[Simon F]

Crap interface?

What the hell is wrong with... ?

Prompt> tar czvf stuff.tgz  directory1 directory2 etc.....

Bahh.. You're just weak.

 

[SteveHill]

Yes, it was red for me too. Don't know if that's the real texture or if it's just GLIntercept that extracts luminance textures to red only. Would make more sense to use a luminance texture than RGBA8 but only use the red component.

From the shader code, you'd expect f(x) to be in all components, so my guess is that GLIntercept isn't replicating luminance.