tag:blogger.com,1999:blog-6950833531562942289.post8301791053974471060..comments2024-03-25T03:36:48.099-07:00Comments on C0DE517E: Know your ZDEADC0DEhttp://www.blogger.com/profile/01477408942876127202noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-6950833531562942289.post-88422743584172411862010-08-20T23:11:35.659-07:002010-08-20T23:11:35.659-07:00Why don't you try? I don't predict anythin...Why don't you try? I don't predict anything good, but who knows :)<br /><br />FxComposer is your friendDEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-28430678675331650722010-08-20T12:19:12.530-07:002010-08-20T12:19:12.530-07:00Nice article! How about this?
hPos.xy /= hPos.w;
...Nice article! How about this?<br /><br />hPos.xy /= hPos.w;<br />hPos.w = 1;Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-28743114027106135742010-08-17T23:29:27.610-07:002010-08-17T23:29:27.610-07:00MJP: Yes, I know that article and it's very ne...MJP: Yes, I know that article and it's very neat. <br /><br />I don't think it's 100% accurate, but I agree that floating point depth is in general better (and that's why indeed W buffering is not really supported nowadays).<br /><br />For example when it says: "Given that the gradient is constant across the primitive it's also relatively easy to compute the exact depth range within a tile for Hi-Z culling" - I don't think this is true at all, Hi-Z gets quads as inputs as everything really past the rasterizer, quads do know all their interpolated attributes, the gradients are indeed computed by finite differences on the quads values, so I don't think the linearity of Z/W in screenspace comes into play.<br /><br />"Assume for instance that you want to do edge detection on the depth buffer, perhaps for antialiasing by blurring edges. This is easily done by comparing a pixel's depth with its neighbors' depths. With Z values you have constant pixel-to-pixel deltas, except for across edges of course. This is easy to detect by comparing the delta to the left and to the right, and if they don't match (with some epsilon) you crossed an edge. And then of course the same with up-down and diagonally as well" - This sounds like a lot of processing, and it does not sound like a smart idea. The gradient will be constant across a primitive, but in such algorithms you're not interested at all at primitive to primitive edges (i.e. wireframe) but you want object to object ones, so you'll have to use a fairly large threshold anyways and you gain nothing from the linearity. Actually you loose something, because you have to be sure you either scale your threshold with your projection, or convert to view space everything, or yes, do the gradient thing that is expensive.<br /><br />So in the end? Is this "trick" useful? Most of the times no, and it has some pretty nasty problems too. But in some situations you can be handy indeed, and could let you express your algorithms in clip-space without having to transform from the z-buffer values to some other space.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-3508896777740256572010-08-17T10:40:55.279-07:002010-08-17T10:40:55.279-07:00If your z is linear, it can also royally screw up ...If your z is linear, it can also royally screw up coarse-grained z-cull and z compression due to z not being linear in screen space. Have a look at this: http://www.humus.name/index.php?page=News&ID=255MJPhttp://mynameismjp.wordpress.com/noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-89947305679445621822010-08-16T01:06:13.764-07:002010-08-16T01:06:13.764-07:00I wouldn't rely on COLOR outputs to be non per...I wouldn't rely on COLOR outputs to be non perspective correct.<br />DXSDK has this to say: "Color values input to the pixel shader are assumed to be perspective correct, but this is not guaranteed (for all hardware).".<br />On ATI HD5870 they are perspective correct.<br /><br />>and I can't think of a reason why you should need them anyways.<br />Well, NVidia found a use for them here:<br />http://developer.download.nvidia.com/SDK/10/direct3d/Source/SolidWireframe/Doc/SolidWireframe.pdf<br /><br />But I agree, it is hard to find yourself in a position where you need them.NULL_PTRhttps://www.blogger.com/profile/06754673521167225516noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-36895588978322484962010-08-15T19:38:50.465-07:002010-08-15T19:38:50.465-07:00Right! The first option is really a gimmick with n...Right! The first option is really a gimmick with no useful application, anyway you already have non perspectively correct intepolators if you need them (the COLOR ones) and I can't think of a reason why you should need them anyways. The second trick is actually useful. It records a linear Z from near to far. It makes eye-space position reconstruction from the depth buffer easier, it gives you a nicer distribution of your precision and so on. Someone told me that at least on some cards it screws with the near-clipping even if I could no reproduce the problem, handle with care.DEADC0DEhttps://www.blogger.com/profile/01477408942876127202noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-63975394277540403122010-08-15T04:25:33.186-07:002010-08-15T04:25:33.186-07:00A. IMHO NULL_PTR is right.
B. Outputs linear z val...A. IMHO NULL_PTR is right.<br />B. Outputs linear z values (w-buffer). Useful if You need same precision over all range (shadow mapping of smth).Krzysztof Narkowiczhttps://www.blogger.com/profile/01055035127272189489noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-19545406771033564432010-08-14T10:58:07.528-07:002010-08-14T10:58:07.528-07:00As I recall, "A" will effectively disabl...As I recall, "A" will effectively disable perspective-correct interpolation.NULL_PTRhttps://www.blogger.com/profile/06754673521167225516noreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-80999606066847856072010-08-14T02:42:56.058-07:002010-08-14T02:42:56.058-07:00If you do this in the VS and pass the result as PO...If you do this in the VS and pass the result as POSITION to the rasterizer I'd say you'll get some strange results. I think option B will just compress z further and maybe bring some stuff that would have been (far-) clipped otherwise back in. So maybe this doesn't look too wrong in the end.<br /><br />But I can't think of a scenario where this would be useful (in a VS -- in a PS it's another story). So? What's the solution?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6950833531562942289.post-60155900726108691302010-08-14T00:46:42.742-07:002010-08-14T00:46:42.742-07:00A: Makes XYZ a valid screen-space position, so it ...A: Makes XYZ a valid screen-space position, so it can be used as a float3 once again.<br />B: Haven't used this one myself, but looks like it would put Z into a 0-1 range, which is useful for writing out, for a depth pre-pass or deferred shading/lighting.Matt Enrighthttps://www.blogger.com/profile/11046322398655702512noreply@blogger.com