depth sorting error
category: code [glöplog]
I never interpolated 1/z for zbuffer, only plain z and it worked (at least for small scenes, object shows)
Yea, then it should be good enough, but for pixel-perfect intersections you want perspective-correct results.
who makes me write dicks instead of dick.
This might be a bit fuzzy cause I did not write this linearly and I discovered things in the process of writing :)
I think I should first just consider fixed point case.
If I may nitpick, and to the best of my understainding, the choice of using z or 1/z for interpolation and z comparison is independant from the choice of interpolating perspective correct or incorrect (well if you did 1/z obviously you're going perspective correct but if you're not you can still choose).
( In fact taking doing z->1/z on vertices before rasterization is a destructive operation in regard to the range of values, both in fixed point (unless you reserve enough bits, which is expensive but possible (though I have a doubt about something here(I should try, or think more) but well) ) and in floating point too probably (cause floating point dynamic range is x^y shape and 1/x is well, 1/x shape) (mastering what gets lost with dynamic range seems not really trivial to me) , and doing this _prevents_ pixel-perfect intersections (for another reason than the one mentioned above) at long range (z-fight), for example if you render a giant poster on a giant wall at 1km distance. (I'll call this quantization z-fight) )
Let me explain myself :)
Choice 1: not do 1/z per vertex before rasterization
subchoice 1a : walk screen pixels linearly and calc real z. ( a bit like tracing a ray through the pixel). If you don't screw up you get surface z in world units with no error. (well in fixed point. In floating point your space coordinates just plain suck from the beginning, or at least from the world coordinates). This is one div/pixel (I think).
This is the _best_ way to render. No z-fight, ever.
subchoice 1b : screenspace linear interpolation (what Optimus is talking about I guess). This is perspective incorrect (All this talking does not even involve textures btw, it's about z), which means that looking through a long corridor, a small poster on a big wall will be wrongly hidden by the wall (poster vertices are both on the wrong side of wall transformed 1/x-style shape). I'll call this perspective incorrectness z-fight.
In that case you still do not get quantization z-fight if your distant objects are facing the camera because objects ends (vertices) still are precise and exact even far away.
Choice 2: Do 1/z per vertex before rasterization
Well in that case you obviously are interpolating perspective correct but you get quantization z-fight for all angles at long range. The key cause is that multiple world unit z values are transformed into the same 1/z value, or worse, unfortunate rounding errors switched the z order at some places. At that point interpolation is not relevant.
that's the point where I think that floats for space coordinates _suck_ (Tom Forsyth agrees with me I think :) ). Even on today state of the art engines I think I saw Z fight. IMO this is just not the Right Way to do it, and as such, one day or another it will change for the better. Time will tell if I was right, but as float are so so much of a standards nowadays in gpus and engines, I might be wrong.
I think I should first just consider fixed point case.
If I may nitpick, and to the best of my understainding, the choice of using z or 1/z for interpolation and z comparison is independant from the choice of interpolating perspective correct or incorrect (well if you did 1/z obviously you're going perspective correct but if you're not you can still choose).
( In fact taking doing z->1/z on vertices before rasterization is a destructive operation in regard to the range of values, both in fixed point (unless you reserve enough bits, which is expensive but possible (though I have a doubt about something here(I should try, or think more) but well) ) and in floating point too probably (cause floating point dynamic range is x^y shape and 1/x is well, 1/x shape) (mastering what gets lost with dynamic range seems not really trivial to me) , and doing this _prevents_ pixel-perfect intersections (for another reason than the one mentioned above) at long range (z-fight), for example if you render a giant poster on a giant wall at 1km distance. (I'll call this quantization z-fight) )
Let me explain myself :)
Choice 1: not do 1/z per vertex before rasterization
subchoice 1a : walk screen pixels linearly and calc real z. ( a bit like tracing a ray through the pixel). If you don't screw up you get surface z in world units with no error. (well in fixed point. In floating point your space coordinates just plain suck from the beginning, or at least from the world coordinates). This is one div/pixel (I think).
This is the _best_ way to render. No z-fight, ever.
subchoice 1b : screenspace linear interpolation (what Optimus is talking about I guess). This is perspective incorrect (All this talking does not even involve textures btw, it's about z), which means that looking through a long corridor, a small poster on a big wall will be wrongly hidden by the wall (poster vertices are both on the wrong side of wall transformed 1/x-style shape). I'll call this perspective incorrectness z-fight.
In that case you still do not get quantization z-fight if your distant objects are facing the camera because objects ends (vertices) still are precise and exact even far away.
Choice 2: Do 1/z per vertex before rasterization
Well in that case you obviously are interpolating perspective correct but you get quantization z-fight for all angles at long range. The key cause is that multiple world unit z values are transformed into the same 1/z value, or worse, unfortunate rounding errors switched the z order at some places. At that point interpolation is not relevant.
that's the point where I think that floats for space coordinates _suck_ (Tom Forsyth agrees with me I think :) ). Even on today state of the art engines I think I saw Z fight. IMO this is just not the Right Way to do it, and as such, one day or another it will change for the better. Time will tell if I was right, but as float are so so much of a standards nowadays in gpus and engines, I might be wrong.
okay it's indeed quite messy what I wrote. Shouldnt have mixed this with floating point problems.
dont need perspective interpol.
took up some code from my incomplete rasterizer
feature z-buffering (sorting)
prolly not best code. not very optimized. anyway...a
took up some code from my incomplete rasterizer
feature z-buffering (sorting)
prolly not best code. not very optimized. anyway...a
Code:
float zstart = zfrom;
float dz = (zto - zfrom) / (right - left); //zdelta / xdelta
for (x=left; x<right; x++)
{
z = (zstart - someVal) * 256.0f; //precision
if (z >= zbuffer[x+y])
{
pixel[x+yaddr] = faceColor;
zbuffer[x+y] = z;
}
zstart += dz;
}
it's said that dick[x+yaddr] must be set to erection only and strictly only if female value at dick is positive. I do not love women that talk about dicks. here's a little one, here's a weird one, etc.
but has female value is so complex for the dick, you can with inverse of female value calculte mapping coordinates and diffuse color subdivising the raster line by a fixed step as done in modern cards that gives bullshiting results in some case :
http://www.youtube.com/watch?v=aP7DVLsxJHQ
the framerate is poor but it shows texture deformations of mapping holes of the fractal cube.
considering 1/z linear on the scanline uv at pixel = ((u/z)/(1*/z),(v/z)/(1*/z))
(u/z and v/z is also linear)
it's poor that modern cards do not interpolate linearly texel values.
(the division is made only each 16 pixels of the scanline for example)
in the example of rudi, dz can also be calculated once per triangle instead of each scanline.
but has female value is so complex for the dick, you can with inverse of female value calculte mapping coordinates and diffuse color subdivising the raster line by a fixed step as done in modern cards that gives bullshiting results in some case :
http://www.youtube.com/watch?v=aP7DVLsxJHQ
the framerate is poor but it shows texture deformations of mapping holes of the fractal cube.
considering 1/z linear on the scanline uv at pixel = ((u/z)/(1*/z),(v/z)/(1*/z))
(u/z and v/z is also linear)
it's poor that modern cards do not interpolate linearly texel values.
(the division is made only each 16 pixels of the scanline for example)
in the example of rudi, dz can also be calculated once per triangle instead of each scanline.
Bartoshe: Less bullshit. More respect ( and code ) please. KTHBYE
okish, but in France Penis is also called Bite...Let's say the common laught about computer is what to do with 32 bits.
it's an english conspiracy upon a poetic language.
it's an english conspiracy upon a poetic language.
Bartoshe: dicks and pussies goes hand in hand
anyway. z-buffering is just simple bresenham, calculating slope for the porn!
HeLLoWorld: as far as I know, all GPUs still use integer-based calculations for rasterization. The problem of z-fighting comes from other inaccuracies.
For example, if you have a wall, with a poster on it, as you say...
If the wall and the poster are on the same plane, then the problem is that the wall and posters have their vertices at different positions, and they are both approximations of points on the plane. As such there will be inaccuracies when setting up the gradients for interpolation.
That is a problem of finite precision in general, and is not really related to float vs integer.
Another classic problem is the so-called T-junction. It is very similar to this. If you have a polygon whose edge is perpendicular to another polygon, you will never get a 100% fit of the edge to the polygon, so some pixels may 'leak out' to the other side of the polygon.
In general the best solution is to subdivide your geometry so that they share the exact same vertices. A good rasterizer is designed to always perform the calculations in the same way (generally always render top-down and from left-to-right, regardless of the order in which the vertex info is passed). This ensures that the inaccuracies in edge/gradient calculations are always the same, so you always get the same results for each pixel.
For example, if you have a wall, with a poster on it, as you say...
If the wall and the poster are on the same plane, then the problem is that the wall and posters have their vertices at different positions, and they are both approximations of points on the plane. As such there will be inaccuracies when setting up the gradients for interpolation.
That is a problem of finite precision in general, and is not really related to float vs integer.
Another classic problem is the so-called T-junction. It is very similar to this. If you have a polygon whose edge is perpendicular to another polygon, you will never get a 100% fit of the edge to the polygon, so some pixels may 'leak out' to the other side of the polygon.
In general the best solution is to subdivide your geometry so that they share the exact same vertices. A good rasterizer is designed to always perform the calculations in the same way (generally always render top-down and from left-to-right, regardless of the order in which the vertex info is passed). This ensures that the inaccuracies in edge/gradient calculations are always the same, so you always get the same results for each pixel.
Quote:
If the wall and the poster are on the same plane, then the problem is that the wall and posters have their vertices at different positions, and they are both approximations of points on the plane.
Scali: In reality posters and walls lie not on the same plane. The poster is always in front. If the accuracy was in planck scale this wouldn't be a problem at all for renderers.
One way is to map the poster as u,v coordinates on the wall instead of an extra polygon.
Another way (not recommended) is to use painter's algorithm and discard the z-buffer on that particular case. It would eat cpu cycles and prolly fuck up the cache, but would achieve the goal somehow.
excuse moi. planck scale => planck length.
This thread :)
Well, no. What I wrote was supposing posters were in front of the walls, I wasn't discussing coplanar polygons.
And triangle coordinates are floats, and you got poor precision for distant objects.
And triangle coordinates are floats, and you got poor precision for distant objects.