Nobody,

I don't know what these "virtual pixels" you describe are.

Nope, I'm not going to try to explain that to you for ... the fourth or
fifth time. Just accept that you never will.

While you can define your own coordinate system for
the purpose of exposition,

And you will never understand that that coordinate system you keep using is
as abitrary as a roll of the dice.

A pixel doesn't have a position. How many times do I have to
keep saying this?

Until you come up with a position that *doesn't* flip-flop from one
explanation to another. Like saying that a pixel is a rectangle, where the top-left one ranges from 0,0 to 1,1. That certainly looks like a
positional indication to me ....

A pixel is an area, a subset of R^2 containing an infinite number of
points, each of which has a distinct position.

.. and I don't know about that screen you are looking at, but on mine (the physical) pixels have a fixed position/location.

And those "points" you are talking about ? Guess what: Thats what I ment
with "virtual pixels". In your system the pixels you are talking about do
not exist *at all*, and much less are a rectangle or have dimensions.

What you do not seem to grasp is that those pixels *you* are talking about
are, in fact, representations / shadows of the physical pixels, the ones
those "points" of yours need to be translated to. Thru a set of
translations and scalings no less. Which causes *your* "pixels" to have different sizes depending on a combination of factors.


...And I'm going to stop here, not even bothering to read the rest. I
don't think you want to understand what I asked, nor what I said later on.

Lets face it: I've mentioned the stupidity of placing (your) points on the border of two (of my) pixels a few times now (when placing them using
integer coordinates), but you've fully ignored it. Why ? Most likely
because its not in line with your "its GOOD!" conviction (either that, or
you have a remarkable selective reading).

You've also tried to let me/us believe that the most basic of Ortho setups
is actually "a constructed case", and no mentioning of mine about it to the opposite could evoke a reaction.

Either you're not half as smart as you think you are, or you are activily trying to lie to me.

So, go pester somebody else.

Goodbye.
Rudy Wieser


-- Origional message:
Nobody <nobody@nowhere.invalid> schreef in berichtnieuws pan.2015.09.17.10.36.43.152000@nowhere.invalid...

On Wed, 16 Sep 2015 15:56:38 +0200, R.Wieser wrote:

As I said before: a pixel isn't a point, it's a rectangle. A pixel
doesn't have a single, specific location.

....

The centre of the bottom-left pixel is at (0.5,0.5) in window
coordinates.

Thank you for that explanation. It also indicates a problem when the

term

"pixel" is used, as lthe ast time you metioned "rectangular pixels" I assumed, from the context, that you ment OpenGLs virtual ones, instead

of

the screens physical ones.

I don't know what these "virtual pixels" you describe are.

But a question: If I would use the exact same explanation, but define

the

origin of the screen as the center* of the top-left pixel, with it

ranging

from -1/2 pixel to +1/2 pixel, would that make the explanation invalid ?
If so, why ? If not ....

OpenGL defines a number of coordinate systems. Coordinates passed to
OpenGL are interpreted in the coordinate systems which it defines. While
you can define your own coordinate system for the purpose of exposition,
I really don't seen any point; it would just create confusion, as you'd continually need to clarify whether you were talking about your coordinate system or OpenGL's.

* The position of a lamp (or most any single-point lightsource) is
normally defined as its center, not somewhere on its outside. Why would

it

be different for a pixel ?

A pixel doesn't have a position. How many times do I have to keep saying this?

A pixel is an area, a subset of R^2 containing an infinite number of
points, each of which has a distinct position.

is that in the case where two polygons share a common edge, any pixel
along that edge will belong to exactly one of the two polygons.

I think you've here mentioned the reason why a quad drawn ontop of a lineloop (ofcourse using the same coordinates for both) does not fully overlap the lineloop: because its *forced* to stop one pixel short of

its

left/bottom end-coordinates, so it will not overlap an eventual next

one.

A good choice, but not mentioned anywhere and as such not expected. :-\

The omission of the endpoint is a separate issue, but has a similar origin (certain operations not modifying a pixel multiple times).

The fact that a rasterised line between two points is neither wholly
inside nor wholly outside a rasterised polygon containing that edge is related to the fact that the same edge can be shared by two different polygons (one on each side).

Which polygon should the line be inside or outside? The answer can't be
"the one I'm actually drawing" because drawing operations are independent; the rasterisation of a line can't change based upon whether or not you
also draw a polygon using the same vertices.

2. The reason for using the pixel's centre is that it is unbiased.
Using any other location would result in rasterised polygons exhibiting
a net shift whose magnitude depends upon the raster resolution.

Ehrmmm ... Although I think I understand what problem you are indicating here, wasn't the problem not that OpenGL is *not* using the pixels
center ?

No. Your problem is that rasterisation (for both lines and polygons) is
based upon pixel centers, whose window coordinates are always an integer-plus-a-half, not integers.

for which the line intersects a diamond inscribed within the pixel

Yeah, I found that diamond too. Though I have to say that I do not
quite see how it, in a basic Ortho projection, would affect a
single-pixel width line drawn from the center of a physical pixel to the center of another physical pixel

It doesn't. If you draw between pixel centres, you don't have a problem.
If you draw between pixel corners (i.e. use integer window coordinates),
the problem occurs.

because unless x is a power of two, x*(1/x) typically won't be exactly
1.0 when using floating-point arithmetic.

And thats *exactly* why an OpenGL pixel should *not* be placed, when
using a basic ortho projection and integer coordinates, on the border of two physical ones.

Pixels aren't "placed" anywhere; they're areas, not points (I'm starting
to sound like a stuck gramophone here).

unless you've managed to construct a case where you're consistently
hitting the discontinuity in the rounding function.

Yeah, funny that: I'm using the *most basic* of setups (ortho projection matching the viewport size, integer coordinates for any used vertex),

Which is exactly what you SHOULDN'T be doing. Integer coordinates
correspond to the edges and corners of pixels, i.e. the points exactly between pixels. Which are the worst points to use if you're trying to draw lines such that specific pixels are affected.

If you want to render filled polygons, then integer coordinates are ideal (i.e. they ensure that the edges don't fall on pixel centres, resulting in the inside-ness test being a tie which is decided by rounding error).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)