plib-devel

Re: [Plib-devel] ssg Borland

[Wolfram K. <w_...@rz...>]

John F. Fay wrote:

>This is a pointer to a constant array rather than being a constant =
pointer
>to an array. =20

Doh!=20
Good, so we understand what happens. All other compilers are correct
in allowing that code.=20

Ok, it should be easy to rewrite the code to avoid the construct the
Mac compiler has problems with. Unfortunately, I am down to about 5-10
spare hours per week, so it might take me a few days.


Bye bye,
Wolfram.

Re: [Plib-devel] Another New Demo Program for PW

[Nick M. <nic...@ds...>]

I don't have time myself to 'understand' and then fix this problem right 
now ... but if someone is interested in adding Multisampling for Windows 
to pwInit then here is a tutorial that might be useful ...

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=46


Steve Baker wrote:

>Fay John F Contr AAC/WMG wrote:
>  
>
>>To coin a phrase, I think you are being slightly X-centric <grin>.
>>    
>>
>
>No - there is certainly multisampling under Windows.
>
>  
>
>>I don't
>>see anything about multisampling in the MSVC documentation ...
>>    
>>
>
>Yeah - well, Microsoft don't exactly enthusiastically support OpenGL.
>OpenGL can do it under Windows *for*sure* - but you'll have to look
>away from Microsoft to get the information.   nVidia or ATI perhaps?
>
>  
>
>>so I guess Windows will simply continue to ignore that parameter.
>>    
>>
>
>That would be a disaster!   Multisampling is very important these days.
>
>  
>
>>We do have another parameter in "pwInit", though, the "num_samples", which I
>>hadn't noticed last Friday.  Suggestions?
>>    
>>
>
>Ah - now you come to mention it - that is the number of multisample samples.
>  
>

Re: [Plib-devel] Another New Demo Program for PW

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:
> To coin a phrase, I think you are being slightly X-centric <grin>.

No - there is certainly multisampling under Windows.

> I don't
> see anything about multisampling in the MSVC documentation ...

Yeah - well, Microsoft don't exactly enthusiastically support OpenGL.
OpenGL can do it under Windows *for*sure* - but you'll have to look
away from Microsoft to get the information.   nVidia or ATI perhaps?

> so I guess Windows will simply continue to ignore that parameter.

That would be a disaster!   Multisampling is very important these days.

> We do have another parameter in "pwInit", though, the "num_samples", which I
> hadn't noticed last Friday.  Suggestions?

Ah - now you come to mention it - that is the number of multisample samples.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] PUI rendering fixes

[Andy R. <an...@pl...>]

Steve Baker wrote:
> Andy Ross wrote:
> > I also changed the stipple to a simpler 1010 pattern from the
> > four-pixel dash pattern it originally had.  IMHO, the tighter
> > pattern is prettier.
>
> I chose the 0x0F0F pattern because 0x5555 or even 0x3333 tend to
> look more like a grey line on cheap high resolution CRT's.

And is a grey line undesirable?  FWIW, current versions of Gtk+ use
exactly the same stipple pattern to indicate their keyboard focus.
I've attached two (tiny) screenshots of the old and new code as an
example.  Honestly, the wide dashes look kinda clunky to me.  Would
you accept a patch that made the value settable?

Andy

Re: [Plib-devel] PUI rendering fixes

[Steve B. <sjb...@ai...>]

Andy Ross wrote:

> The dashed line rendered for the "default" button almost always cut
> right through the button text.  I moved it out by three pixels, which
> gives it one pixel of margin from the edge of the thickest widget
> border.  I also changed the stipple to a simpler 1010 pattern from the
> four-pixel dash pattern it originally had.  IMHO, the tighter pattern
> is prettier.

I chose the 0x0F0F pattern because 0x5555 or even 0x3333 tend to look more
like a grey line on cheap high resolution CRT's.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] PUI rendering fixes

[Andy R. <an...@pl...>]

I started chasing down a font rendering issue in FlightGear on Sunday.
The original issue was a metrics bug in the afm2txf.pl font generator,
a script I wrote for plib a while back.  But fixing that didn't quite
solve all the problems, so I spent some time hunting around in the PUI
rendering code and fixing buglets.  The patch is attached.
Explanations:

There was a hard-coded assumption in fnt.cxx that when rendering
multi-line strings the interline distance was 1.333 * pointsize.  My
guess is that this was there as a workaround for an older bug
somewhere; pointsize is, of course, the very definition of interline
distance.

Likewise, puFont has a getStringHeight() with the same baked-in
constant.  I rewrote this to use the more common GUI convention that
the height of a single line of text is "ascender + descender", instead
of the full point size (which includes significant whitespace in many
fonts).

Once that was changed, it exposed some weirdness in the vertical
positioning code in puInput and puObject.  I'm honestly not sure what
the older formulas were trying to do.  I changed them all to adhere to
the line height convention above (i.e.: ascender + descender + (Nlines
- 1) * pointsize).  Vertical centering of text now looks significantly
better.

The dashed line rendered for the "default" button almost always cut
right through the button text.  I moved it out by three pixels, which
gives it one pixel of margin from the edge of the thickest widget
border.  I also changed the stipple to a simpler 1010 pattern from the
four-pixel dash pattern it originally had.  IMHO, the tighter pattern
is prettier.

The rendering code for the "default" line also had a coordinate
aliasing bug: when drawing GL_LINES, you have to use pixel center
coordinates or else the GL will see a value exactly on the edge of two
pixels and you'll get funny off-by-one artifacts.

I fixed a similar coordinate issue with the puInput caret rendering.
I also increased its height; most GUIs draw this from the bottom of
the descender to the baseline of the next line.

I tried this with a bunch of test code (and FlightGear, of course) and
it doesn't seem to break anything.

Andy

RE: [Plib-devel] ssg Borland

[Fay J. F C. AAC/W. <joh...@eg...>]

The variable type "sgMat4" is typedef'ed to "sgFloat [4][4]", so I think the
argument is equivalent to

const sgFloat m[4][4]

This is a pointer to a constant array rather than being a constant pointer
to an array.  As such, an assignment like

m = w ;

is legal while an assignment like

m[0][0] = 1.0 ;

is not legal.  Or so I surmise.  The MSVC help files say this about "const":

<begin quote>
The const keyword can also be used in pointer declarations.

char *const aptr = mybuf;  // Constant pointer

*aptr = 'a';       // Legal
aptr = yourbuf;    // Error

A pointer to a variable declared as const can be assigned only to a pointer
that is also declared as const.

const char *bptr = mybuf;  // Pointer to constant data

*bptr = 'a';       // Error
bptr = yourbuf;    // Legal
<end quote>

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Wolfram Kuss
Sent: Tuesday, May 04, 2004 7:58 AM
To: pli...@li...
Subject: Re: [Plib-devel] ssg Borland

<snip>

>ssgVtxTable.cxx
>
>Within void ssgVtxTable::transform ( const sgMat4 m ) there is a line that
>says:
>
> 
>
>m = w;

Maybe this is a stupid question, but why do other compilers not even
warn? I checked and MSVC has no problems with that line.

Bye bye,
Wolfram.

Re: [Plib-devel] ssg Borland

[Wolfram K. <w_...@rz...>]

I commited all your changes apart from two (see below).

Also with some changes like

>#ifdef UL_BB
>
>ssgListOfLists ( int init =3D 3 ) : ssgSimpleList ( =
sizeof(ssgSimpleList*),
>init ) {}
>
>#else
>
>ssgListOfLists ( int init =3D 3 ) : ssgSimpleList ( sizeof(class
>ssgSimpleList*), init ) {}
>
>#endif


I think that all compilers will be able to work with the Macintosh
friendly code. I checked and MSVC works with it. So, I changed the
code to the one without "class" and did not add any "#ifdef" here.

The two changes I did not commit are:

>Ul.h
>
>After the system if defs I added:
>
>
>#if defined(BORLANDBUILDER)
>
>#define UL_BB     1
>
>#endif

Unfortunately, for unknown reasons my ul.h is different to the one in
CVS and I don't have the time now to investigate.=20

>ssgVtxTable.cxx
>
>Within void ssgVtxTable::transform ( const sgMat4 m ) there is a line =
that
>says:
>
>=20
>
>m =3D w;

Maybe this is a stupid question, but why do other compilers not even
warn? I checked and MSVC has no problems with that line.

Bye bye,
Wolfram.

Re: [Plib-devel] Build Problem under MacOS X 10.3.3

[Jonathan P. <eq_...@ma...>]

Steve,

     FWIW, while it is nice to be able to get the files from CVS, the fact that I was able to get them in a nice, easy, package is the most important thing.  After all *sniff*, we Mac users *whimper* are use to the fact that no one loves us *sob* .  ;)

     From me, at least, there is no major rush.

Jonathan Polley

On Monday, May 03, 2004, at 05:35PM, Steve Baker <sjb...@ai...> wrote:

>Fay John F Contr AAC/WMG wrote:
>
>> OK, this is getting ridiculous.  Olivier rewrote the JS library and it was
>> ready for testing four weeks ago and it still isn't in CVS.  I'm sending it
>> to Jonathan separately but in the meantime when is it going to go into CVS?
>
>I should probably feel guilty about not doing this - but there are TWENTY THREE
>people with CVS checkin privilages for PLIB - and I'm *really* busy at work right
>now.
>
>---------------------------- Steve Baker -------------------------
>HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
>HomePage : http://www.sjbaker.org
>Projects : http://plib.sf.net    http://tuxaqfh.sf.net
>            http://tuxkart.sf.net http://prettypoly.sf.net
>-----BEGIN GEEK CODE BLOCK-----
>GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
>V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
>-----END GEEK CODE BLOCK-----
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: Oracle 10g
>Get certified on the hottest thing ever to hit the market... Oracle 10g. 
>Take an Oracle 10g class now, and we'll give you the exam FREE.
>http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
>_______________________________________________
>plib-devel mailing list
>pli...@li...
>https://lists.sourceforge.net/lists/listinfo/plib-devel
>
>
 

Of COURSE they can do that.  They're engineers!

Re: [Plib-devel] Build Problem under MacOS X 10.3.3

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:

> OK, this is getting ridiculous.  Olivier rewrote the JS library and it was
> ready for testing four weeks ago and it still isn't in CVS.  I'm sending it
> to Jonathan separately but in the meantime when is it going to go into CVS?

I should probably feel guilty about not doing this - but there are TWENTY THREE
people with CVS checkin privilages for PLIB - and I'm *really* busy at work right
now.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] re: Build Problem under MacOS X 10.3.3

[<ima...@ve...>]

> OK, this is getting ridiculous.  Olivier rewrote the JS library and it 
> was
> ready for testing four weeks ago and it still isn't in CVS.  I'm 
> sending it
> to Jonathan separately but in the meantime when is it going to go into 
> CVS?
>
> John F. Fay
> joh...@eg...

Olivier's joystick code works great on Mac OS X 10.3.3.  There are 
significant improvements, especially hat support and the removal of 
some bus errors that I no longer see with the new js version on Mac OS 
X. I am also using 10.3.3

Thanks!

Ima

[Plib-devel] ssg Borland

[Simon <sim...@ho...>]

Hi, ok well here are the changes I had to make to get ssg to build with
Borland C++ Builder 6 on Windows XP:

=20

Ul.h

After the system if defs I added:

=20

#if defined(BORLANDBUILDER)

#define UL_BB     1

#endif

=20

ssgVtxTable.cxx

Within void ssgVtxTable::transform ( const sgMat4 m ) there is a line =
that
says:

=20

m =3D w;

=20

I had to comment it out - the error message is that you cannot modify a
const object, I think this is a bad solution on my part.  Definitely a =
quick
fix.

=20

ssgLoaderWriterStuff.h

Within ssgListOfLists : public ssgSimpleList

=20

#ifdef UL_BB

ssgListOfLists ( int init =3D 3 ) : ssgSimpleList ( =
sizeof(ssgSimpleList*),
init ) {}

#else

ssgListOfLists ( int init =3D 3 ) : ssgSimpleList ( sizeof(class
ssgSimpleList*), init ) {}

#endif

=20

Also within ssgSimpleStateList : public ssgSimpleList

=20

#ifdef UL_BB

ssgSimpleStateList( int init =3D 3 ) : ssgSimpleList (
sizeof(ssgSimpleState*), init ) {}

#else

ssgSimpleStateList( int init =3D 3 ) : ssgSimpleList ( sizeof(class
ssgSimpleState*), init ) {}

#endif

=20

Also within ssgListOfNodes : public ssgSimpleList

=20

#ifdef UL_BB

ssgListOfNodes ( int init =3D 3 ) : ssgSimpleList ( sizeof(ssgBase*), =
init )
{}

#else

ssgListOfNodes ( int init =3D 3 ) : ssgSimpleList ( sizeof(class =
ssgBase*),
init ) {}

#endif

=20

ssgParser.cxx

Inside static char *mystrchr( const char *string, int c )

=20

#ifdef UL_BB

return strchr( (char*)string, c );

#else

return strchr( string, c );

#endif

=20

ssgSaveAC.cxx

Inside static int ssgSaveLeaf ( ssgEntity *ent )

=20

if ( writeTextureWithoutPath )

        {

          #ifdef UL_BB

          char *s =3D strrchr ( (char*)tfname, '\\' ) ;

          #else

          char *s =3D strrchr ( tfname, '\\' ) ;

          #endif

=20

          if ( s =3D=3D NULL )

            #ifdef UL_BB

             s =3D strrchr ( (char*)tfname, '/' ) ;

            #else

            s =3D strrchr ( tfname, '/' ) ;

            #endif

.

=20

ssgLoadMDL_BGLTexture.cxx

Inside: bool ssgLoadMDLTexture ( const char *fname, ssgTextureInfo* info =
)

at the top of the first if statement:

=20

#ifdef UL_BB

char *p =3D strrchr((char*)fname,'_');

#else

char *p =3D strrchr(fname,'_');

#endif

=20

That's it for now.  I'll post any other fixes I have to do as I make =
them.
Hope someone can recommend something for the first one (m=3Dw).  I made =
the
changes to non beautified versions of the source files so I posted those =
as
well.  I think I got all the file names right, I was really speeding =
through
as I want to get back to work soon.

=20

Edit-> The mail I sent with the zip file got bounced back.  The zip is
available below for the next week or so:

=20

http://www.millington.no-ip.org/trials/plibfixes.zip

=20

RE: [Plib-devel] Build Problem under MacOS X 10.3.3

[Fay J. F C. AAC/W. <joh...@eg...>]

OK, this is getting ridiculous.  Olivier rewrote the JS library and it was
ready for testing four weeks ago and it still isn't in CVS.  I'm sending it
to Jonathan separately but in the meantime when is it going to go into CVS?

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Jonathan
Polley
Sent: Saturday, May 01, 2004 8:46 PM
To: pli...@li...
Subject: [Plib-devel] Build Problem under MacOS X 10.3.3


Thinking that I had somehow screwed up my directory, I pulled down a 
fresh snapshot of plib and tried to build it.  Unfortunately, I got the 
following errors:

In file included from js.cxx:23:
js.h:97: error: data member may not have variably modified type `
    io_object_t[jsJoystick::kNumDevices]'
make[2]: *** [js.o] Error 1


Any idea as to what is going wrong?  Could someone who has a working 
MacOS version of plib check their changes into CVS?

Thanks!

Jonathan Polley



-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] Another New Demo Program for PW

[Fay J. F C. AAC/W. <joh...@eg...>]

To coin a phrase, I think you are being slightly X-centric <grin>.  I don't
see anything about multisampling in the MSVC documentation ... so I guess
Windows will simply continue to ignore that parameter.

We do have another parameter in "pwInit", though, the "num_samples", which I
hadn't noticed last Friday.  Suggestions?

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Friday, April 30, 2004 5:46 PM
To: pli...@li...
Subject: Re: [Plib-devel] Another New Demo Program for PW


Fay John F Contr AAC/WMG wrote:
> OK, I think that sounds like a plan.  Since the "bool" is in the sample
> program, I think we can just change it right away.  How does PW decide
what
> is the best possible multisampling?

Well, probably we just try 16 multisamples and work down towards zero until
X says we have a valid rendering context.  On nVidia hardware, there is an
additional GL_NICEST hint that selects between what was once called
'quincunx'
mode and the simpler, basic mode.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----


-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. 
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

Re: [Plib-devel] Building with Borland

[Wolfram K. <w_...@rz...>]

Hi,

>There=92s a few changes that need to be made to get it to
>build ok with Borland Builder 6 for Windows. =20

Great!

>I also have source styler and use
>this to format all the source files after downloading. =20

Ah :-(. Is it possible that you do the changes inside ifdefs to=20
the original code (non beautified)? Changing formatting is
unfortunately a great way to make CVS find a TON of changes.

Bye bye,
Wolfram.

[Plib-devel] Building with Borland

[Simon <sim...@ho...>]

Hi, I didn=92t say thanks to Paolo for the physics pointers so thank you =
:=AC)

=20

Ok so I got the latest stable plib release as I thought I would start
(again) with that.  There=92s a few changes that need to be made to get =
it to
build ok with Borland Builder 6 for Windows.  I=92ve only tried building =
ssg
lately so a few other libs get pulled in as well like sg.  Anyway I=92ve =
got
the fixes pretty sorted now, it=92s just a few type casts and commenting
something out.  I was wondering if you would be interested in me adding =
some
form of directive to count builder as an option.  I can do some =93if=94
statements to use the correct syntax.  I also have source styler and use
this to format all the source files after downloading.  PLIB looks =
really
nice when it=92s beautified.  At the least I could do this and leave the
Borland fixes out.  Anyone interested?  I remember when I used pui ages =
ago
that there were some changes that had to be made to that as well to get =
it
to build.  I can add changes that are required as I come across them, =
i.e at
the moment I=92m only using ssg so the only fixes I can post are with =
this but
later on I might use pui again so I can do some for that as well.

[Plib-devel] Build Problem under MacOS X 10.3.3

[Jonathan P. <eq_...@ma...>]

Thinking that I had somehow screwed up my directory, I pulled down a 
fresh snapshot of plib and tried to build it.  Unfortunately, I got the 
following errors:

In file included from js.cxx:23:
js.h:97: error: data member may not have variably modified type `
    io_object_t[jsJoystick::kNumDevices]'
make[2]: *** [js.o] Error 1


Any idea as to what is going wrong?  Could someone who has a working 
MacOS version of plib check their changes into CVS?

Thanks!

Jonathan Polley

Re: [Plib-devel] Another New Demo Program for PW

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:
> OK, I think that sounds like a plan.  Since the "bool" is in the sample
> program, I think we can just change it right away.  How does PW decide what
> is the best possible multisampling?

Well, probably we just try 16 multisamples and work down towards zero until
X says we have a valid rendering context.  On nVidia hardware, there is an
additional GL_NICEST hint that selects between what was once called 'quincunx'
mode and the simpler, basic mode.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

RE: [Plib-devel] Is a point inside a triangle in 3-d

[Fay J. F C. AAC/W. <joh...@eg...>]

OK, I have a well-tested point-inside-a-triangle function in two dimensions.

I have a poorly-tested point-inside-a-triangle function in three dimensions.
The problem is not well-posed (the point may not lie on the plane of the
triangle) and it will give different answers from the present function in
SG.  The differences are especially apparent if the point does not lie in
the plane of the triangle, in which case the present code can easily give an
improper answer.

I have a somewhat-tested intersection-of-two-lines function in three
dimensions.  It is consistent with the documentation although it gives
different results from the present algorithm if the two lines do not
actually intersect.

I did a bit of work on a function to return the line of intersection between
two planes but realized that the general vector algebra solution would be
less efficient than the present code so I gave it up.

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Norman Vine
Sent: Friday, March 26, 2004 9:37 AM
To: pli...@li...
Subject: RE: [Plib-devel] Is a point inside a triangle in 3-d


John Fay writes:

>       I've been mulling the 3-d version of the point/triangle problem and
I have a question or two.
>        (1) The current code assumes that the point and the triangle are in
the same plane.  Is this a good thing?
>        (2) Is there a need for a faster point-in-triangle function?


One always needs a faster intersection routine :-)

To see how this one is used see < URL all one line >

http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/FlightGear/src/Scenery
/hitlist.cxx?rev=1.9&cvsroot=FlightGear-0.9&content-type
=text/vnd.viewcvs-markup

The code is not the easiest to follow but a generic line intersection
with a SSG tree is in there

< the line is described by its origin and direction >

void FGHitList::Intersect( ssgBranch *scene, sgdVec3 orig, sgdVec3 dir ) {
    sgdMat4 m;
    clear();
    sgdMakeIdentMat4 ( m ) ;
    IntersectBranch( scene, m, orig, dir );
}

Cheers

Norman




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
plib-devel mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-devel

RE: [Plib-devel] Another New Demo Program for PW

[Fay J. F C. AAC/W. <joh...@eg...>]

OK, I think that sounds like a plan.  Since the "bool" is in the sample
program, I think we can just change it right away.  How does PW decide what
is the best possible multisampling?

John F. Fay
joh...@eg...



-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Steve Baker
Sent: Tuesday, April 27, 2004 7:59 PM
To: pli...@li...
Subject: Re: [Plib-devel] Another New Demo Program for PW


<snip>

> 	The second is a PW issue which I think I raised earlier.  The fifth
> argument of "pwInit" is "int multisample" which in the "pw_demo" program
is
> set to "false".  I think an "int" should be "TRUE" and "FALSE" rather than
> the strict boolean values of "true" and "false".  I propose that we either
> change the "pwInit" function to take a "bool" or else we change "pw.h" to
> include definitions of "TRUE" and "FALSE" and change the sample programs
to
> pass those.  My personal preference is for the latter.

Actually, we should probably step back and think a bit more about that.
When
you turn on multisampling, there is generally a choice as to the number of
subsamples - and sometimes other qualitative parameters.

Perhaps we should change it to some kind of enumeration such that zero means
"no multisampling", one means "best possible multisampling" and other values
could be added later.   This would keep existing programs working - but
allow
for more fancy stuff later.

<snip>

[Plib-devel] RE: sgPointInTriangle2

[Fay J. F C. AAC/W. <joh...@eg...>]

For an additional note:  I modified the algorithm slightly so that all
subtractions are done relative to the corner of the triangle nearest the
point being tested.  This makes the algorithm considerably more robust in
cases where one corner of the triangle has coordinates greater than the
others by several orders of magnitude.

I have noticed that the existing algorithm gives significantly different
results when in MSVC debug mode than it does in MSVC release mode for
degenerate triangles.  In the case of degenerate triangles, many
"reasonable" cases (all coordinates the same order of magnitude and the
point is clearly off the line segment created by the degenerate triangle)
give false positives.

In release mode, I ran a case (with "stretched" triangles with one corner
having coordinates three orders of magnitude larger than the other corners)
and found out of 29,000,000 points tested there were 218 cases in which the
two algorithms disagreed.  From a brief inspection it appears that all
involve the "stretched" triangles.  An in-depth analysis of two of them
shows that the new algorithm gives correct answers where the existing
algorithm does not.

The bottom line is that I have tested the new algorithm rather severely and
I think it should go into the SG library.

John F. Fay
joh...@eg...

[Plib-devel] sgPointInTriangle2

[Fay J. F C. AAC/W. <joh...@eg...>]

Gentlemen,

	A couple of months ago I put out a new algorithm for calculating
whether a point is in a triangle in two dimensions.  This algorithm is
robust and is a good bit faster than the one currently in the SG library.
At the time I listed the number of multiplications and so on and noted that
it avoided some square root taking.  The reaction at the time was that this
was a new and unheard-of algorithm and that we would do well to play it safe
with the SG library.

	Since then I have put it and the present algorithm through some
rather stringent tests.  Under all reasonable circumstances, they give
identical results.  The new algorithm handles degenerate triangles slightly
better than the present algorithm, which includes my good friend "NaN" (Not
a Number) in its calculations under these circumstances.  I have just given
them Steve Baker's test of "Given a grid of triangles, will the point fall
into exactly one of the triangles".  For a reasonable grid (no exceptionally
elongated triangles, although two of the 50 triangles were degenerate) I
checked some 16,000,000 points and found no multiple-triangle hits.  With
some extremely elongated triangles (an aspect ratio of 1000 or so) I am
getting about 50 double hits (where the point is flagged as being in two
triangles) when checking 10,000,000 points.  Again, both the present
algorithm and the new algorithm give identical results.

	Based on these results, I would like to offer the new
"sgPointInTriangle2" function for the SG library.  It behaves at least no
worse than the present algorithm and does it considerably faster.

John F. Fay
joh...@eg...

Re: [Plib-devel] Another New Demo Program for PW

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:

> 	I have a couple of notes on your changes.  The first is that the
> "%lf" is good for the "printf" statements but we need to be careful with the
> "sscanf" statements.  I've put in a "float_value" variable which actually
> gets read from the strings.

Yep.

> 	The second is a PW issue which I think I raised earlier.  The fifth
> argument of "pwInit" is "int multisample" which in the "pw_demo" program is
> set to "false".  I think an "int" should be "TRUE" and "FALSE" rather than
> the strict boolean values of "true" and "false".  I propose that we either
> change the "pwInit" function to take a "bool" or else we change "pw.h" to
> include definitions of "TRUE" and "FALSE" and change the sample programs to
> pass those.  My personal preference is for the latter.

Actually, we should probably step back and think a bit more about that.  When
you turn on multisampling, there is generally a choice as to the number of
subsamples - and sometimes other qualitative parameters.

Perhaps we should change it to some kind of enumeration such that zero means
"no multisampling", one means "best possible multisampling" and other values
could be added later.   This would keep existing programs working - but allow
for more fancy stuff later.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

Re: [Plib-devel] puChooser Widget

[Steve B. <sjb...@ai...>]

Fay John F Contr AAC/WMG wrote:

> 	I think I asked before, but I don't remember the answer.  The
> Triereis project has a potential PUI widget called the "puChooser" which you
> had said was eventually going to go into PLIB.  My question is, should it go
> into PUI or into puAux?

puAux I think.  Please feel free to move it if you have the time.  As I explained
before, I'm really snowed under with work right now and I don't really have any
time for OpenSource work for at least a few weeks to come.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----

[Plib-devel] puChooser Widget

[Fay J. F C. AAC/W. <joh...@eg...>]

Steve,

	I think I asked before, but I don't remember the answer.  The
Triereis project has a potential PUI widget called the "puChooser" which you
had said was eventually going to go into PLIB.  My question is, should it go
into PUI or into puAux?

John F. Fay
joh...@eg...