Z-correct bump mapping and tile rendering

[nAo]

I just saw gf4 presentation video from nvidia site and I noticed there is a demo showing <z-correct> bump mapping. I don't have any docs about PS1.3 but it seems to me that the z-buffer is modified during pixel shader execution. More, I read PS2.0 preliminary specs and in the new syntax are explicitly exposed some output registers like out and zout, to write pixel shaders output(s) to different color buffers and to the z-buffer. Now..how can a deferred rendering architecture cope with such <features> without resorting to work like a traditional IMR?
Does that mean will never see a TBR based dx9+ card?
Sorry if doesn't make any sense at all...

ciao,
Marco

 

[Kristof]

While I have not looked at the specifics there are already today last minute Z changing operations like alpha test, color key etc. In those cases the final texture fetch determines visiblity. So if that is supported it should also be possible to support any kind of other, be it pixel shader based Z manipulation. Obviously the efficieny will drop since you can not predict the outcome of something texture based until you have fetched the actual texture deta (or in the case of a pixel shader have executed the full shader).

K~

 

[nAo]

Correct me if I'm wrong, but afaik actual z-updating states can't modify the z-buffer in the sense that the application (e.g. pixel shader) can write whatever value. With a fixed pipeline u can just make un update or non-update decision on zbuffer.
(stencil test are more general, permitting some aritmetic operations, but the selected stencil mode is costant across all the polygon, afaik). What if the shader push a value that can potentially destroy informations collected about other tiles?
I'm a bit confused here...if I back-project a z-buffer modified (by the shader) point in world space and reproject it in screen space, can it end in another tile?
A lot of questions here..:smile:
Where can I find some specs about PS1.3 instruction set?

ciao,
Marco

 

[MfA]

How is there a problem? Are you saying with PS2.0 you can actually change the coordinates for the pixel being drawn?

Personally I would assume not, Z might be changed but thats just screenspace Z ... which would mean it would just have to be rendered as a transparant surface.

<font size=-1>[ This Message was edited by: MfA on 2002-02-11 23:57 ]</font>

 

[nAo]

Personally I would assume not, Z might be changed but thats just screenspace Z ... which would mean it would just have to be rendered as a transparant surface.

Ok..let assume we are going to just change z-screenspace and not z-world, drawing like a transparent surface, so we are going to draw all these polygons in a tile like a IMR would do..in the same order they were sent down trough the pipeline.

ciao,
Marco

 

[Humus]

Changing the z-value in a shader would pretty much screw up any TBR/early z-culling/HierarchicalZ implementation. I would guess that these kinds of optimizations would be disabled for shaders which contains instructions that change the z.

<font size=-1>[ This Message was edited by: Humus on 2002-02-12 02:00 ]</font>

 

[pcchen]

PS 1.3 has an instruction which can replace the Z value of the pixel. See here

This is the PS 1.4 version, which performs (almost) the same function.

 

[Kristof]

You can only change the z-value of the pixel, not its on-screen position. Main use of these trick are the so called "z-correct" imposters and even there its usability is very doubtful. Note that this kind of processing ruins any early-z system.

K~

 

[pcchen]

I think for Z corrected bump mapping and sprites, it could be better using a displacement scheme (add/minus a value to current Z value), not a replacement scheme (as in current DX8 pixel shaders). The 3D chip has no idea about the possible Z range of a pixel in replacement scheme. However, in a displacement scheme, it is possible to compute a maximum range, thus many early Z optimization will still be partially useful.

 

[Simon F]

I object to the way it's been described as "Z-Correct". It isn't.

AFAICS this technique assumes that the objects are "flat on" to the viewer - if they aren't then it's going to produce incorrect results. If you have these "bumps" on one surface protruding through another object (which is the only way they'd look any different to a flat object anyway), then the bumps will surely shift around as the objects are rotated.

As for handling this kludge on a TBR, it'd be no different (in principle) to alpha tests.

_________________
"Your work is both good and original. Unfortunately the part that is good is not original and the part that is original is not good." - Samuel Johnson


<font size=-1>[ This Message was edited by: Simon F on 2002-02-12 09:55 ]</font>

 

[darkblu]

I'm a bit confused here...if I back-project a z-buffer modified (by the shader) point in world space and reproject it in screen space, can it end in another tile?

a change in Z in screen space corresponds to a change along a line that passes through the focal point in world space. so you can modify Zscr as much as you want (i.e. from -inf to +inf) -- it still won't leave its tile even after an infinitely-long inverse/forward mapping sequence.

 

[nAo]

a change in Z in screen space corresponds to a change along a line that passes through the focal point in world space. so you can modify Zscr as much as you want (i.e. from -inf to +inf) -- it still won't leave its tile even after an infinitely-long inverse/forward mapping sequence

Yeah..that was clear once I discovered pixel shader can't modify where the pixel will end on the frame buffer :smile: Changing z in the screen space gives the same vector, with the same direction, one can only modify its modulo.

ciao,
Marco

 

[3dcgi]

Can the shader make a pixel visible when early z would have rejected it? Or can it only change the z to make it not visible or visible, but by a different amount?

 

[pcchen]

The current design allows a pixel shader to completely replace the Z value of a pixel. That is, early Z can not be used because it may incorrectly reject some pixels.

A displacement method (add/subtract some values to the current Z of a pixel) with hinted (explicit or implicit) maximum displacement should fit better to early Z schemes.