# Keep rasterized pixel amount constant

I have a scene that is rendered from the point of view of the light using an orthographic projection matrix.

For an arbitrarily shaped and oriented object that doesn't change its shape or size in any way, the amount of pixels that get rasterized change with its position. I guess it's better to explain this with an images:

The depth of the quads (their y coordinates) are constant. Their x and z coordinates are slightly different. However, since it's an orthographic projection matrix, their "world space" floating point sizes are the same as seen from the camera. Just in one case, one additional lines of pixels is rasterized (I drew the two white lines with mspaint to illustrate their size difference).

This is highly undesirable for my application. Is there a way to keep the amount of rasterized pixels consistent? How would I go about implementing it using OpenGL?

• Those images are too small for me to see any difference. Jan 1, 2014 at 7:20
• I opened the image in a new tab and hit CTRL+ a bunch of times until it was large enough to see clearly. The difference is the right quad is 1px taller than the left. Jan 1, 2014 at 7:36
• Are the objects really arbitrarily shaped and oriented, or is there some consistency? Your example with a rectangle is a worst-case scenario and I can think of methods to reduce the problem in this specific case, but that will depend on what the other objects are. Jan 2, 2014 at 10:18
• Yeah, they are completely arbitrarily shaped. Jan 2, 2014 at 16:00

Snap the quad sizes to integer multiples of the light's-eye-view camera's pixel size.

What's happening is the bottom vertices in the right quad have just barely crossed the y-threshold of the bottom row of pixels, so that row gets included in the rasterized quad.

If the height is exactly an integer number of pixels, then this will only happen when the top vertices have slipped out of the top row at the same time, so the total rows covered remains the same.

As long as the quad is strictly between n and n+1 pixels tall, there will be some positions where it will rasterize to n rows and some positions where it will rasterize to n+1 rows.

• Can you go into a little bit more detail on how to do that? It seems to me that which coordinates (x/y/z) should be snapped, and to what multiples, depends on the orientation of the light source towards the geometry, and probably on the position of non-directional light sources. I.e. it seems to me that solid angles are involved. I guess for directional light sources, just snapping x/y would work. How about other types? Jan 1, 2014 at 20:37
• Also how do I get the texel size of the rendertarget in view space? Jan 1, 2014 at 20:55
• The details are going to be a bit application-dependent. ie. Are they always quads pointed straight at the light and view axis-aligned, or arbitrary geometry/arbitrary rotation? (In the latter case, it may be difficult to impossible to get 1:1 pixel congruency). Can you add a little more context about what kinds of objects/orientations you're rendering, and why the rasterized pixel count needs to be consistent? I'll try to expand my answer based on this. Jan 2, 2014 at 3:07
• Arbitrary objects. It needs to be consistent because a global illumination algorithm I'm implementing depends on the data that is rendered to that texture. If there's one line of pixels more, essentially more energy is added to indirect illumination. This causes flickering with moving objects. Jan 2, 2014 at 3:31
• Jan 2, 2014 at 16:01