[osg-users] Question regarding the position of the camera in orthographic projection

366 views
Skip to first unread message

Ron Mayer

unread,
Jul 23, 2012, 9:14:18 AM7/23/12
to osg-...@lists.openscenegraph.org
Hi,

There is a mode in our application where the user does not control the camera. The camera is initially set to look at the z=0 plane (perpendicular to the plane) at a fixed height. We then get notifications from the application to move the camera in x and y only.

I was looking at our code we had for that, and I found out that we may have been doing a mistake. On the other hand, the view looks correct so I wanted to ask for more insight on this.

When the application comes in with a delta [x, y], we only move the frustum of the orthographic projection, without moving the camera.
I would imagine the right thing to do would be to move the camera in [x, y] without changing the frustum. But for some reason just moving the frustum works fine. I am not sure if this is valid or not.
[I do know that if we were in perspective we would have to move the camera, since the frustum is defined by the angle and ratio of the view.]

Just as an example, we start by setting the camera:

Code:
camera->setProjectionMatrixAsOrtho(-100.0, 100.0, -100.0, 100.0, 0.0, 320); // frustum of [200X200]
camera->setViewMatrixAsLookAt( osg::Vec3(0.0, 0.0, 320.0), osg::Vec3(0.0, 0.0, 0.0), osg::Vec3(0.0, 1.0, 0.0)); // [eye, center, up]


then at a later time, the application may say: "move the camera in x=50, y=25"

Instead of moving the camera location we just call:

Code:
camera->setProjectionMatrixAsOrtho(-50.0, 150.0, -75.0, 125.0, 0.0, 320);


Without moving the camera.


Cheers,
Ron

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=48990#48990





_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Paul Martz

unread,
Jul 23, 2012, 10:35:09 AM7/23/12
to osg-...@lists.openscenegraph.org
On 7/23/2012 7:14 AM, Ron Mayer wrote:
> When the application comes in with a delta [x, y], we only move the frustum of the orthographic projection, without moving the camera.
> I would imagine the right thing to do would be to move the camera in [x, y] without changing the frustum. But for some reason just moving the frustum works fine. I am not sure if this is valid or not.
> [I do know that if we were in perspective we would have to move the camera, since the frustum is defined by the angle and ratio of the view.]

I suspect that the concatenation of the modelview and projection matrices are
the same in either case, so the end result of the transformation is the same.

But it's likely that you really do want to effect the movement in the modelview
matrix rather than the projection matrix, and the reason for this is that OpenGL
performs certain operations in eye coordinates, and the movement would need to
be in the modelview matrix in order for these operations to be performed
correctly. The operations including lighting and clip planes.

All this is covered extensively in books like OpenGL Programming Guide and
(shameless plug) OpenGL Distilled.
-Paul

Tueller, Shayne R Civ USAF AFMC 519 SMXS/MXDEC

unread,
Jul 23, 2012, 1:00:27 PM7/23/12
to osg-...@lists.openscenegraph.org
Ron,

In your particular case, you have a camera positioned at (0,0,320)
looking at the origin (right down the z-axis) with "up" being the
y-axis. For the orthographic projection, the viewing region is a box per
se. The left and right sides align with the x-axis and the top and
bottom sides align with the y-axis. The projection of an object onto the
near plane has all lines of projection parallel to each other. When you
change the x and y boundaries, you're effectively changing the sides
(left, right, bottom, top) of the box relative to the eye position. This
is the same effect as changing the eye (x,y) relative to the box
assuming the vector from the eye position to the look-at point is
parallel to the sides of the box (ignoring the near-far sides).

For your example, if you change the box to (-50, 150, -75, 125), this is
the same as setting the view point to (-50,-25,320) with a look-at of
(-50,-25,0) with the same "up" vector (0,1,0) (e.g.
setViewMatrixAsLookAt()). If you draw the geometry (the viewing "box"
and the eye) on paper in 2D and do the translation, you can see why it
does what it does.

In general, you do want to use the ModelView matrix to set the position
and orientation of the camera...

-Shayne

Paul Martz

unread,
Jul 23, 2012, 1:32:14 PM7/23/12
to OpenSceneGraph Users
The osgthirdpersonview example might be helpful here. It supports visualizing
the perspective view frustum. If it doesn't also have support for visualizing an
ortho frustum, it should be pretty easy to add that support.
-Paul

Ron Mayer

unread,
Jul 24, 2012, 8:22:09 AM7/24/12
to osg-...@lists.openscenegraph.org

Paul Martz wrote:
>
>
> But it's likely that you really do want to effect the movement in the modelview
> matrix rather than the projection matrix, and the reason for this is that OpenGL
> performs certain operations in eye coordinates, and the movement would need to
> be in the modelview matrix in order for these operations to be performed
> correctly. The operations including lighting and clip planes.
>
> All this is covered extensively in books like OpenGL Programming Guide and
> (shameless plug) OpenGL Distilled.
> -Paul
>
>


Thanks Paul, I will go and change the code to move the camera. Can you give a concrete example for the usage of the camera's eye coordinates inside openGL?

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49017#49017

Ron Mayer

unread,
Jul 24, 2012, 8:23:39 AM7/24/12
to osg-...@lists.openscenegraph.org

S2LR wrote:
> This
> is the same effect as changing the eye (x,y) relative to the box
> assuming the vector from the eye position to the look-at point is
> parallel to the sides of the box (ignoring the near-far sides).
>
>


Thanks for the explanation.

------------------
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=49018#49018

Paul Martz

unread,
Jul 24, 2012, 1:35:49 PM7/24/12
to osg-...@lists.openscenegraph.org
On 7/24/2012 6:22 AM, Ron Mayer wrote:
> Thanks Paul, I will go and change the code to move the camera. Can you give a concrete example for the usage of the camera's eye coordinates inside openGL?

The clearest example would be the computation of specular reflection. Suppose
you have a scene consisting of a light source and a shiny table, and you want to
position your eye so that the light produces a nice bright specular reflection
off the table top. (Picture a 'V' shape, with the light at upper left, the table
surface at the bottom of the 'V', and the eye at upper right. In this scene, the
eye would "see" the light reflected off the table.)

If you use the modelview matrix to contain the eye transformation, then the eye
coordinate eye position will be at the origin, and the table and light will be
in -z space. In this case, the specular reflection will be computed correctly,
and the lighting math will determine that the eye is within the cone of the
reflected light vector.

However, matrices are just matrices, so you could get the same net *clip*
coordinate transformation if you (inadvertently) placed the eye transformation
in the projection matrix. You'd still see the table rendered in the same
location as in the previous example, but the specular reflection would almost
certainly be missing, because the math used to compute the specular reflection
would use the wrong eye location. This happens because the light computation is
done in eye coordinates == after multiplying by the modelview matrix, but
*before* multiplying by the projection matrix == so there's no way for the
OpenGL lighting code to know where you've placed the eye.

Tying this into OSG, the Camera has a view matrix, and the scene graph can have
other Transform nodes such as MatrixTransform and PositionAttitudeTransform. It
is the accumulated hierarchical concatenation of these matrices that end up
being sent to OpenGL as the modelview matrix.

As I mentioned before, the OpenGL books go into detail on this.

The OpenGL technical FAQ has some info here:
http://www.opengl.org/archives/resources/faq/technical/transformations.htm#tran0011
It's the old FAQ at this point, but it describes the OpenGL 1.x / 2.x FFP, and
that hasn't changed and it's what OSG uses by default.
-Paul
Reply all
Reply to author
Forward
0 new messages