R: [Plib-devel] Possible problem in Frustum calculation (new release?)

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

Please consider inserting the following patch to sg.cxx for working =
around
the subject problem:

In the sgFrustum::update function:

    if ( ortho )
    {
      right =3D SG_HALF * hfov ;
      top   =3D SG_HALF * vfov ;
    }
    else
    {
      right =3D nnear * (SGfloat) tan ( hfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;
//    top   =3D nnear * (SGfloat) tan ( vfov * SG_DEGREES_TO_RADIANS / =
SG_TWO
) ;  <=3D current code
      top =3D right * vfov/hfov;
<=3D new, patch code
    }

This way the aspect ratio of the window gets finally honored.

Thanks a lot -

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Paolo Leoncini
> Inviato: mercoled=EC 26 ottobre 2005 12.04
> A: pli...@li...
> Oggetto: [Plib-devel] Possible problem in Frustum calculation
>=20
>=20
> Dear friends,
>=20
> I suspect a problem in the frustum calculation given hfov and=20
> vfov as implemented in sgFrustum::update() (sg.cxx). The=20
> focus is on the following
> code:
>=20
>   if ( hfov !=3D SG_ZERO && vfov !=3D SG_ZERO )
>   {
>     // code for the check of a too narrow fov snipped=20
>=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 *=20
> SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
>       top   =3D nnear * (SGfloat) tan ( vfov *=20
> SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
>     }
>=20
>     left  =3D -right ;
>     bot   =3D -top   ;
>   }
>=20
> This code gets executed when a call to ssgSetFOV( hfov, vfov=20
> ) occurs (and when near and far do, as well). In the case=20
> hfov=3D60, vfov=3D45, nnear=3D1 (the default, isn't?), i.e. aspect=20
> ratio=3D1.33333, we get:
>=20
> left -0.57735, right 0.57735, bot -0.414214, top 0.414214
>   i.e.
> width=3D1.1547, height=3D0.828428
>=20
> thus leading to an aspect ratio of 1.39385, which is not=20
> really 1.33333 as I'd expect. The resulting image is, infact,=20
> somehow distorted, but it's not so evident until you check=20
> against regular shapes such as a circle seen by a plane view=20
> (the differece between aspects is 4.5%, small yet noticeable).
>=20
> Yet having a suspect since time, I had a kind of confirmation=20
> when implemented my own general off-axis frustum value=20
> calculation, which, in the same case, produce l-r-b-t values=20
> leading to the right aspect ratio (screen ranging in h=20
> [-2:2], v [-1.5:1.5], eye at (0,0,2*sqrt(3)) leading to a=20
> hfov of 60=B0 and vfov of 45=B0).
>=20
> According to=20
> 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



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005 =
Visit
http://www.jboss.com/services/certification for more information
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel