<div dir="auto"><div>Z is 0 at the near plane and 1 at the far plane, but the planes can have an arbitrary distance from the viewer, therefore Z Is irrelevant.</div><div dir="auto"><br></div><div dir="auto">W is the real distance from the viewer. The greater W is, the smaller (farther away) the object is, because W is the divisor (which makes objects smaller as it increases).</div><div dir="auto"><br></div><div dir="auto">The W=0 plane intersects the viewer. It is exactly in the middle of the "eye ball".</div><div dir="auto"><br></div><div dir="auto">W < 0 means behind the viewer.</div><div dir="auto"><br></div><div dir="auto">Marek<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri., Aug. 2, 2019, 21:22 Ilia Mirkin, <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Compare<br> <br> generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-smooth-other-smooth-none.shader_test<br> generated_tests/spec/glsl-1.30/execution/interpolation/interpolation-noperspective-other-smooth-none.shader_test<br> <br> as you can see, the first one is perspective-interpolated and has a<br> lot more red and less blue (due to the depth). The second one is even,<br> since depth is ignored. gl_Position.w is the same in both cases, but<br> the "other" varying gets interpolated differently.<br> <br> I think you're right that 1/w plays into it -- you're supposed to<br> divide the interpolated result by w in the frag shader. But I think<br> the ij coefficients themselves are different? Not sure, it just seems<br> like z has to be taken into account *somewhere* otherwise the whole<br> thing can't possibly work.<br> <br> -ilia<br> <br> On Fri, Aug 2, 2019 at 8:11 PM Marek Olšák <<a href="mailto:maraeo@gmail.com" target="_blank" rel="noreferrer">maraeo@gmail.com</a>> wrote:<br> ><br> > IIRC, perspective interpolation is driven by W, not Z. Interpolating W and then computing barycentric coordinates using 1/W is what causes the perspective distortion.<br> ><br> > Marek<br> ><br> > On Fri, Aug 2, 2019 at 4:59 PM Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu" target="_blank" rel="noreferrer">imirkin@alum.mit.edu</a>> wrote:<br> >><br> >> On Fri, Aug 2, 2019 at 3:46 PM Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank" rel="noreferrer">gert.wollny@collabora.com</a>> wrote:<br> >> ><br> >> > Am Freitag, den 02.08.2019, 15:09 -0400 schrieb Ilia Mirkin:<br> >> > > On Fri, Aug 2, 2019 at 1:28 PM Gert Wollny <<a href="mailto:gert.wollny@collabora.com" target="_blank" rel="noreferrer">gert.wollny@collabora.com</a><br> >> > > > wrote:<br> >> > > > Am Donnerstag, den 01.08.2019, 07:22 -0400 schrieb Ilia Mirkin:<br> >> > > > > Hey Gert,<br> >> > > > ><br> >> > > > > I'm looking at<br> >> > > > > <a href="https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f" rel="noreferrer noreferrer" target="_blank">https://cgit.freedesktop.org/mesa/mesa/commit/?id=b048d8bf8f056759d1845a799d4ba2ac84bce30f</a><br> >> > > > > , which attempts to implement depth clamping (rather than<br> >> > > > > clipping)<br> >> > > > > with shader tricks.<br> >> > > > ><br> >> > > > > You're forcing the final vertex stage's position's depth to 0,<br> >> > > > > and<br> >> > > > > then making up for it in the frag shader with an extra varying.<br> >> > > > > However won't this screw up the barycentric coordinates for<br> >> > > > > perspective interpolation? i.e. won't you effectively always just<br> >> > > > > get<br> >> > > > > noperspective interp everywhere as a result?<br> >> > > > That is probably true, I was following @kumas lead [1], in fact<br> >> > > > he implemented the initial version of this code, and I only fixed<br> >> > > > it up<br> >> > > > for ARB_clip_control and GS and TES shaders.<br> >> > > ><br> >> > > > One fix I could think is maybe clamp the z value to the clip range<br> >> > > > [-1,<br> >> > > > 1] or [0,1] depending on the clip control z accuracy, so that the<br> >> > > > error<br> >> > > > only happens only for the clamped areas where the result is<br> >> > > > distorted<br> >> > > > anyway, what do you think?<br> >> > ><br> >> > > Unfortunately I can't think of a way to generically emulate it<br> >> > > without implementing clipping in a geometry shader.<br> >> > Yeah, when I first looked into this, this is also what I thought of.<br> >> ><br> >> ><br> >> ><br> >> > > Basically if depth is clipped, the triangle gets split into 2 -- one<br> >> > > half which is shown, and one half which isn't. When depth is clamped,<br> >> > > the half which isn't shown appears as a different polygon with the<br> >> > > clamped depth for all of its vertices instead. An interesting<br> >> > > question is whether it should be using the original z coords for its<br> >> > > barycentric coords or not -- I have no idea, and the spec doesn't<br> >> > > seem to explain it in a manner which is accessible to me.<br> >> > I think that the spec suggest to use the original z coords and the<br> >> > clamping only happens when the depth test is executed:<br> >> ><br> >> > RESOLUTION: ... Eliminating far and near plane clipping and<br> >> > clamping *interpolated* depth values to the depth range is much<br> >> > simpler to specify.<br> >> ><br> >> > > If it should be the original z coords, then perhaps you can just<br> >> > > disable clipping entirely in that case,<br> >> > My guess is that hardware that disables clipping completely also<br> >> > supports clamping the depth values. Our use case (virgl on top of e<br> >><br> >> Yeah, that's how NVIDIA hardware works. There's a DEPTH_CLAMP_NEAR/FAR<br> >> value which you set to a value between 0 and 1, based on the viewport<br> >> transform, and that just clamps it prior to being supplied to the frag<br> >> shader. (And separately, you disable clipping near/far planes.) Adreno<br> >> hw works similarly.<br> >><br> >> > GLES host that doesn't support EXT_depth_clamp) repesents the opposite:<br> >> > a hardware that doesn't support disabling clipping because OpenGL (ES)<br> >> > doesn't allow this and also not doesn't support depth clamping.<br> >> ><br> >> > I still have to think about whether the interpolation really goes<br> >> > wrong. I think I need to write another piglit to get an idea.<br> >><br> >> Should be easy - take one of the interpolation piglit tests, and<br> >> enable depth clamp without doing anything else.<br> >><br> >> Cheers,<br> >><br> >> -ilia<br> >> _______________________________________________<br> >> mesa-dev mailing list<br> >> <a href="mailto:mesa-dev@lists.freedesktop.org" target="_blank" rel="noreferrer">mesa-dev@lists.freedesktop.org</a><br> >> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br> </blockquote></div></div></div>