More than a year on and shaders are unimpressive

[Hyp-X]

An original GeForce just won't be able to run in high details.

I agree.

Dot3 is sufficient to do diffuse per-pixel lighting. (I'd just avoid the term bump-mapping if possible.)

For specular per-pixel lighting you need a dot3 and a power-of operation. I see no way of doing that on Geforce 1/2 class hw. You can do that on dx8 class hardware using dependent texturing using that as a lookup table. You'll be able to do this with the "pow" instruction of dx9's pixel shader as well.

 

[Dave Baumann]

It does appear to me that developers have so far fallen into the trap that I pointed out in our Radeon 8500 review and so far we've only really seen pixel shader effects on water locations. It will be nice to see developers get a little more creative with the effects, however I suppose that will only come when board that can this are a little more widespread which will give the developer confidence that they will be used.

 

[DemoCoder]

I agree.

Dot3 is sufficient to do diffuse per-pixel lighting. (I'd just avoid the term bump-mapping if possible.)

For specular per-pixel lighting you need a dot3 and a power-of operation. I see no way of doing that on Geforce 1/2 class hw. You can do that on dx8 class hardware using dependent texturing using that as a lookup table. You'll be able to do this with the "pow" instruction of dx9's pixel shader as well.

Nope, you don't need pow(). A reasonable approximation for exponents between 1 and 8 can be done by shifting. Ghost of Envy posted a demo on B3D along time ago demonstrating not just per-pixel specular without using dependent lookups, but per-pixel phong shading, doing normalization per-pixel via Newton-Raphson approximation. This works with simple register combiners. (e.g. pixel shaders) It's true that it's just an approximation, but good high performance 3D graphics is the art of cheating. (witness Doom3 high-poly imposters)


I think what non-developers don't understand is that "pixel shaders" are merely just an extension of multitexturing. We are still dealing with the same basic pipeline operations: add, sub, mul, dot3, etc. The only difference is, with pixel shaders, you can do more of them in a single pass, and with alittle more flexibility in composing the operations. Yes, some cards can now do dependent lookups as well, or 3D textures, etc, but that is besides the point: you can do ALOT with just basic add, mul, and dot3. Up until recently, most developers were using the multitexture capability of today's 3D hardware for the same thing that glQuake1 was using them for -- shadow maps (and other lighting masks) Alot can be done with basic multitexturing of even pre-DX8 cards that no one bothered with (probably because of lack of performance)


It's not what you have, it's how you use it. Doom3 demonstrates the power of DOT3 if used correctly. (it also demostrates how to use other things effectively, like stencil, etc) Doom3 is just taking advantage of OLD features that cards years ago had. The only difference is that now

1) a large segment of the market had DOT3 capable cards and
2) performance had reached the point where Carmack could use it heavily and get the result he wanted.


I don't know what Rev means when he says "pixel shaders"? I mean, Doom3 is using per-pixel calculations everywhere for all kinds of computations. Just because it's using basic OpenGL dot3 and blending modes and not "DX8 pixel shaders" don't mean that it's not using "pixel shaders" (or "fragment shaders")


Doom3 is a *quantum leap* IMHO in visuals (especially LIGHTING) over every other 3D engine to date. If Rev thinks the engine is unimpressive visually, I'll just have to agree to disagree. There's just no common ground for argument and clearly it must be a matter of aesthetics (or lack of)

 

[PSarge]

I think what non-developers don't understand is that "pixel shaders" are merely just an extension of multitexturing. We are still dealing with the same basic pipeline operations: add, sub, mul, dot3, etc. The only difference is, with pixel shaders, you can do more of them in a single pass, and with alittle more flexibility in composing the operations.

I would beg to differ. I would say that "Register Combiners" are an extension of Multitexturing, not "Pixel Shaders", where RC's are a subset of PS's. The trouble is that RC's are what we have now on the Geforce, Radeon & Parhelia (To varying degrees), so there is a limit to what you can do. These are only the first totering steps into Pixel Shader land.

Once you get a more flexible pipeline and more flexible PS's (which is the way that OGL2 and DX9 seem to be wanting to push things) then I think you'll see more unique effects. I can belive that we might not see big strides for a generation or two though.

So, I guess I agree with DemoCoder. The reason you haven't seen anything that blown your mind is becuase the hardware we have is just an evolution of what was there before. Only I would add that Pixel Shaders will have more to offer in the future. We ain't done yet.

It's not what you have, it's how you use it.

Very true. (On sooooo many levels)

 

[Bjorn]

To add something to Democoders last post:

Jim Dose, ID Software

By the way, let me give you a piece of advice regarding hardware configuration: you won't see what DOOM's like on video cards below GeForce 3. With per-pixel lighting and bump-mapping turned off, you just won't see DOOM III. Yes, the game can be run on GeForce 1, but my urgent message is as follows: go buy GeForce 3 or better".

So, it seems that no pixelshaders = no per-pixel lighting and no bump-mapping in Doom3.

What then, vertex lighting ?

 

[Dave Baumann]

So, it seems that no pixelshaders = no per-pixel lighting and no bump-mapping in Doom3.

That could be in be a performance thing i.e. the per-pixel lighting/bump mapping have to be turned off to sustain any type of performance in the Doom3 engine beloe GF3 level hardware.

 

[DemoCoder]

II would beg to differ. I would say that "Register Combiners" are an extension of Multitexturing, not "Pixel Shaders", where RC's are a subset of PS's. The trouble is that RC's are what we have now on the Geforce, Radeon & Parhelia (To varying degrees), so there is a limit to what you can do. These are only the first totering steps into Pixel Shader land.

I would beg to differ too! The current DX8 "pixel shaders" are actually a subset of GF3 register combiners. The OpenGL interface for NV_register_combiners2 allows one to do things not possible in DX8 PS because of the multiple output nature of the combiners (e.g. can do A.B, AB, and AB+CD using only a single combiner)

I would agree that the current shaders are somewhat limited, allowing only 16 per pixel operations in total (8 scalar, 8 vector). And PS1.4 isn't much better.

However, even with the limited number of operations available in PS1.1 or PS1.4, you can accomplish a great many things. Most lighting revolves around combinations of a few simple quantities: the local normal, light vector, eye vector, half angle vector, etc I've looked at some pretty slick RenderMan surface shaders that only used a few ops and no loops.

I'd say the lack of interesting pixel shader effects to this day has been caused by several things:

1) no market demand -- widespread lack of DX8 capable, or even DOT3 capable hardware. Takes a lot of extra content creation work to utilize effectively, little reward. Game engine has to be designed from the ground up to avoid doing the effects "piece meal", and frankly, 2 years ago when most new engines being used today started getting written, there was even less pixel shading hardware out there.

2) lack of performance. Using 3 or 4 textures all ovee the scene was probably prohibitively slow until latest hardware gen

3) difficultly in doing something "new". Water? Seen it. Shiny Bumpy? Bo-ring. Reflections? Yawn. Translucence? Refraction? Per pixel shader? All seen in demos before, nothing new.

4) Per pixel lighting only takes you so far. Realism comes in large part from global lighting algorithms, including shadows. Seeing a game with realistic, dynamic, shadows and ambient lighting is far more impressive, far more real looking, then same old Quake-engine style lighting that every game up till Q3 has had.

5) real value of per pixel generalized shading will be realized by procedural texture effects, infinite non-repeating textures with mega zoom capability and not much texture ram storage required. Also, per pixel programmable displacement mapping will be big.

 

[Bjorn]

So, it seems that no pixelshaders = no per-pixel lighting and no bump-mapping in Doom3.

That could be in be a performance thing i.e. the per-pixel lighting/bump mapping have to be turned off to sustain any type of performance in the Doom3 engine beloe GF3 level hardware.

I agree.

It would be interesting to get some clarification on this though.

As in:

You can turn it on it but it would be <= 10 fps
or
You can't because of the way the engine works

 

[Dave Baumann]

You can turn it on it but it would be <= 10 fps
or
You can't because of the way the engine works

Although I have no more information on the engine and what it uses than anyone else my assumption is that it could be done, just very slowly - i.e. it appears these effects are done via Dot3 (or so this thread says) which are all perfectly do-able on GeForce256/GTS level hardware, however doing it would require many passes to external memory as it doesn't have the multi-texture abilities of Radeon/GF3 level hardware.

My other reason for saying this is that, AFAIK, JC has stated in the past his dislike of supporting propriety extensions and currently to support vertes/fragment (Pixel) shaders under OpenGL he would have to support both NVIDIA and ATI's extensions (although ATI's will likely be supported by Matrox as well it seems), both of which have very different coding paths so, his code would have to be branched to support these two methods. I would be surprised if JC has supported much outside of the core OpenGL1.3 featureset, however its possible that he may have.

This diversion of OpenGL shader routines, by the sound of things, will not be resolved until OpenGL 2.0 is available, at which point will likely be far too late for the majority of work done on the DoomIII engine.

 

[Teasy]

it appears these effects are done via Dot3 (or so this thread says) which are all perfectly do-able on GeForce256/GTS level hardware, however doing it would require many passes to external memory as it doesn't have the multi-texture abilities of Radeon/GF3 level hardware.

Don't forget Kyro Not that I neccesarilly think Kyro II will run Doom3 well with the per pixel lighting and bump mapping turned on, but it does have multi-texturing capabilities in excess of Radeon and Geforce 3/4.

 

[Joe DeFuria]

KryoII might not be all that great, but what about Kyro III? Oh, wait....

 

[Bjorn]

My other reason for saying this is that, AFAIK, JC has stated in the past his dislike of supporting propriety extensions and currently to support vertes/fragment (Pixel) shaders under OpenGL he would have to support both NVIDIA and ATI's extensions (although ATI's will likely be supported by Matrox as well it seems), both of which have very different coding paths so, his code would have to be branched to support these two methods. I would be surprised if JC has supported much outside of the core OpenGL1.3 featureset, however its possible that he may have.

Hasn't Carmack mentioned that he's doing different codepaths for the GeForce 3-4, Radeon 8500, "pre Geforce 3 features" hardware and so forth ?

That of course doesn't mean that he's using propriety extensions but he has mentioned before that he will take advantage of the register combiners of the GeForce 2 to gain some speed/quality. So i don't think he'll hesitate to use the propriety stuff of the the Radeon 8500/GeForce 3-4 if he can gain performance/quality by doing it.

 

[Teasy]

KryoII might not be all that great, but what about Kyro III? Oh, wait

That's sort of irrelivent to this discusion but Kyro III should run it very well. And as long as the new partner (if their is one yet) hasn't decided that they don't want to buy that chip from STM then it'll easily be out before for Doom III considering Doom III's release schedule.

I just hope Carmack supports all 8 textures in a single pass for Kyro II and gives an option to change the number of textures per pass. I've always wanted to see what sort of a performance difference would occur by going from 8 passes for 8 textures to one pass for 8 textures.

BTW Joe, do you follow me around this forum or something? I know you like me but this is rediculous

 

[Joe DeFuria]

Heh...just poking a little fun!

No, I don't follow you around...I've been posting here rather consistently the past few weeks...I just haven't seen you post here in quite a while.

It would be interesting to see how KyroII would perform if Carmack directly supports it, but I wouldn't expect much. It just (like other "GeForce2 class" boards) doesn't have the raw fill rate IMO.

Assuming Kyro III has the effecitve fill rate to be competitve with GeForce3+ class hardware, that could be very interesting indeed. Although it's not looking like we'll seem Doom III until the latter half of next year. If that's the case, I'd hope that Kyro III (as we have known it) will not be PowerVR's best offering.

 

[Teasy]

Heh...just poking a little fun!

Yeah same here as far as the follwing me around comment goes.

I just haven't seen you post here in quite a while.

I've become increasingly more involved in the console forum in the runnup to GameCube and XBox's release. Between that forum, this forum, Paraknowya's forum, PVR-Net forum, PVR-Extremist forum, overclockers.co.uk forums, thedvdforums ect it was starting to get far too time consuming. I decided that I had to put allot less time into either this forum or the console forum (considering their my two most time consuming forums). Considering everything that's happening in the console world right now I decided I was most interested in posting in the console forum for now. I do still look at this forum now and again though.

It would be interesting to see how KyroII would perform if Carmack directly supports it, but I wouldn't expect much.

Neither would I, but I would expect probably better performance then a Geforce 2 if Carmack does support it, given that he's using allot of textures and also stencil buffering. But that won't be enough to make it really playable in Doom3 at any decent resolution... or its extremely unlikely too anyway.

Assuming Kyro III has the effecitve fill rate to be competitve with GeForce3+ class hardware, that could be very interesting indeed.

According to IMGTEC Kyro III is currently highend, so I take from that that its somewhere around either Geforce 3 TI 500 or Geforce 4 in performance in mosy situations.. possibly faster in some (maybe FSAA) and slow in others.

Although it's not looking like we'll seem Doom III until the latter half of next year. If that's the case, I'd hope that Kyro III (as we have known it) will not be PowerVR's best offering.

I did hear rumours a little while back that the new partner (at that time to my knowledge then new partner was already found) may not be interested in Kyro III because of the need to actually buy the chip and name from STM. And by the time they had built their own series 4 chip it would be a low end card. So they had decided to pass it by and move onto Series 5. But for the last few months rumours on this subject have pretty much stopped alltogether. So I have no idea what has happened to the partner that was meant to already have been found months ago.

I do know that Series 5 is now in advanced development and they've started looking into Series 6 though. I would also hope that by late next year they have something better then Series 4. After all Series 4 has been complete now for several months so to have the current Series 4 tech (with the currently known specs) as their best chip in late 2003 would be a but poor IMO.

 

[Randell]

After all Series 4 has been complete now for several months so to have the current Series 4 tech (with the currently known specs) as their best chip in late 2003 would be a but poor IMO.

not if by high end they meant Gf4Ti4600 performance without AA, 'MSAA4Free' was part of the package and price point was currently equal to Gf3Ti200/8500LE. I'm ambivilent about DX9 requirement as I dont see the need to get a DX9 chip for a couple of years if DX7 & DX8 is anything to go by.

 

[MDolenc]

Doom III rendering pipeline basically looks something like this:
First it renders COMPLETE scene with all but ambient light off and without textures. This pass is VERY quick (and you don't burn much memory bandwidth). After this pass z buffer is filled with correct (and final) depth information for each pixel on screen and z writes are turned off.
Then for EACH (per pixel) light:
1. Render shadow volumes of all shadow casters into stencil buffer. This is again fast pass (no textures used), but you can burn here much fill rate because of overdraw (Doom II probably has some optimisations to reduce this overdraw).
2. Add light contribution to pixels that have stencil=0 (they are not in shadow). This looks something like this for diffuse point light:
Temp=NormalMap dot3 LightDirection
Temp=Temp mul AttenuationMap
Temp=Temp mul LightColor
Result=Temp mul MaterialTexture

Total number of render passes is (greatly) influenced by the number of per pixel lights used. When Carmack said he does two passes on GeForce 3/4 and one on Radeon 8500 he actually meant number of passes PER light (if you don't believe me ask him). GeForce 3 "could" (now this is my pure instinct) handle about 3 maybe 4 per pixel lights per frame (that is with 30fps) which actually means 8-10 passes (not always fullscreen but still)!! Radeon 8500 would take 5-6 passes which saves him some t&l work.
All in all this kind of pipeline is STILL much more hardware friendly than what most games do today, because it takes advantage of "bandwidth saving technologies" (such as LMA II). Engine actually draws z buffer in one quick pass and than the z buffer does not change anymore. Thus expensive pixels get rejected VERY early. It's LMA II that makes GeForce 4 "constantly faster then Radeon 8500 in DOOM III" (according to Carmack).

As for the Kyro 2: Kyro MIGHT run Doom III IF Carmack will disable per pixel normalization of LightDirection (see up). LightDirection is actually a cube map texture and Kyro does not support cube mapping.

GeForce 1/2 will run Doom III on lower resolutions and with fewer per pixel lights per frame (and maybe without per pixel normalized LightDirection - no cube maps and LightDirection can be stored in diffuse or specular color component of vertex, but you will have to ask Carmack for this). Same goes for Radeon 7500.

As for the pixel shaders vs. register combiners: As DemoCoder said pixel shaders (DirectX term) ARE subset of register combiners. Pixel shader programs are still compiled into register combiner code in drivers. Register combiners (+ "texture shader" extension to handle texture addressing) can do anything that pixel shaders can + more. GeForce 1/2/4 MX have 2 general combiners (each general combiner means one "instruction"), GeForce 3/4 has 8. Pixel shaders have 8 instructions (+4 or 6 (PS.1.4) texture address instructions). But you can do, for example, TWO dot products in ONE register combiner. This takes you 2 (out of 8) instructions in pixel shaders!
Pixel shaders are really just math instructions. If you want reflection then you have to use render to texture capability and probably cube mapping, if you want refraction you have to use texture lookup capability (environment bump mapping), etc.
Pixel shaders (or register combiners, or standard SetTextureStageState in Direct3D) just tell graphics card what to do with all those textures, constants and temporary variables.

How can someone compare dot product 3 (vector math operation) with S3TC (texture compression) remains total mystery to me...

If you read all these, then you are good.
If you understand it you are even better !

P.S.: It's not only that DX9 will be better, it's that cards that will fully support it (mainly PS.2.0) will be MUCH faster then today high end (DX8) cards.
P.S.2: Chalnoth: Can you ask Carmack about per pixel normalization in GeForce 1/2 codepath ?

 

[Teasy]

Randell, yeah you could be right there. But still no matter how fast the current Series 4 tech is, considering its already been finished for a little while and that Series 5 is already in advanced development I would still hope that the currently finished Series 4 Kyro III chip is not the best around from IMGTEC in around 15-16 months from now (late 2003). Because surely they should have Series 5 finished before then.

I suppose we'll just have to wait and see, I just wish IMGTEC and/or STM would release some sort of clear statement on what is going on with PowerVR, Kyro III and the new partner. Because allot of people have really lost patience not just waiting for Kyro III but just waiting for info on it. If people were kept more up to date they would be more inclined to wait IMO.

 

[Randell]

yeah my bad, I read your late 2003 as late 2002

 

[Hyp-X]

Nope, you don't need pow(). A reasonable approximation for exponents between 1 and 8 can be done by shifting. Ghost of Envy posted a demo on B3D along time ago demonstrating not just per-pixel specular without using dependent lookups, but per-pixel phong shading, doing normalization per-pixel via Newton-Raphson approximation. This works with simple register combiners. (e.g. pixel shaders) It's true that it's just an approximation, but good high performance 3D graphics is the art of cheating. (witness Doom3 high-poly imposters)

Do you have any details? (or links)

How many passes are used by that algorithm?

Is it possible to do that with D3D?