plib-devel

Re: [Plib-devel] Linux joystick crash and fix.

[Mathias <Mat...@gm...>]

Hi,

On Montag 21 Februar 2005 08:41, Bram Stolk wrote:
> I recall having seen this patch a month ago or so, but I assume
> it was dropped then for no appearant reasons?
Yes. I guess nobody felt responsible for that one :)
Thanks.

   Greetings

          Mathias

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

Re: [Plib-devel] Linux joystick crash and fix.

[Bram S. <br...@sa...>]

Mathias,

I've committed your patch to the CVS repository.

I recall having seen this patch a month ago or so, but I assume
it was dropped then for no appearant reasons?

   Bram

On 02/21/05 07:45:10, Mathias Fr=C3=B6hlich wrote:
>=20
> Hi,
>=20
> If a joystick has more than _JS_MAX_AXES axes, the JSIOCGCORR ioctl
> will
> crash.
> Attached is a fix to that by making the data dynamic allocated with
> the
> correct size.
>=20
> Please apply!
>=20
>        Greetings
>=20
>             Mathias
>=20
> --
> Mathias Fr=C3=B6hlich, email: Mat...@gm...
>

> Index: src/js/jsLinux.cxx
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/plib/plib/src/js/jsLinux.cxx,v
> retrieving revision 1.6
> diff -u -r1.6 jsLinux.cxx
> --- src/js/jsLinux.cxx	20 Oct 2004 23:49:33 -0000	1.6
> +++ src/js/jsLinux.cxx	3 Feb 2005 18:24:56 -0000
> @@ -75,12 +75,13 @@
>    ioctl ( os->fd, JSIOCGNAME ( sizeof(name) ), name ) ;
>    fcntl ( os->fd, F_SETFL      , O_NONBLOCK   ) ;
>=20
> +  int all_axes =3D num_axes;
>    if ( num_axes > _JS_MAX_AXES )
>      num_axes =3D _JS_MAX_AXES ;
>=20
>    // Remove any deadband value already done in the kernel.
>    // Since we have our own deadband management this is save to do
> so.
> -  struct js_corr corr [ _JS_MAX_AXES ] ;
> +  struct js_corr* corr =3D new js_corr[ all_axes ] ;
>    ioctl ( os->fd, JSIOCGCORR, corr );
>    for ( int i =3D 0; i < num_axes ; ++i ) {
>      if ( corr[ i ] . type =3D=3D JS_CORR_BROKEN ) {
> @@ -90,6 +91,7 @@
>      }
>    }
>    ioctl ( os->fd, JSIOCSCORR, corr );
> +  delete[] corr;
>=20
>    for ( int i =3D 0 ; i < _JS_MAX_AXES ; i++ )
>    {
>=20

[Plib-devel] Linux joystick crash and fix.

[Mathias <Mat...@gm...>]

Hi,

If a joystick has more than _JS_MAX_AXES axes, the JSIOCGCORR ioctl will=20
crash.
Attached is a fix to that by making the data dynamic allocated with the=20
correct size.

Please apply!

       Greetings

            Mathias

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

[Plib-devel] trivial bug in jsLinuxOld.cxx

[Stanislav I. <in...@al...>]

Greetings!

You have a little mistake in the #ifdefs

jsLinux.cxx
--
#if defined(JS_VERSION) && JS_VERSION >= 0x010000 
--

jsLinuxOld.cxx
--
#if !defined(JS_VERSION) || JS_VERSION >= 0x010000                                           
--

As a result _both_ versions of each method will always include if JS_VERSION >=0.10000 and JS_VERSION defined.


diff -Naur plib-1.8.4/src/js/jsLinuxOld.cxx
plib-1.8.4.new/src/js/jsLinuxOld.cxx             
--- plib-1.8.4/src/js/jsLinuxOld.cxx    2004-10-21 03:49:33 +0400                            
+++ plib-1.8.4.new/src/js/jsLinuxOld.cxx        2005-02-08 14:33:24 +0300                    
@@ -27,7 +27,7 @@                                                                            
                                                                                             
 #include <linux/joystick.h>                                                                 
                                                                                             
-#if !defined(JS_VERSION) || JS_VERSION >= 0x010000                                          
+#if !defined(JS_VERSION) || JS_VERSION < 0x010000                                           
                                                                                             
 #include <fcntl.h>                                                                          
 #include <sys/ioctl.h>   

--
With best regards
Stanislav Ievlev

ALT Linux Team.

[Plib-devel] RE: FlightGears puList code

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

Erik,

	Thank you for looking at the code.  I am glad that it works well.
Unfortunately, because of my address (".mil") I am behind a serious firewall
and am terminally CVS-challenged.  I cannot upload it to CVS, therefore, and
need somebody else to do it for me.

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: Erik Hofman [mailto:er...@eh...] 
Sent: Saturday, February 05, 2005 5:50 AM
To: Fay John F Contr AAC/WMG
Subject: Re: FlightGears puList code

Fay John F Contr AAC/WMG wrote:
> Erik,
> 
>         Attached are two "puAux" files.  The "puAuxList.cxx" file would 
> be added to the present "puAux" list of files while "puAux.h" would 
> replace the existing one.  The name of the widget will have to change 
> from "puList" to "puaList" to conform with the "puAux" naming 
> convention.  Please substitute this in and check it out.  If it works, I 
> will see about putting it into CVS.

This code itself works perfectly. If you wish you can commit it. There 
are two issues puAux issues that need to sorted out before the next 
release (compiler errors on IRIX/MIPSpro). But I will handle that in a 
separate message.

Erik

Re: [Plib-devel] Portability - policy suggestion

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

Martin Spott wrote:
> Steve Baker wrote:
> 
> 
>>Once we've gotten the thing to the point where it's basically releasable,
>>doing a new version is a 10 minute job - and version numbers are a very
>>cheap commodity.
> 
> 
> Would anyone consider reviewing the patches as proposed by Paolo
> Leoncini ?
> I think improving the 3DS loader is always a "good thing" (TM  :-)

Yeah - those are good changes - I've just been too busy to do anything
about them.

---------------------------- 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] Portability - policy suggestion

[Martin S. <Mar...@un...>]

Steve Baker wrote:

> Once we've gotten the thing to the point where it's basically releasable,
> doing a new version is a 10 minute job - and version numbers are a very
> cheap commodity.

Would anyone consider reviewing the patches as proposed by Paolo
Leoncini ?
I think improving the 3DS loader is always a "good thing" (TM  :-)

Martin.
-- 
 Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------

Re: [Plib-devel] Sphere intersection tests, and ssgaSpheres.

[Bram S. <br...@sa...>]

On 02/02/05 15:15:36, Bram Stolk wrote:

> I need to scale the ssgaSphere to a very strange size before I
> get results which are visually roughly correct.

Ah... I found the problem in my test program.
When using this ssg func:

int  ssgIsect ( ssgBranch *root, sgSphere*s,sgMat4 m, ssgHit =20
**results ) ;

the relative position of intersector and intersectee can be
in either the inverse mat for the root, or in the 'center'
member data of the sphere.

I had put the sphere pos both in the inverse-math *and* in
the sphere itself -> incorrect results.

   bram

[Plib-devel] Linux joystick problem with fix.

[Mathias <Mat...@gm...>]

Hi all,

I have found a problem with joysticks on linux with more than 16 axes.
Having such a joystick will crash the program.

In fact I have introduced that problem with a prevous patch, so here is the=
=20
proper fix.

Please apply!

         Thanks

                Mathias

=2D-=20
Mathias Fr=C3=B6hlich, email: Mat...@gm...

Re: [Plib-devel] RE: FlightGears puList code

[Slowhand_47 <slo...@gm...>]

Am Thu, 03 Feb 2005 18:55:38 +0100 schrieb Erik Hofman <er...@eh...>:

> I would not oppose to a different solution. In fact prior to sending it 
> to John I checked whether plib has already included such a widget. If a 
> different type gets included I will update FlightGear to use that one 
> instead.

It should still be compatible with FG, at least with the 0.9.6
sources from where I took the puList. I removed the underlying
frame, because we use transparency and the extra frame stops the
background from shining through. But the original puList API
should still work, I only added the missing methods from the
puListBox API.

Kind regards,
Jan

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] RE: FlightGears puList code

[Erik H. <er...@eh...>]

Slowhand_47 wrote:

> when we added a pui GUI to crrcsim, we also adopted the puList
> from FG. I was quite unsatisfied with its general behaviour as
> it didn't inherit the puListBox API which led to some strange
> behaviour when I tried to use some of the getXXXValue() methods.
> If you add the puList to puAux it would make sense to get
> an API similar to a non-scrolling list box. I'll send you an
> email with my changes, maybe you can use something of it.

I would not oppose to a different solution. In fact prior to sending it 
to John I checked whether plib has already included such a widget. If a 
different type gets included I will update FlightGear to use that one 
instead.

Erik

Re: [Plib-devel] RE: FlightGears puList code

[Slowhand_47 <slo...@gm...>]

Am Thu, 3 Feb 2005 06:16:09 -0600 schrieb Fay John F Contr AAC/WMG <joh...@eg...>:

> Erik,
> 
> 	Please excuse the delay in getting back to you.  I haven't been able
> to look at the "puList" code yet but I will.  On principle I don't see
> anything wrong with adding it to "puAux".

John,

when we added a pui GUI to crrcsim, we also adopted the puList
from FG. I was quite unsatisfied with its general behaviour as
it didn't inherit the puListBox API which led to some strange
behaviour when I tried to use some of the getXXXValue() methods.
If you add the puList to puAux it would make sense to get
an API similar to a non-scrolling list box. I'll send you an
email with my changes, maybe you can use something of it.

Kind regards,
Jan

-- 
Jan Reucker
email: jan dot reucker at web dot de
web:   http://www.reucker-online.de

Re: [Plib-devel] specular exponent in 3ds files

[Bram S. <br...@sa...>]

Steve Baker wrote:

> I guess the question is: "What does the real 3D Studio do when
> presented with one of these files?"

3DStudio Max shows the model without specular.
I will add the test to plib's 3ds loader.

    Bram

Re: [Plib-devel] ssgaSpheres?

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

Nick wrote:

>Thanks for the explanation Steve - that clears my issue up.

Indeed.=20
Taking the BBox of a sphere and then the BSphere of it will lead to a
factor of sqrt( 3 ) which is quite accurately what you observe.

Bye bye,
Wolfram.

[Plib-devel] PUI/puAux Class Notes

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

Gentlemen,

	In putting Erik Hofmann's "puList" code into my private copy of
"puAux", I have come upon a couple of issues having to do with PUI classes.
I would appreciate any guidance anybody could give.

(1) With the new class, the total number of classes in PUI and puAux is now
30.  The bitmap that defines what class (puValue::type) has 32 bits; thus we
have space for exactly two more types of widget.  While this is not an
emergency yet, I can see it turning into one.  What should we do about it?
I see two alternatives:
	- Adopt SSG's style of typing.  This, I think, assigns the same bit
to two different classes if their parent classes differ.  Each class thus
has a unique bit pattern but not a unique bit.
	- Increase the number of bits available.  There is a non-portable
64-bit integer type, but the "P" in PLIB makes this a nonstarter.  The
alternative is to define a structure or an array, making the "getType" more
complicated.

(2) "puValue" in PUI has a "getTypeString" function that prints out the name
of the PUI class.  Is there a way to extend this to print out puAux class
names?  One could define a function pointer, initialize it to null in PUI,
and set it to point to a function in puAux in each constructor method in
puAux, but this strikes me as being extremely ugly.  Does anybody have an
alternative?

John F. Fay
joh...@eg...
850-729-6330 

[Plib-devel] RE: FlightGears puList code

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

Erik,

	Please excuse the delay in getting back to you.  I haven't been able
to look at the "puList" code yet but I will.  On principle I don't see
anything wrong with adding it to "puAux".

John F. Fay
joh...@eg...
850-729-6330 
-----Original Message-----
From: Erik Hofman [mailto:er...@eh...] 
Sent: Monday, January 31, 2005 4:23 AM
To: Fay John F Contr AAC/WMG
Subject: FlightGears puList code



Hi John,

FlightGear has been shipped with a puList (a scrolling PUI list box) for 
ages ans we have hit a problem recently:

Melchior FRANZ -- Wednesday 22 December 2004 15:10:
 > getString is only made virtual in puList() and AirportList(), but it's
 > not virtual in puObject. copy_from_pui(), however, uses the
 > getStringValue() method on a puObject, assuming that it will get
 > AirportList()'s. Of course, this doesn't work and puValue()'s is used
 > instead. One would have to make getStringValue virtual in puObject()
 > or puValue() to make this work.

Someone has provided a workaround for it but it depends on a define that 
might be used in the future:

Andrew Midson wrote:
> I have some concerns about the
> solution, which could be broken by changes to plib (if
> they re-use the value I have assigned to
> PUCLASS_LIST), but for the moment it seems to work OK.

Now I was thinking that it might be a good idea to add this code the 
puAux and get it settled from now on. Unless you can point me to another 
PUI list pox widget, would you be so kind to add this to puAux?

Erik

Re: [Plib-devel] specular exponent in 3ds files

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

Bram Stolk wrote:

> Wings3d, an excellent 3d modeling application, can export to 3ds.
> If I read the 3ds file into plib, specular lighting is horrible.
> 
> This is caused by the fact that GL_SPECULAR is set to 1,1,1,1
> whereas GL_SHININESS is the OpenGL default 0.0
> This gives ugly results.
> 
> I think that the wings3d exporter is at fault here, by specifying
> the specular colour, but NOT the specular exponent. Plib's 3ds loader
> does not seem to encounter shininess data in the file.
> 
> Should this be handled in some smart way by plib, or would you
> think this is strictly a wings3d issue? For what it's worth: SGI's
> OpenGL|Performer renders 0.0 exponents for 1,1,1,1 specular without
> artefacts by presumably disabling specular light for 0.0 exponents.

Yes - it does.  That's because it was originally implemented on top
of IrisGL (the predecessor of OpenGL) - and IrisGL treats a shininess
of zero as 'no specular component whatever'.  OpenGL sets the exponent
of the specular component to the shininess value - and an exponent of
zero produces a huge shiney patch.  Performer had specific code to
'fix' the OpenGL behavior to mimic IrisGL so that existing Performer
programs would still work.

In OpenGL (and hence PLIB), the correct way to get non-shiney surfaces
is to set the material's specular colour to 0,0,0,x or the specular
light source colour to 0,0,0 - at which point, it doesn't matter
what the shininess setting is.

So - what should the 3DS loader do?   The colours and shininesses in
3DS files are not necessarily intended to have the same meaning as
OpenGL gives them - so doing something like:

   if ( shininess == 0.0f ) spec_colour = { 0,0,0 } ;

...might not be unreasonable if 3DS takes the same view of the
world that IrisGL used to take.

I guess the question is: "What does the real 3D Studio do when
presented with one of these files?"

---------------------------- 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] ssgaSpheres?

[McEVOY, N. <nic...@ba...>]

Steve wrote:
>If you follow that tortured explanation then you'll see that the bounding
>sphere for a sphere is not an exact fit for the sphere.

Thanks for the explanation Steve - that clears my issue up.

And sorry Bram, for me jumping in and confusing the issue - my problem was
obviously not the same as yours.

Cheers,
Nick

[Plib-devel] specular exponent in 3ds files

[Bram S. <br...@sa...>]

Hi,


Wings3d, an excellent 3d modeling application, can export to 3ds.
If I read the 3ds file into plib, specular lighting is horrible.

This is caused by the fact that GL_SPECULAR is set to 1,1,1,1
whereas GL_SHININESS is the OpenGL default 0.0
This gives ugly results.

I think that the wings3d exporter is at fault here, by specifying
the specular colour, but NOT the specular exponent. Plib's 3ds loader
does not seem to encounter shininess data in the file.

Should this be handled in some smart way by plib, or would you
think this is strictly a wings3d issue? For what it's worth: SGI's
OpenGL|Performer renders 0.0 exponents for 1,1,1,1 specular without
artefacts by presumably disabling specular light for 0.0 exponents.

  Bram

Re: [Plib-devel] ssgaSpheres?

[Bram S. <br...@sa...>]

On 02/02/05 18:48:47, Steve Baker wrote:

> I've added an example program for the ssgaShapes in
> examples/src/ssg/shapes

Ok thanks.
The ssgaSizes are now the same, as demonstrated by your test prog.

BTW: For me, the lighting on the teapot is really messed up. There
seems to be no shading. (only cyan ambient reflection, and a specular
reflection that seems way off). No shading (neither gouraud nor flat).
Is this the same for you?

Additionally, the mismatch with sgSphere is still there. See my
other post on the isects.

  Bram
=20

Re: [Plib-devel] ssgaSpheres?

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

Bram Stolk wrote:

> As I said, the spheres are also visually wrong.
> If you render both styles, they have different sizes.
> And both sizes are also a mismatch against a sgSphere
> with radius 1, judging from the hits I get from sgIsect()
> (although this latter problem could be a bug in my isect program).

Ah - OK.

So it looks like there is a radius/diameter screwup somewhere in
ssgaSphere.

> This is clearly wrong. Changing topology of the sphere should
> not affect size. I also expect the mismatch against sgSphere.

Indeed.

> Also, you have to make a decision on the definition of ssgaSphere
> of size 1: do you want its radius to be 1, or its diameter?

The size of all of the ssgaShape's is supposed to be the overall
size - so it *should* be the diameter.

I have committed a fix for the sphere (there was also a problem
with the colour of the teapot that needed fixing).

I've added an example program for the ssgaShapes in examples/src/ssg/shapes

 > From what I'm seeing: neither sphere style has neither radius 1 nor
> diameter 1, judging from isects with sgSphere radius 1.

I don't know about the isect results - I have not checked that.

---------------------------- 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] Sphere intersection tests, and ssgaSpheres.

[Bram S. <br...@sa...>]

Hello,

Attached is sphere_isect.cxx test program, which demonstrates the
difficulties I experience when trying to line up ssgaSpheres with
sgSpheres.

The test program shows a sphere, and a cube. If the sgSphere
intersects the cube, the sphere is rendered in red, else it is
rendered using a blue colour.

I need to scale the ssgaSphere to a very strange size before I
get results which are visually roughly correct.

  Bram

Re: [Plib-devel] ssgaSpheres?

[Bram S. <br...@sa...>]

On 02/02/05 09:30:56, Steve Baker wrote:

> If you follow that tortured explanation then you'll see that the
> bounding
> sphere for a sphere is not an exact fit for the sphere.

Steve,

This is not the problem.
As I said, the spheres are also visually wrong.
If you render both styles, they have different sizes.
And both sizes are also a mismatch against a sgSphere
with radius 1, judging from the hits I get from sgIsect()
(although this latter problem could be a bug in my isect program).

Rendering this scenegraph:

  scene    =3D new ssgRoot      ;
  balltrf0  =3D new ssgTransform ;
  balltrf1  =3D new ssgTransform ;

  ball0 =3D new ssgaSphere();
  ball1 =3D new ssgaSphere();

  ball0->setLatLongStyle(FALSE);
  ball0->setSize(1.0);
  ball0->setColour(blu);

  ball1->setLatLongStyle(TRUE);
  ball1->setSize(1.0);
  ball1->setColour(red);

  scene->addKid(balltrf0);
  scene->addKid(balltrf1);

  balltrf0->addKid(ball0);
  balltrf1->addKid(ball1);

  sgVec3 pos0=3D{-1,0,0};
  sgVec3 pos1=3D{ 1,0,0};
  balltrf0->setTransform(pos0);
  balltrf1->setTransform(pos1);

  ssgSimpleState *state =3D new ssgSimpleState();
  state->setShininess(8.0);
  ball0->setKidState(state);
  ball1->setKidState(state);

  sgCoord campos ;
  sgSetCoord ( & campos, 0.0f, -5.0f, 1.0f, 0.0, 0.0f, 0.0f ) ;
  ssgSetCamera ( & campos ) ;

Will give you the output as can be seen in attached jpeg.
This is clearly wrong. Changing topology of the sphere should
not affect size. I also expect the mismatch against sgSphere.
I have some isect test prog if you want that.

Also, you have to make a decision on the definition of ssgaSphere
of size 1: do you want its radius to be 1, or its diameter? From
what I'm seeing: neither sphere style has neither radius 1 nor
diameter 1, judging from isects with sgSphere radius 1.

   Bram

Re: [Plib-devel] ssgaSpheres?

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

McEVOY, Nick wrote:
> Bram Stolk wrote:
> <...snip...>
> 
>> bounds0: center=-0.124761,0.005011,0.317507 radius=1.860521
>> bounds1: center=0.000000,0.000000,-0.000000 radius=0.947555
>>...which looks wrong for three reasons:
>>1) radius of non latlong sphere is roughly twice as big
>>2) radii are not 1.0
>>3) center of bounding sphere for non latlong sphere is not 0,0,0
> 
> 
> I had a similar problem (and its still a problem nearly 3yrs later - I never
> had time to dig deeper into the PLIB code) - but in my case I was loading a
> sphere from AC3D (a 3D modelling tool) of radius 10 and centred at 0,0,0 -
> but when I check its bounding sphere ... getBSphere() I got bounding sphere
> radius return 17.9544 ???  And the centre of -1.27190,-0.726630,0.303701 ???

The code for computing a really tight bounding sphere around an object
is horribly, horribly expensive.

Since PLIB's bounding sphere is only used for optimising rendering, it
doesn't need to be perfect.   What it does is to compute the maximum
and minimum X, Y and Z coordinates - uses that to find the median X,
Y and Z and makes that the center of the sphere - the radius is the
smallest sphere to enclose an axially aligned box that extends from
(minX, minY, minZ) to (maxX, maxY, maxZ).

If you follow that tortured explanation then you'll see that the bounding
sphere for a sphere is not an exact fit for the sphere.

Now - to take this one step further - an ssgaSphere is more than one
ssgLeaf node.  The system has to compute the sphere around each of those
and then the sphere around those spheres.

Don't sweat it.  It's not *supposed* to be a tight fit - and it isn't.

You could try to look for a more intelligent bsphere calculating algorithm
- but unless it's REALLY efficient, we won't want it no matter how
accurate it might be.

---------------------------- 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] ssgaSpheres?

[McEVOY, N. <nic...@ba...>]

Bram Stolk wrote:
<...snip...>
>  bounds0: center=-0.124761,0.005011,0.317507 radius=1.860521
>  bounds1: center=0.000000,0.000000,-0.000000 radius=0.947555
>...which looks wrong for three reasons:
>1) radius of non latlong sphere is roughly twice as big
>2) radii are not 1.0
>3) center of bounding sphere for non latlong sphere is not 0,0,0

I had a similar problem (and its still a problem nearly 3yrs later - I never
had time to dig deeper into the PLIB code) - but in my case I was loading a
sphere from AC3D (a 3D modelling tool) of radius 10 and centred at 0,0,0 -
but when I check its bounding sphere ... getBSphere() I got bounding sphere
radius return 17.9544 ???  And the centre of -1.27190,-0.726630,0.303701 ???

See http://sourceforge.net/mailarchive/message.php?msg_id=1153817

Sorry I don't yet have a solution.  :(

Cheers,
Nick