Thread: [Plib-devel] Possible problem in Frustum calculation
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Paolo L. <p.l...@ci...> - 2005-10-26 10:04:45
|
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
|
|
From: Paolo L. <p.l...@ci...> - 2005-11-21 15:44:54
|
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
|
|
From: Bram S. <br...@sa...> - 2005-11-26 13:30:05
|
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 |
|
From: steve <sjb...@ai...> - 2005-11-26 14:58:33
|
Bram Stolk wrote: > 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). Exactly. Whichever you do will displease roughly 50% of developers. We picked one at the outset - if we change it, we'll at best upset 50% of developers - and do nothing for the other 50% who have already worked around the issue. At worst, we'll upset 100% of developers because the library changed in ways they didn't expect. We shouldn't do this. |
|
From: Paolo L. <p.l...@ci...> - 2005-11-28 15:05:11
|
> -----Messaggio originale----- > Da: pli...@li...=20 > [mailto:pli...@li...] Per conto di steve > Inviato: sabato 26 novembre 2005 16.01 > A: pli...@li... > Oggetto: Re: R: [Plib-devel] Possible problem in Frustum=20 > calculation (new release?) >=20 >=20 > Bram Stolk wrote: > > Paolo Leoncini wrote: > >=20 > >> Please consider inserting the following patch to sg.cxx for working > >> around > >> the subject problem: > >=20 > >=20 > > Paolo, > >=20 > > I would like to help you, but check out this thread: > >=20 > >=20 > = http://sourceforge.net/mailarchive/forum.php?thread_id=3D6692659&forum_i > > d=3D4479 > >=20 > >=20 > > 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=20 > > aspect ratio. Sometimes, you want a fixed aspect, like=20 > steve described=20 > > in the thread. And in other cases you may want the current plib=20 > > behaviour. (Altough I agree that this messes up ratio's, and looks=20 > > ugly). >=20 > Exactly. >=20 > Whichever you do will displease roughly 50% of developers. =20 > We picked one at the outset - if we change it, we'll at best=20 > upset 50% of developers - and do nothing for the other 50%=20 > who have already worked around the issue. The idea is to fix things for casual users who don't want to complicate their life with frustum extents whilst getting their setFOV honored (and don't want to ugly multiply the hfov by 1.045 at 60=B0). IMHO whoever has worked around the problem did it with explicit frustum extent calculation as Bram's code shows, which has a different path = within sgFrustum::update yet. > At worst, we'll upset 100% of developers because the library changed > in ways they didn't expect. ... or many could finally see actual spheres! Seriously, I don't fully understand the referred post about the freedom = left by the current behavior, I'm just a little disappointed having had a = wrong aspect ration for five years, and for the last two years having worked around with an unexplainable constant multiplication, and would like = other users don't do the same. > We shouldn't do this. Ok, at leat what about warning setFOV users anywhere in the doc that = putting e.g. (60, 45) args for a 4:3 window doesn't produce an isotropic coord space? Paolo |
|
From: Bram S. <br...@sa...> - 2005-11-28 18:06:58
|
Paolo Leoncini wrote: > Ok, at leat what about warning setFOV users anywhere in the doc that putting > e.g. (60, 45) args for a 4:3 window doesn't produce an isotropic coord > space? Ok, I updated the sg documentation in CVS, so that it now contains a warning on aspect ratios. I think some script needs to be run, to update the website from CVS, but I dont know how to do this. So I can't say when the change will show up in the webpage. The warning I've put in, reads: "When using setFOV, the application programmer should be aware that aspect ratios are not enforced, thus these ratios can deviate from the window aspect ratio. If this happens, a sphere will look like an ellipse." Bram -- Bram Stolk, VR Engineer SARA, Amsterdam. tel +31 20 592 3000 "Windows is a 32-bit extension to a 16-bit graphical shell for an 8-bit operating system originally coded for a 4-bit microprocessor by a 2-bit company that can't stand 1 bit of competition." |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X