Re: [Algorithms] Continous worlds

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Got it, thanks.

But I prefer to think in terms of a mechanism that the value that ends =
up in the z-buffer is the ratio of zc/wc, when both zc and wc are =
pesrp-correct interpolated, and as if zc/wc was then done for every =
pixel.

This is the semantics that matters for me as a HW-user. This POV has =
also been very helpful in mentally managing projective texturing.

Speaking of which, this implies that for every projective texture unit =
an additional divider is needed since now the texcoords are not (U/W) / =
(1/W), but instead (U/W) / (P/W). And I thought tex2Dproj was free ...

-----Original Message-----
From:	gda...@li... on behalf of =
Jarkko Lempiainen
Sent:	Fri 7/7/2006 5:11 PM
To:	Game Development Algorithms
Cc:=09
Subject:	Re: [Algorithms] Continous worlds

Hmh, not quite. Just to wrap it up:

First clip space coordinates are outputted from vertex shader [X, Y, Z, =
W] (usually as the result of multiplying an object space position [x, y, =
z, 1] with object->world->view->clip -matrix), and possibly some other =
attributes (color, UV, etc). Then graphics HW takes those attributes =
from vertex output and computes: X'=3DX/W, Y'=3DY/W, Z'=3DZ/W, W'=3D1/W, =
and Color'=3DColor/W, UV'=3DUV/W, etc.

When all the 3 vertices for a triangle have been computed the HW builds =
dx/dy gradients for each attribute for their bilinear interpolation over =
the triangle in the screen space. When a pixel is rendered (at the =
interpolated position [X', Y']) the interpolated Z' is used for =
z-testing/writing. W''=3D1/W' for the pixel is computed and all those =
other interpolated attributes are multiplied with it: =
Color''=3DColor'*W'', UV''=3DUV'*W'' and used for perspective correct =
rendering.

Jarkko

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of
Christian Sch=FCler
Sent: 07 July 2006 14:11
To: Game Development Algorithms
Subject: Re: [Algorithms] Continous worlds

z from clip space (zc) gets interpolated linearly, and w=20
from clip space (wc) gets interpolated linearly. After that,
zc/wc is calculated per pixel.
When the proj matrix usually loads the z-coord from view=20
space (zv) into wc, by means of the (0 0 1 0) as last column,
this in effect is interpolating 1/zv per pixel.

-----Original Message-----
From: gda...@li... =
[mailto:gda...@li...] On Behalf Of =
Jarkko Lempiainen
Sent: Friday, July 07, 2006 2:58 PM
To: Game Development Algorithms
Subject: Re: [Algorithms] Continous worlds

Well, it's Z/W interpolation, not Z interpolation, which is quite a =
different thing. With Z interpolation (i.e. Z in clip space or any space =
before /perspective/ divide) you would get incorrectly interpolated =
values with linear interpolation in screen space. But yeah, you don't =
perform per-pixel division with (linearly) interpolated 1/W for linearly =
interpolated Z/W for getting the value for z-buffer, like you do for =
perspective correct tex coords, etc. (i.e. for linearly interpolated =
U/W, V/W, etc.)

So are you saying that introducing floating point depth buffer is =
cheaper transistor-wise than having perspective multiplication performed =
for Z? There should be also nothing preventing from having really fast =
z-cull/hi-z with that.

Jarkko

-----Original Message-----
From: gda...@li...
[mailto:gda...@li...]On Behalf Of Tom
Forsyth
Sent: 07 July 2006 10:13
To: 'Game Development Algorithms'
Subject: Re: [Algorithms] Continous worlds

> For sure z interpolation is perspective correct

No, it's not. It's linear in screen-space.

> because=20
> otherwise you would get weird intersection of two polygons,=20

No, you wouldn't, and you don't.

> and as we know the depth value stored in the z-buffer is Z/W=20
> (not 1/W), where Z & W are clip space values outputted from a=20
> vertex shader.

Sort-of. There's a viewport scale that happens first.

> Regarding speed (as if we were talking of=20
> software renderers here ;) once you do perspective correction=20
> for anything, you can just as well do it for everything,=20

No, Z interpolation happens before any perspective correction, otherwise =
you
wouldn't get really fast Z-rejection.

Nobody is talking about software renderers, we're talking about =
expending
transistor budget on something that could be making something else go =
faster
instead.

> since you have to perform the perspective division (the=20
> expensive part) per-pixel anyway and only extra per-pixel=20
> work for a perspective correct component is multiplication.

No, there are no reciprocals involved in Z interpolation or testing. =
That
comes after the Z-test has passed (unless you have shader-Z or wacky =
stuff
like that)

Did I mention every graphics coder should write a software rasteriser? I
think I did.

TomF.

> -----Original Message-----
> From: gda...@li...=20
> [mailto:gda...@li...] On=20
> Behalf Of Jarkko Lempiainen
> Sent: 07 July 2006 01:55
> To: Game Development Algorithms
> Subject: Re: [Algorithms] Continous worlds
>=20
>=20
> For sure z interpolation is perspective correct because=20
> otherwise you would get weird intersection of two polygons,=20
> and as we know the depth value stored in the z-buffer is Z/W=20
> (not 1/W), where Z & W are clip space values outputted from a=20
> vertex shader. Regarding speed (as if we were talking of=20
> software renderers here ;) once you do perspective correction=20
> for anything, you can just as well do it for everything,=20
> since you have to perform the perspective division (the=20
> expensive part) per-pixel anyway and only extra per-pixel=20
> work for a perspective correct component is multiplication.
>=20
> Jarkko
>=20
>=20
> -----Original Message-----
> From: gda...@li...
> [mailto:gda...@li...]On=20
> Behalf Of Tom
> Forsyth
> Sent: 06 July 2006 17:45
> To: 'Game Development Algorithms'
> Subject: Re: [Algorithms] Continous worlds
>=20
>=20
> Interpolation of Z is non-perspective-correct (for speed).=20
> That is why you
> interpolate something like 1/Z - when you non-perspectively=20
> interpolate
> that, the results are correct (correctly non-linear that is).=20
> So if you
> "linearise" it in the vertex shader, the mid-triangle values=20
> are incorrect
> and you can get incorrect intersections between large triangles (e.g.
> terrain) and small ones (e.g. things standing on the=20
> terrain). It looks very
> strange indeed.
>=20
> TomF.
>=20
> > -----Original Message-----
> > From: gda...@li...=20
> > [mailto:gda...@li...] On=20
> > Behalf Of Jarkko Lempiainen
> > Sent: 06 July 2006 04:17
> > To: Game Development Algorithms
> > Subject: Re: [Algorithms] Continous worlds
> >=20
> >=20
> > It doesn't really matter if the pixel size (width/height)=20
> > changes over the distance in world space though, because the=20
> > sampling is done in a precise point in the center of the=20
> > pixel, and the z for all triangles falling to that pixel are=20
> > sampled at that precise point.
> >=20
> > Anyway, let me reiterate, why not just linearize the z in=20
> > vertex shader and use fixed point z-buffer? Both of those are=20
> > supported in pretty much all hardware (ok, maybe not in those=20
> > mobile phones?) and it's also very cheap operation to do=20
> > (only one /vertex/ shader instruction or so).
> >=20
> > Jarkko
> >=20
> >=20
> > -----Original Message-----
> > From: gda...@li...
> > [mailto:gda...@li...]On=20
> > Behalf Of Jon
> > Watte
> > Sent: 06 July 2006 08:46
> > To: Game Development Algorithms
> > Subject: Re: [Algorithms] Continous worlds
> >=20
> >=20
> >=20
> >=20
> > Simon Fenney wrote:
> > > That maybe on *your* platform, but it is by no means universal.
> > >  =20
> > I'd say that it's a lot more universal than floating point Z,=20
> > dating all=20
> > the way back to good-old SGI and E&S hardware. I'm not aware of any=20
> > incumbent floating-point Z hardware, although I know of newer=20
> > hardware=20
> > that can do it (leading edge and all that). (Then there's software=20
> > renderers, of course.)
> >=20
> > > If you actually analyse it (and I design algorithms for HW
> > > implementation), you will find that a fixed point Z-buffer=20
> > has a nasty
> > > degradation in accuracy as you get towards the far clip distance.
> > >
> > >  =20
> > Yes, but it degrades just the same way in X and Y resolution. At=20
> > infinity, a screen pixel is infinitely wide and infinitely=20
> > tall, too, so=20
> > it makes sense that it's infinitely deep. For a given pixel,=20
> > the ratio=20
> > of X/Z and Y/Z stays the same with a fixed point Z buffer,=20
> > which I think=20
> > is a nice property. An object that renders right at size S at=20
> > distance=20
> > D, will render the same at size S*N at distance D*N (as long=20
> > as N keeps=20
> > you off the near plane :-)
> >=20
> > >
> > > With floating point Z, it makes a world of difference. If=20
> > you use the
> > > first (and ironically cheaper) mapping with a floating=20
> > point Z buffer,
> > > you get equal relative depth precision through your entire=20
> > range, which
> > > is, pretty much, ideal.
> > >
> > >  =20
> >=20
> > I agree that, with floating point Z, you can get better=20
> resolution in=20
> > one end than the other. However, then you get the bizarre=20
> > effect that an=20
> > object that renders correctly (no Z aliasing) at scale S*N=20
> > distance D*N,=20
> > will suffer Z aliasing at scale S at distance D (for some N > 1).
> >=20
> > So I guess what I argue with is the definition of "equal=20
> > relative depth=20
> > precision" -- relative to what? My assertion is that your=20
> > statement is=20
> > false when you measure relative to pixel world-space dimensions.
> >=20
> > Cheers,
> >=20
> >              / h+
> >=20
> >=20
> > Using Tomcat but need to do more? Need to support web=20
> > services, security?
> > Get stuff done quickly with pre-integrated technology to make=20
> > your job easier
> > Download IBM WebSphere Application Server v.1.0.1 based on=20
> > Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
> dat=3D121642
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188
>=20
> **************************************************************
> **************
> ******
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>=20
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
> **************************************************************
> **************
> ******
>=20
> Using Tomcat but need to do more? Need to support web=20
> services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on=20
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&
dat=3D121642
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188

Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188

Using Tomcat but need to do more? Need to support web services, =
security?
Get stuff done quickly with pre-integrated technology to make your job =
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache =
Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D=
121642
_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188