[Plib-devel] Possible problem in Frustum calculation

[Paolo L. <p.l...@ci...>]

Dear friends,

I suspect a problem in the frustum calculation given hfov and vfov as
implemented in sgFrustum::update() (sg.cxx). The focus is on the =
following
code:

  if ( hfov !=3D SG_ZERO && vfov !=3D SG_ZERO )
  {
    // code for the check of a too narrow fov snipped=20

    if ( ortho )
    {
      right =3D SG_HALF * hfov ;
      top   =3D SG_HALF * vfov ;
    }
    else
    {
      // perspective, with explicitly assigned FOVs
      right =3D nnear * (SGfloat) tan ( hfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;
      top   =3D nnear * (SGfloat) tan ( vfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;
    }

    left  =3D -right ;
    bot   =3D -top   ;
  }

This code gets executed when a call to ssgSetFOV( hfov, vfov ) occurs =
(and
when near and far do, as well).
In the case hfov=3D60, vfov=3D45, nnear=3D1 (the default, isn't?), i.e. =
aspect
ratio=3D1.33333, we get:

left -0.57735, right 0.57735, bot -0.414214, top 0.414214
  i.e.
width=3D1.1547, height=3D0.828428

thus leading to an aspect ratio of 1.39385, which is not really 1.33333 =
as
I'd expect.
The resulting image is, infact, somehow distorted, but it's not so =
evident
until you check against regular shapes such as a circle seen by a plane =
view
(the differece between aspects is 4.5%, small yet noticeable).

Yet having a suspect since time, I had a kind of confirmation when
implemented my own general off-axis frustum value calculation, which, in =
the
same case, produce l-r-b-t values leading to the right aspect ratio =
(screen
ranging in h [-2:2], v [-1.5:1.5], eye at (0,0,2*sqrt(3)) leading to a =
hfov
of 60=B0 and vfov of 45=B0).

According to
http://www.opengl.org/resources/faq/technical/transformations.htm FAQ =
#9.085
(How can I make a call to glFrustum() that matches my call to
gluPerspective), the way of calculating 'top' seems correct. Instead =
'right'
seems not explicitly calculated, yet directly following by 'top' =
(*aspect).
The problem in applying such approach for us is that our 'top' seems =
just
the "wrong" value.

I'm sure Steve has the clarifying answer.

Greetings -

Paolo



-------------------------------------------------------------------------=

Paolo Leoncini     phone:  +39 (0823) 623134
Visualization & Virtual Reality   fax:    +39 (0823) 623126
CIRA - Italian Center for Aerospace Researches mailto:p.l...@ci...
Via Maiorise - 81043 Capua (CE) Italy  http://www.cira.it