Hi Kees,
I have just checked the OSG's code for setting up the Matrix from ortho
parameters and it looks like it exactly matches OpenGL definition and
language. The code that does the work is:
void Matrix_implementation::makeOrtho(double left, double right,
double bottom, double top,
double zNear, double zFar)
{
// note transpose of Matrix_implementation wr.t OpenGL documentation,
since the OSG use post multiplication rather than pre.
double tx = -(right+left)/(right-left);
double ty = -(top+bottom)/(top-bottom);
double tz = -(zFar+zNear)/(zFar-zNear);
SET_ROW(0, 2.0/(right-left), 0.0, 0.0, 0.0 )
SET_ROW(1, 0.0, 2.0/(top-bottom), 0.0, 0.0 )
SET_ROW(2, 0.0, 0.0, -2.0/(zFar-zNear), 0.0
)
SET_ROW(3, tx, ty, tz, 1.0
)
}
Since the intention of the OSG's ortho convenience methods is to exactly
mirror that of OpenGL it does looks like to me that everything is correct
and it's just you expectations of how OpenGL/OSG works in this respect that
is off.
Robert.
On Wed, Apr 15, 2009 at 11:48 AM, Kees van Kooten <
[email protected]> wrote:
> Hi,
>
> I don't know whether this has been brought up before (I couldn't find any
> posts regarding this matter in the user forum), but when using the
> orthographic projection matrix's setProjectionMatrixAsOrtho(), the near/far
> plane z values supplied as arguments are not set as according to the OpenGL
> spec. Specifically, the third column of the projection matrix as applied by
> osg is:
>
> 0.0,
> 0.0,
> -2.0/(zFar-zNear),
> -(zFar+zNear)/(zFar-zNear)
>
> with zFar and zNear being the actual Z values of the far and near plane -
> as opposed to the distance to the far and near plane mentioned in the spec,
> which in practice turns out to be the negated z value of the far and near
> plane.
>
> If this has been a conscious choice, it seems highly confusing to me. For
> example, the vector (0,0,zNear,1) now transforms to
> (0,0,-(3zN+zF)/(zF-zN),1) in clip space, while the expected transformation
> would yield (0,0,-1,1). In practice, it gave me a few problems integrating
> an orthographic projection with depth to a partially rendered scene.
>
> Of course, the workaround is easy, as one should just supply the negated
> zNear and zFar to setProjectionMatrixAsOrtho(), and in a certain way this is
> all just a matter of interpretation of the function arguments. In my
> opinion, supplying the actual z values for the near and far plane is the
> more intuitive choice, as this is what the names of the function arguments
> imply.
>
> Best regards,
> Kees van Kooten
>
>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
