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

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Paolo Leoncini wrote:
> Please consider inserting the following patch to sg.cxx for working around
> the subject problem:

Paolo,

I would like to help you, but check out this thread:

http://sourceforge.net/mailarchive/forum.php?thread_id=6692659&forum_id=4479

field-of-view behaviour is tricky.
Sometimes, you want the behaviour you implemented:
fix one fov dimension, and set the other depending on the
window aspect ratio.
Sometimes, you want a fixed aspect, like steve described in the thread.
And in other cases you may want the current plib behaviour.
(Altough I agree that this messes up ratio's, and looks ugly).

Personally I dont use sgFustrum, so I'm hesitant to touch the
code (No plib examples use it either, but tuxkart, aqfh, fg, etc
may use it, so it would require a lot of testing).

Personally, I use a glut reshape func like the one below:

static void reshape(int w, int h)
{
   glViewport ( 0, 0, w, h ) ;

   aspectratio = w / (float) h;
   winw=w; winh=h;
   float fovy = 60.0 * M_PI / 180.0;
   float nearPlaneDistance = 0.4;
   float farPlaneDistance  = 2500.0;
   float y = tan(0.5 * fovy) * nearPlaneDistance;
   float x = aspectratio * y;
   context->setFrustum(-x,x,-y,y,nearPlaneDistance,farPlaneDistance);
}

Let's see what Steve's opinion is on this (if it's not aleady
clear from the mentioned thread).

    bram

> 
> In the sgFrustum::update function:
> 
>     if ( ortho )
>     {
>       right = SG_HALF * hfov ;
>       top   = SG_HALF * vfov ;
>     }
>     else
>     {
>       right = nnear * (SGfloat) tan ( hfov * SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;
> //    top   = nnear * (SGfloat) tan ( vfov * SG_DEGREES_TO_RADIANS / SG_TWO
> ) ;  <= current code
>       top = right * vfov/hfov;
> <= new, patch code
>     }
> 
> This way the aspect ratio of the window gets finally honored.
> 
> Thanks a lot -
> 
> Paolo Leoncini
> 
> 
> 
>>-----Messaggio originale-----
>>Da: pli...@li... 
>>[mailto:pli...@li...] Per conto di 
>>Paolo Leoncini
>>Inviato: mercoledì 26 ottobre 2005 12.04
>>A: pli...@li...
>>Oggetto: [Plib-devel] Possible problem in Frustum calculation
>>
>>
>>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 != SG_ZERO && vfov != SG_ZERO )
>>  {
>>    // code for the check of a too narrow fov snipped 
>>
>>    if ( ortho )
>>    {
>>      right = SG_HALF * hfov ;
>>      top   = SG_HALF * vfov ;
>>    }
>>    else
>>    {
>>      // perspective, with explicitly assigned FOVs
>>      right = nnear * (SGfloat) tan ( hfov * 
>>SG_DEGREES_TO_RADIANS / SG_TWO
>>) ;
>>      top   = nnear * (SGfloat) tan ( vfov * 
>>SG_DEGREES_TO_RADIANS / SG_TWO
>>) ;
>>    }
>>
>>    left  = -right ;
>>    bot   = -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=60, vfov=45, nnear=1 (the default, isn't?), i.e. aspect 
>>ratio=1.33333, we get:
>>
>>left -0.57735, right 0.57735, bot -0.414214, top 0.414214
>>  i.e.
>>width=1.1547, height=0.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° and vfov of 45°).
>>
>>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
> 
> 
> 
> -------------------------------------------------------
> 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
> 
> 
> 
> -------------------------------------------------------
> 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. For more info visit:
> http://ads.osdn.com/?ad_idv28&alloc_id845&op=click
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-devel