0
\$\begingroup\$

I am trying to implement following: enter image description here

What are the l r b t units? I understood that r-l= is just screen_width, however is not clear: is it for ex: l=-400 and r=+400 for a screen width 800 pixels? I believe so, because that's what we see on the picture below (origin is in the middle):

enter image description here

However, plugging l=-400 and r=+400 into ortho matrix provided above, we have zero: r+l = 0. Same obivously goes for t+b when t=+400 and b=-400.

Am I taking wrong numbers, or is it just zero and that's it?

\$\endgroup\$

1 Answer 1

1
\$\begingroup\$

These values are measurements in world space - the coordinate space you're using to position objects in your scene. This is the same unit used in view space, the frame of reference of the camera, since the view matrix is just a rotation and translation, and does not apply any scaling.

So let's say you've set up your game where 1 world unit = 1 meter, and you have a level that's 5m tall, and you want to fit the whole level vertically into however many pixels there are along the height of your screen/window. Then t = 2.5 and b = -2.5 so that t - b = 5, covering the full height you want, and t + b = 0 - no vertical shift, so the part of the scene directly in front of the camera stays in the center of the screen.

Once you've transformed your objects into view space, an object at the very top of the camera's view will be at y = 2.5 - multiplying it by this orthographic projection matrix gets you y' = 1. Similarly, an object at the very bottom will be at y = -2.5, and after multiplying by the projection matrix you get y' = -1. This transformed position is in normalized device coordinates: a coordinate system that ranges from -1 to +1 from left to right/bottom to top across the window's bounds, and from the near plane to the far plane depth. The standard -1/+1 bounds make it easy to do clipping math in the next stage of the graphics pipeline.

Because pixel values don't occur anywhere in this formula, you can run the same projection code for a window or viewport of any size, and the rasterization will automatically scale the view of the scene to fit the output. You do need to match the aspect ratio of your (r-l)/(t-b) to the aspect ratio of the destination to avoid squashing though. And this automatic scaling works fine for mesh geometry, but does not do anything clever for textures, so if you want "pixel perfect" sprites and UI images, you need to take extra steps to adjust their positions/sizes/contents depending on the output resolution.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .