Z-correct bump mapping and tile rendering

Discussion in 'Architecture and Products' started by nAo, Feb 11, 2002.

  1. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    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
     
  2. Kristof

    Regular Alpha

    Joined:
    Jan 30, 2002
    Messages:
    733
    Likes Received:
    1
    Location:
    Abbots Langley
    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~
     
  3. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    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
     
  4. MfA

    MfA
    Legend

    Joined:
    Feb 6, 2002
    Messages:
    6,705
    Likes Received:
    458
    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>
     
  5. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco

    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
     
  6. Humus

    Humus Crazy coder
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    3,217
    Likes Received:
    77
    Location:
    Stockholm, Sweden
    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>
     
  7. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,741
    Likes Received:
    105
    Location:
    Taiwan
    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.
     
  8. Kristof

    Regular Alpha

    Joined:
    Jan 30, 2002
    Messages:
    733
    Likes Received:
    1
    Location:
    Abbots Langley
    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~
     
  9. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,741
    Likes Received:
    105
    Location:
    Taiwan
    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.
     
  10. Simon F

    Simon F Tea maker
    Moderator Veteran

    Joined:
    Feb 8, 2002
    Messages:
    4,560
    Likes Received:
    157
    Location:
    In the Island of Sodor, where the steam trains lie
    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>
     
  11. darkblu

    Veteran

    Joined:
    Feb 7, 2002
    Messages:
    2,642
    Likes Received:
    22
    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.
     
  12. nAo

    nAo Nutella Nutellae
    Veteran

    Joined:
    Feb 6, 2002
    Messages:
    4,325
    Likes Received:
    93
    Location:
    San Francisco
    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
     
  13. 3dcgi

    Veteran Subscriber

    Joined:
    Feb 7, 2002
    Messages:
    2,432
    Likes Received:
    261
    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?
     
  14. pcchen

    pcchen Moderator
    Moderator Veteran Subscriber

    Joined:
    Feb 6, 2002
    Messages:
    2,741
    Likes Received:
    105
    Location:
    Taiwan
    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.
     
Loading...

Share This Page

  • About Us

    Beyond3D has been around for over a decade and prides itself on being the best place on the web for in-depth, technically-driven discussion and analysis of 3D graphics hardware. If you love pixels and transistors, you've come to the right place!

    Beyond3D is proudly published by GPU Tools Ltd.
Loading...