Z-correct bump mapping and tile rendering

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~

 

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>

 

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>

 

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.

 

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~

 

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.

 

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>

 

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.

 

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?

 

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.