Thread: [Plib-users] culling problems w/ off-axis projection

Brought to you by: sjbaker

plib-users

[Plib-users] culling problems w/ off-axis projection

From: <p.l...@ci...> - 2010-04-06 10:19:04

Dear all,

I'm doing off-axis projection (the most general form of projection) by
translating the four corners of the screen into a projection matrix, for which
I added a new method to the sgFrustum class and to the Context too. The only
difference with giving the six frustum extrema values is that no calculation
occurs. Culling seems to rely only on the projection matrix values, so,
apparently, no difference w/ the on-axis standard case.

As far as the projection is not far from the on-axis case the culling gives no
problem. Instead when screen position definition results in a large rotation in
the projection matrix objects suddenly disappear and reappear by apparently no
rule.

Are culling calculations based on a particular form of the projection matrix?
should culling planes be extracted in a different way to support the more
general case?

Thanks a lot,

Paolo Leoncini

[Plib-users] R: culling problems w/ off-axis projection

From: Paolo L. <p.l...@ci...> - 2010-04-12 08:21:37

Dear friends,

I think to have solved the problem.

> -----Messaggio originale-----
> Da: p.l...@ci... [mailto:p.l...@ci...] 
> Inviato: martedì 6 aprile 2010 11.19
> A: pli...@li...
> Oggetto: [Plib-users] culling problems w/ off-axis projection
> 
> Dear all,
> 
> I'm doing off-axis projection (the most general form of 
> projection) by translating the four corners of the screen 
> into a projection matrix, for which I added a new method to 
> the sgFrustum class and to the Context too. The only 
> difference with giving the six frustum extrema values is that 
> no calculation occurs. Culling seems to rely only on the 
> projection matrix values, so, apparently, no difference w/ 
> the on-axis standard case.
> 
> As far as the projection is not far from the on-axis case the 
> culling gives no problem. Instead when screen position 
> definition results in a large rotation in the projection 
> matrix objects suddenly disappear and reappear by apparently no rule.
> 
> Are culling calculations based on a particular form of the 
> projection matrix?
> should culling planes be extracted in a different way to 
> support the more general case?

In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for the non-ortho
case which is presently done this way:

    sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[ SG_LEFT_PLANE
][2] * center[2] ;
    sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[ SG_RIGHT_PLANE
][2] * center[2] ;
    sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ SG_BOT_PLANE
][2] * center[2] ;
    sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ SG_TOP_PLANE
][2] * center[2] ;

should be substituted by the following general form:

    sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ], center ) + plane[
SG_LEFT_PLANE  ][3] ;
    sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ], center ) + plane[
SG_RIGHT_PLANE ][3] ;
    sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ], center ) + plane[
SG_BOT_PLANE   ][3] ;
    sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ], center ) + plane[
SG_TOP_PLANE   ][3] ;

The hint were just below there (see comment "Note: in the general case, we
would have to do:").
I propose to patch it since this general form also manages the default
on-axis case, but Steve should definitely give the go-ahead.
Should someone be concerned about performances I could supply a bit larger
patch for introducing the ability to supply the Context a general
perspective matrix, so to have the general case only calculated in this
eventuality.

> Thanks a lot,
> 
> Paolo Leoncini

Thanks in advance to a good will updater (John, it's you as usual?).

Paolo Leoncini


> --------------------------------------------------------------
> ----------------
> Download Intel&#174; Parallel Studio Eval Try the new 
> software tools for yourself. Speed compiling, find bugs 
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

Re: [Plib-users] R: culling problems w/ off-axis projection

From: Fay, J. F Dr C. U. A. 46 S. <joh...@eg...> - 2010-04-17 16:33:13

Paolo,

	Congratulations and very good on having solved the problem.  Is there a code change that you want me to put into Subversion?

Dr. John F. Fay
Technical Fellow
Jacobs Technology TEAS Group
850-883-1294


-----Original Message-----
From: Paolo Leoncini [mailto:p.l...@ci...] 
Sent: Monday, April 12, 2010 3:21 AM
To: 'PLIB Users'
Subject: [Plib-users] R: culling problems w/ off-axis projection

Dear friends,

I think to have solved the problem.

> -----Messaggio originale-----
> Da: p.l...@ci... [mailto:p.l...@ci...] 
> Inviato: martedì 6 aprile 2010 11.19
> A: pli...@li...
> Oggetto: [Plib-users] culling problems w/ off-axis projection
> 
> Dear all,
> 
> I'm doing off-axis projection (the most general form of 
> projection) by translating the four corners of the screen 
> into a projection matrix, for which I added a new method to 
> the sgFrustum class and to the Context too. The only 
> difference with giving the six frustum extrema values is that 
> no calculation occurs. Culling seems to rely only on the 
> projection matrix values, so, apparently, no difference w/ 
> the on-axis standard case.
> 
> As far as the projection is not far from the on-axis case the 
> culling gives no problem. Instead when screen position 
> definition results in a large rotation in the projection 
> matrix objects suddenly disappear and reappear by apparently no rule.
> 
> Are culling calculations based on a particular form of the 
> projection matrix?
> should culling planes be extracted in a different way to 
> support the more general case?

In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for the non-ortho
case which is presently done this way:

    sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[ SG_LEFT_PLANE
][2] * center[2] ;
    sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[ SG_RIGHT_PLANE
][2] * center[2] ;
    sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ SG_BOT_PLANE
][2] * center[2] ;
    sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ SG_TOP_PLANE
][2] * center[2] ;

should be substituted by the following general form:

    sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ], center ) + plane[
SG_LEFT_PLANE  ][3] ;
    sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ], center ) + plane[
SG_RIGHT_PLANE ][3] ;
    sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ], center ) + plane[
SG_BOT_PLANE   ][3] ;
    sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ], center ) + plane[
SG_TOP_PLANE   ][3] ;

The hint were just below there (see comment "Note: in the general case, we
would have to do:").
I propose to patch it since this general form also manages the default
on-axis case, but Steve should definitely give the go-ahead.
Should someone be concerned about performances I could supply a bit larger
patch for introducing the ability to supply the Context a general
perspective matrix, so to have the general case only calculated in this
eventuality.

> Thanks a lot,
> 
> Paolo Leoncini

Thanks in advance to a good will updater (John, it's you as usual?).

Paolo Leoncini


> --------------------------------------------------------------
> ----------------
> Download Intel&#174; Parallel Studio Eval Try the new 
> software tools for yourself. Speed compiling, find bugs 
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 


------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] R: R: R: culling problems w/ off-axis projection

From: Paolo L. <p.l...@ci...> - 2010-05-31 08:22:59

John, 

> -----Messaggio originale-----
> Da: John F. Fay [mailto:joh...@cy...] 
> Inviato: sabato 29 maggio 2010 4.15
> A: PLIB Users
> Oggetto: Re: [Plib-users] R: R: culling problems w/ off-axis 
> projection
> 
> Paolo,
> Message-Id: <201...@yo...>
> 
>          Please pardon my delay in answering; May is never a 
> good month for me.  Did this patch get put in already,

No.
 
> or did the patch file switch the "from" and "to" versions?

Yes.

>                  - John

Thanks for taking care of it.

Greetings,

Paolo


> At 09:40 AM 4/21/2010, you wrote:
> >John,
> >
> >Please find attached the patch.
> >
> >This patch also include a fix to the function 
> sgQuatToAxisAngle which 
> >manages cases of Quat's W outside the range [-1:1] (acos undefined). 
> >For this I used _isnan and _finite functions in MS Visual C++, whose 
> >availability I ask all of you to verify on other 
> Plib-supported platforms.
> >Otherwise just ignore this second part of the patch.
> >
> >Thanks a lot,
> >
> >Paolo Leoncini
> >
> >
> > > -----Messaggio originale-----
> > > Da: Fay, John F Dr CTR USAF AFMC 46 SK 
> > > [mailto:joh...@eg...]
> > > Inviato: sabato 17 aprile 2010 18.33
> > > A: PLIB Users
> > > Oggetto: Re: [Plib-users] R: culling problems w/ off-axis 
> projection
> > >
> > > Paolo,
> > >
> > >       Congratulations and very good on having solved the 
> problem.  
> > > Is there a code change that you want me to put into Subversion?
> > >
> > > Dr. John F. Fay
> > > Technical Fellow
> > > Jacobs Technology TEAS Group
> > > 850-883-1294
> > >
> > >
> > > -----Original Message-----
> > > From: Paolo Leoncini [mailto:p.l...@ci...]
> > > Sent: Monday, April 12, 2010 3:21 AM
> > > To: 'PLIB Users'
> > > Subject: [Plib-users] R: culling problems w/ off-axis projection
> > >
> > > Dear friends,
> > >
> > > I think to have solved the problem.
> > >
> > > > -----Messaggio originale-----
> > > > Da: p.l...@ci... [mailto:p.l...@ci...]
> > > > Inviato: martedì 6 aprile 2010 11.19
> > > > A: pli...@li...
> > > > Oggetto: [Plib-users] culling problems w/ off-axis projection
> > > >
> > > > Dear all,
> > > >
> > > > I'm doing off-axis projection (the most general form of
> > > > projection) by translating the four corners of the 
> screen into a 
> > > > projection matrix, for which I added a new method to 
> the sgFrustum 
> > > > class and to the Context too. The only difference with
> > > giving the six
> > > > frustum extrema values is that no calculation occurs.
> > > Culling seems to
> > > > rely only on the projection matrix values, so, apparently, no 
> > > > difference w/ the on-axis standard case.
> > > >
> > > > As far as the projection is not far from the on-axis case
> > > the culling
> > > > gives no problem. Instead when screen position definition
> > > results in a
> > > > large rotation in the projection matrix objects suddenly
> > > disappear and
> > > > reappear by apparently no rule.
> > > >
> > > > Are culling calculations based on a particular form of the
> > > projection
> > > > matrix?
> > > > should culling planes be extracted in a different way to
> > > support the
> > > > more general case?
> > >
> > > In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for the 
> > > non-ortho case which is presently done this way:
> > >
> > >     sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[ 
> > > SG_LEFT_PLANE ][2] * center[2] ;
> > >     sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[ 
> > > SG_RIGHT_PLANE ][2] * center[2] ;
> > >     sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ 
> SG_BOT_PLANE
> > > ][2] * center[2] ;
> > >     sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ 
> SG_TOP_PLANE
> > > ][2] * center[2] ;
> > >
> > > should be substituted by the following general form:
> > >
> > >     sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ], 
> center ) + 
> > > plane[ SG_LEFT_PLANE  ][3] ;
> > >     sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ], 
> center ) + 
> > > plane[ SG_RIGHT_PLANE ][3] ;
> > >     sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ],
> > > center ) + plane[
> > > SG_BOT_PLANE   ][3] ;
> > >     sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ],
> > > center ) + plane[
> > > SG_TOP_PLANE   ][3] ;
> > >
> > > The hint were just below there (see comment "Note: in the general 
> > > case, we would have to do:").
> > > I propose to patch it since this general form also manages the 
> > > default on-axis case, but Steve should definitely give 
> the go-ahead.
> > > Should someone be concerned about performances I could 
> supply a bit 
> > > larger patch for introducing the ability to supply the Context a 
> > > general perspective matrix, so to have the general case only 
> > > calculated in this eventuality.
> > >
> > > > Thanks a lot,
> > > >
> > > > Paolo Leoncini
> > >
> > > Thanks in advance to a good will updater (John, it's you 
> as usual?).
> > >
> > > Paolo Leoncini
> > >
> > >
> > > > --------------------------------------------------------------
> > > > ----------------
> > > > Download Intel&#174; Parallel Studio Eval Try the new
> > > software tools
> > > > for yourself. Speed compiling, find bugs proactively, and 
> > > > fine-tune applications for parallel performance.
> > > > See why Intel Parallel Studio got high marks during beta.
> > > > http://p.sf.net/sfu/intel-sw-dev
> > > > _______________________________________________
> > > > plib-users mailing list
> > > > pli...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/plib-users
> > > >
> > >
> > >
> > > --------------------------------------------------------------
> > > ----------------
> > > Download Intel&#174; Parallel Studio Eval Try the new 
> software tools 
> > > for yourself. Speed compiling, find bugs proactively, and 
> fine-tune 
> > > applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > plib-users mailing list
> > > pli...@li...
> > > https://lists.sourceforge.net/lists/listinfo/plib-users
> > >
> > > --------------------------------------------------------------
> > > ----------------
> > > Download Intel&#174; Parallel Studio Eval Try the new 
> software tools 
> > > for yourself. Speed compiling, find bugs proactively, and 
> fine-tune 
> > > applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > plib-users mailing list
> > > pli...@li...
> > > https://lists.sourceforge.net/lists/listinfo/plib-users
> > >
> >
> >
> >-------------------------------------------------------------
> ----------
> >-------
> >
> >_______________________________________________
> >plib-users mailing list
> >pli...@li...
> >https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> 
> --------------------------------------------------------------
> ----------------
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

[Plib-users] R: R: culling problems w/ off-axis projection

From: Paolo L. <p.l...@ci...> - 2010-04-21 14:41:09

Attachments: sg.patch

John,

Please find attached the patch.

This patch also include a fix to the function sgQuatToAxisAngle which
manages cases of Quat's W outside the range [-1:1] (acos undefined). For
this I used _isnan and _finite functions in MS Visual C++, whose
availability I ask all of you to verify on other Plib-supported platforms.
Otherwise just ignore this second part of the patch.

Thanks a lot,

Paolo Leoncini


> -----Messaggio originale-----
> Da: Fay, John F Dr CTR USAF AFMC 46 SK 
> [mailto:joh...@eg...] 
> Inviato: sabato 17 aprile 2010 18.33
> A: PLIB Users
> Oggetto: Re: [Plib-users] R: culling problems w/ off-axis projection
> 
> Paolo,
> 
> 	Congratulations and very good on having solved the 
> problem.  Is there a code change that you want me to put into 
> Subversion?
> 
> Dr. John F. Fay
> Technical Fellow
> Jacobs Technology TEAS Group
> 850-883-1294
> 
> 
> -----Original Message-----
> From: Paolo Leoncini [mailto:p.l...@ci...]
> Sent: Monday, April 12, 2010 3:21 AM
> To: 'PLIB Users'
> Subject: [Plib-users] R: culling problems w/ off-axis projection
> 
> Dear friends,
> 
> I think to have solved the problem.
> 
> > -----Messaggio originale-----
> > Da: p.l...@ci... [mailto:p.l...@ci...]
> > Inviato: martedì 6 aprile 2010 11.19
> > A: pli...@li...
> > Oggetto: [Plib-users] culling problems w/ off-axis projection
> > 
> > Dear all,
> > 
> > I'm doing off-axis projection (the most general form of
> > projection) by translating the four corners of the screen into a 
> > projection matrix, for which I added a new method to the sgFrustum 
> > class and to the Context too. The only difference with 
> giving the six 
> > frustum extrema values is that no calculation occurs. 
> Culling seems to 
> > rely only on the projection matrix values, so, apparently, no 
> > difference w/ the on-axis standard case.
> > 
> > As far as the projection is not far from the on-axis case 
> the culling 
> > gives no problem. Instead when screen position definition 
> results in a 
> > large rotation in the projection matrix objects suddenly 
> disappear and 
> > reappear by apparently no rule.
> > 
> > Are culling calculations based on a particular form of the 
> projection 
> > matrix?
> > should culling planes be extracted in a different way to 
> support the 
> > more general case?
> 
> In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for 
> the non-ortho case which is presently done this way:
> 
>     sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[ 
> SG_LEFT_PLANE ][2] * center[2] ;
>     sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[ 
> SG_RIGHT_PLANE ][2] * center[2] ;
>     sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ SG_BOT_PLANE
> ][2] * center[2] ;
>     sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ SG_TOP_PLANE
> ][2] * center[2] ;
> 
> should be substituted by the following general form:
> 
>     sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ], 
> center ) + plane[ SG_LEFT_PLANE  ][3] ;
>     sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ], 
> center ) + plane[ SG_RIGHT_PLANE ][3] ;
>     sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ], 
> center ) + plane[
> SG_BOT_PLANE   ][3] ;
>     sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ], 
> center ) + plane[
> SG_TOP_PLANE   ][3] ;
> 
> The hint were just below there (see comment "Note: in the 
> general case, we would have to do:").
> I propose to patch it since this general form also manages 
> the default on-axis case, but Steve should definitely give 
> the go-ahead.
> Should someone be concerned about performances I could supply 
> a bit larger patch for introducing the ability to supply the 
> Context a general perspective matrix, so to have the general 
> case only calculated in this eventuality.
> 
> > Thanks a lot,
> > 
> > Paolo Leoncini
> 
> Thanks in advance to a good will updater (John, it's you as usual?).
> 
> Paolo Leoncini
> 
> 
> > --------------------------------------------------------------
> > ----------------
> > Download Intel&#174; Parallel Studio Eval Try the new 
> software tools 
> > for yourself. Speed compiling, find bugs proactively, and fine-tune 
> > applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-users
> > 
> 
> 
> --------------------------------------------------------------
> ----------------
> Download Intel&#174; Parallel Studio Eval Try the new 
> software tools for yourself. Speed compiling, find bugs 
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
> --------------------------------------------------------------
> ----------------
> Download Intel&#174; Parallel Studio Eval Try the new 
> software tools for yourself. Speed compiling, find bugs 
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
>

Re: [Plib-users] R: R: culling problems w/ off-axis projection

From: John F. F. <joh...@cy...> - 2010-05-29 02:28:28

Paolo,
Message-Id: <201...@yo...>

         Please pardon my delay in answering; May 
is never a good month for me.  Did this patch get 
put in already, or did the patch file switch the "from" and "to" versions?

                 - John


At 09:40 AM 4/21/2010, you wrote:
>John,
>
>Please find attached the patch.
>
>This patch also include a fix to the function sgQuatToAxisAngle which
>manages cases of Quat's W outside the range [-1:1] (acos undefined). For
>this I used _isnan and _finite functions in MS Visual C++, whose
>availability I ask all of you to verify on other Plib-supported platforms.
>Otherwise just ignore this second part of the patch.
>
>Thanks a lot,
>
>Paolo Leoncini
>
>
> > -----Messaggio originale-----
> > Da: Fay, John F Dr CTR USAF AFMC 46 SK
> > [mailto:joh...@eg...]
> > Inviato: sabato 17 aprile 2010 18.33
> > A: PLIB Users
> > Oggetto: Re: [Plib-users] R: culling problems w/ off-axis projection
> >
> > Paolo,
> >
> >       Congratulations and very good on having solved the
> > problem.  Is there a code change that you want me to put into
> > Subversion?
> >
> > Dr. John F. Fay
> > Technical Fellow
> > Jacobs Technology TEAS Group
> > 850-883-1294
> >
> >
> > -----Original Message-----
> > From: Paolo Leoncini [mailto:p.l...@ci...]
> > Sent: Monday, April 12, 2010 3:21 AM
> > To: 'PLIB Users'
> > Subject: [Plib-users] R: culling problems w/ off-axis projection
> >
> > Dear friends,
> >
> > I think to have solved the problem.
> >
> > > -----Messaggio originale-----
> > > Da: p.l...@ci... [mailto:p.l...@ci...]
> > > Inviato: martedì 6 aprile 2010 11.19
> > > A: pli...@li...
> > > Oggetto: [Plib-users] culling problems w/ off-axis projection
> > >
> > > Dear all,
> > >
> > > I'm doing off-axis projection (the most general form of
> > > projection) by translating the four corners of the screen into a
> > > projection matrix, for which I added a new method to the sgFrustum
> > > class and to the Context too. The only difference with
> > giving the six
> > > frustum extrema values is that no calculation occurs.
> > Culling seems to
> > > rely only on the projection matrix values, so, apparently, no
> > > difference w/ the on-axis standard case.
> > >
> > > As far as the projection is not far from the on-axis case
> > the culling
> > > gives no problem. Instead when screen position definition
> > results in a
> > > large rotation in the projection matrix objects suddenly
> > disappear and
> > > reappear by apparently no rule.
> > >
> > > Are culling calculations based on a particular form of the
> > projection
> > > matrix?
> > > should culling planes be extracted in a different way to
> > support the
> > > more general case?
> >
> > In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for
> > the non-ortho case which is presently done this way:
> >
> >     sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[
> > SG_LEFT_PLANE ][2] * center[2] ;
> >     sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[
> > SG_RIGHT_PLANE ][2] * center[2] ;
> >     sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ SG_BOT_PLANE
> > ][2] * center[2] ;
> >     sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ SG_TOP_PLANE
> > ][2] * center[2] ;
> >
> > should be substituted by the following general form:
> >
> >     sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ],
> > center ) + plane[ SG_LEFT_PLANE  ][3] ;
> >     sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ],
> > center ) + plane[ SG_RIGHT_PLANE ][3] ;
> >     sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ],
> > center ) + plane[
> > SG_BOT_PLANE   ][3] ;
> >     sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ],
> > center ) + plane[
> > SG_TOP_PLANE   ][3] ;
> >
> > The hint were just below there (see comment "Note: in the
> > general case, we would have to do:").
> > I propose to patch it since this general form also manages
> > the default on-axis case, but Steve should definitely give
> > the go-ahead.
> > Should someone be concerned about performances I could supply
> > a bit larger patch for introducing the ability to supply the
> > Context a general perspective matrix, so to have the general
> > case only calculated in this eventuality.
> >
> > > Thanks a lot,
> > >
> > > Paolo Leoncini
> >
> > Thanks in advance to a good will updater (John, it's you as usual?).
> >
> > Paolo Leoncini
> >
> >
> > > --------------------------------------------------------------
> > > ----------------
> > > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools
> > > for yourself. Speed compiling, find bugs proactively, and fine-tune
> > > applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > plib-users mailing list
> > > pli...@li...
> > > https://lists.sourceforge.net/lists/listinfo/plib-users
> > >
> >
> >
> > --------------------------------------------------------------
> > ----------------
> > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-users
> >
> > --------------------------------------------------------------
> > ----------------
> > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-users
> >
>
>
>------------------------------------------------------------------------------
>
>_______________________________________________
>plib-users mailing list
>pli...@li...
>https://lists.sourceforge.net/lists/listinfo/plib-users

Re: [Plib-users] R: R: culling problems w/ off-axis projection

From: John F. F. <joh...@cy...> - 2010-05-31 12:35:54

Gentlemen,

         I have just put the below-mentioned 
patch into PLIB.  It uses the functions 
"_isnan"  and "_isfinite" which are just fine on 
my Windows/MSVC platform.  Please check it out on 
other platforms and let me know of any problems.

                 - John

At 09:40 AM 4/21/2010, you wrote:
>John,
>
>Please find attached the patch.
>
>This patch also include a fix to the function sgQuatToAxisAngle which
>manages cases of Quat's W outside the range [-1:1] (acos undefined). For
>this I used _isnan and _finite functions in MS Visual C++, whose
>availability I ask all of you to verify on other Plib-supported platforms.
>Otherwise just ignore this second part of the patch.
>
>Thanks a lot,
>
>Paolo Leoncini
>
>
> > -----Messaggio originale-----
> > Da: Fay, John F Dr CTR USAF AFMC 46 SK
> > [mailto:joh...@eg...]
> > Inviato: sabato 17 aprile 2010 18.33
> > A: PLIB Users
> > Oggetto: Re: [Plib-users] R: culling problems w/ off-axis projection
> >
> > Paolo,
> >
> >       Congratulations and very good on having solved the
> > problem.  Is there a code change that you want me to put into
> > Subversion?
> >
> > Dr. John F. Fay
> > Technical Fellow
> > Jacobs Technology TEAS Group
> > 850-883-1294
> >
> >
> > -----Original Message-----
> > From: Paolo Leoncini [mailto:p.l...@ci...]
> > Sent: Monday, April 12, 2010 3:21 AM
> > To: 'PLIB Users'
> > Subject: [Plib-users] R: culling problems w/ off-axis projection
> >
> > Dear friends,
> >
> > I think to have solved the problem.
> >
> > > -----Messaggio originale-----
> > > Da: p.l...@ci... [mailto:p.l...@ci...]
> > > Inviato: martedì 6 aprile 2010 11.19
> > > A: pli...@li...
> > > Oggetto: [Plib-users] culling problems w/ off-axis projection
> > >
> > > Dear all,
> > >
> > > I'm doing off-axis projection (the most general form of
> > > projection) by translating the four corners of the screen into a
> > > projection matrix, for which I added a new method to the sgFrustum
> > > class and to the Context too. The only difference with
> > giving the six
> > > frustum extrema values is that no calculation occurs.
> > Culling seems to
> > > rely only on the projection matrix values, so, apparently, no
> > > difference w/ the on-axis standard case.
> > >
> > > As far as the projection is not far from the on-axis case
> > the culling
> > > gives no problem. Instead when screen position definition
> > results in a
> > > large rotation in the projection matrix objects suddenly
> > disappear and
> > > reappear by apparently no rule.
> > >
> > > Are culling calculations based on a particular form of the
> > projection
> > > matrix?
> > > should culling planes be extracted in a different way to
> > support the
> > > more general case?
> >
> > In sgFrustum::contains( const sgSphere *s ) (sg.cxx), the for
> > the non-ortho case which is presently done this way:
> >
> >     sp1 = plane[ SG_LEFT_PLANE  ][0] * center[0] + plane[
> > SG_LEFT_PLANE ][2] * center[2] ;
> >     sp2 = plane[ SG_RIGHT_PLANE ][0] * center[0] + plane[
> > SG_RIGHT_PLANE ][2] * center[2] ;
> >     sp3 = plane[ SG_BOT_PLANE   ][1] * center[1] + plane[ SG_BOT_PLANE
> > ][2] * center[2] ;
> >     sp4 = plane[ SG_TOP_PLANE   ][1] * center[1] + plane[ SG_TOP_PLANE
> > ][2] * center[2] ;
> >
> > should be substituted by the following general form:
> >
> >     sp1 = sgScalarProductVec3 ( plane[ SG_LEFT_PLANE  ],
> > center ) + plane[ SG_LEFT_PLANE  ][3] ;
> >     sp2 = sgScalarProductVec3 ( plane[ SG_RIGHT_PLANE ],
> > center ) + plane[ SG_RIGHT_PLANE ][3] ;
> >     sp3 = sgScalarProductVec3 ( plane[ SG_BOT_PLANE   ],
> > center ) + plane[
> > SG_BOT_PLANE   ][3] ;
> >     sp4 = sgScalarProductVec3 ( plane[ SG_TOP_PLANE   ],
> > center ) + plane[
> > SG_TOP_PLANE   ][3] ;
> >
> > The hint were just below there (see comment "Note: in the
> > general case, we would have to do:").
> > I propose to patch it since this general form also manages
> > the default on-axis case, but Steve should definitely give
> > the go-ahead.
> > Should someone be concerned about performances I could supply
> > a bit larger patch for introducing the ability to supply the
> > Context a general perspective matrix, so to have the general
> > case only calculated in this eventuality.
> >
> > > Thanks a lot,
> > >
> > > Paolo Leoncini
> >
> > Thanks in advance to a good will updater (John, it's you as usual?).
> >
> > Paolo Leoncini
> >
> >
> > > --------------------------------------------------------------
> > > ----------------
> > > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools
> > > for yourself. Speed compiling, find bugs proactively, and fine-tune
> > > applications for parallel performance.
> > > See why Intel Parallel Studio got high marks during beta.
> > > http://p.sf.net/sfu/intel-sw-dev
> > > _______________________________________________
> > > plib-users mailing list
> > > pli...@li...
> > > https://lists.sourceforge.net/lists/listinfo/plib-users
> > >
> >
> >
> > --------------------------------------------------------------
> > ----------------
> > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-users
> >
> > --------------------------------------------------------------
> > ----------------
> > Download Intel&#174; Parallel Studio Eval Try the new
> > software tools for yourself. Speed compiling, find bugs
> > proactively, and fine-tune applications for parallel performance.
> > See why Intel Parallel Studio got high marks during beta.
> > http://p.sf.net/sfu/intel-sw-dev
> > _______________________________________________
> > plib-users mailing list
> > pli...@li...
> > https://lists.sourceforge.net/lists/listinfo/plib-users
> >
>
>
>------------------------------------------------------------------------------
>
>_______________________________________________
>plib-users mailing list
>pli...@li...
>https://lists.sourceforge.net/lists/listinfo/plib-users