plib-users

[Plib-users] Re: ./configure opengl problem

[McEvoy, N. <nic...@ds...>]

Steve Baker wrote:
>Well, we've never needed to add pthread to the configure linkage for anyone else (and if
>we do it, it has to be for everyone).
>What version of Mesa are you running?  Did it come with your Linux distribution?

I installed XFree86-devel (XFree86-devel-4.2.0-72 RPM for i386) off my RedHat 8.0 CD.  XFree86-devel 'provided' Mesa-devel (I'm not sure what version ... I'll get back to you on that over the weekend).    

But I notice the 'latest' RedHat RPM for Mesa-devel is 3.4.2 ... and I see a comment about 'pthread' in the changelog:
* Mon Jun 04 2001 Mike A. Harris <mh...@re...> 3.4.2-1
  - Updated to Mesa 3.4.2, and got it to build properly with XFree86 4.0.3
  - Had to disable pthreads as 3.4.2 enables pthreads by default.
  - Updated Requires XFree86 = 4.0.3


>The odd thing is that I've seen that applications that use Mesa need pthreads - and
>all of my games link to it for that very reason.
>What I don't understand is how come we never had a problem with linking the mini-applications
>that the configure script generates.  How did that ever work in the past?

Don't ask me.  :)

I'll give Sebastian's suggestion (about adding a line in configure.in) a go this weekend and let you know how it goes.  I'll leave it to you (plib-devel) guys to decide if you need to handle this Mesa pthread issue in your config scripts ... as I'm only recently an ex-windoze user I'm a bit out of my depth (at the moment).

Once I get plib installed then I can build tux-kart (oh and port my own plib game & screensaver)!  :)

Nick

Re: [Plib-users] Re: ./configure opengl problem

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

McEvoy, Nick wrote:

> So do I need to add -lpthread to the ./configure script
 > or something ???  Or should I be tracking down a version of Mesa with pthread pre-linked ?

Well, we've never needed to add pthread to the configure linkage for anyone else (and if
we do it, it has to be for everyone).

What version of Mesa are you running?  Did it come with your Linux distribution?

The odd thing is that I've seen that applications that use Mesa need pthreads - and
all of my games link to it for that very reason.

What I don't understand is how come we never had a problem with linking the mini-applications
that the configure script generates.  How did that ever work in the past?
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] ./configure opengl problem

[Sebastian U. <ud...@ha...>]

On Thu, 7 Nov 2002, nic...@ds... (McEvoy, Nick) wrote:
> Date: Thu, 7 Nov 2002 10:39:50 +1030
> To: "'pli...@li...'" 
> <pli...@li...>
> From: nic...@ds... (McEvoy, Nick)
> Reply-To: pli...@li...
> Subject: [Plib-users] ./configure opengl problem
>
> Ok so I decided to make the big switch from Windoze to Linux !  Its been
> something I've been wanting to do for ages ... so I decided to go with
> RedHat 8.0 ... well just because ... lets not get into a big discussion
> about this eh ! :)
>
> Now that I've made the switch I want to get back into my games
> development hobby with plib & ode.
>
> But I've hit a problem (already) trying to build plib-1.6.0 !

[...]

> ----- config.log (lots cut out) -----
> <...snip...>
> configure:2596: checking for glNewList in -lGL
> configure:2615: gcc -o conftest -g -O2  -I/usr/include  -L/usr/lib 
> -L/usr/X11R6/lib conftest.c -lGL    -lSM -lICE -lXi -lXmu -lXext -lX11 
> -lm 1>&5
> cc1: warning: changing search order for system directory "/usr/include"
> cc1: warning:   as it has already been specified as a non-system
> directory
> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
> glthread.o(.text+0x28): undefined reference to `pthread_key_create'

Known bug - the configure script does not link against the pthread library,
which is necessary for certain Mesa versions.

Didn't I intend to change that prior to the 1.6.0 release ? Hmm ... seems
like I did not.

Anyhow - for now, search for the following line in configure.in:

AC_CHECK_LIB(GL, glNewList)

.. and add this line prior to it:

AC_CHECK_LIB(pthread, pthread_create)


Then, while in the root of the plib source tree, run

/autogen.sh

and

/configure

(which should work flawlessly now).


- Sebastian

[Plib-users] Re: ./configure opengl problem

[McEvoy, N. <nic...@ds...>]

Steve Baker wrote:
>> ./configure --with-GL=/usr
>                ^^^^^^^^^^^^^^
>                   Why this?
>
>Does a straight "./configure" without the "--with-GL=/usr" work?

I can't quite remember what I was doing using --with-GL option !?  I think the "./configure" was failing so I started mucking around with it (I misunderstood the purpose of this option I think) ... and your right ... I don't need it (but I can't confirm this now as I'm at work).

As you point out it seems to be failing on expecting pthread linkage.


>> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
>> glthread.o(.text+0x28): undefined reference to `pthread_key_create'
>It seems to be missing Pthreads (-lpthread)
>Some versions of Mesa need it - and are not pre-linked with it...so
>OpenGL applications under Linux are recommended to link to pthreads
>even if they don't explicitly need it.
>I've never seen this be a problem with ./configure though.

So do I need to add -lpthread to the ./configure script or something ???  Or should I be tracking down a version of Mesa with pthread pre-linked ?

Thanks for your help on this.

Nick

Re: [Plib-users] ./configure opengl problem

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

McEvoy, Nick wrote:

> But I've hit a problem (already) trying to build plib-1.6.0 !
> 
> I have installed required software eg. opengl & glut3.7 ... but ./configure says "configure: error: could not find working GL library" ... whats going on ?
> 
> (nb. I installed XFree86-devel ... the RPM says it provides Mesa-devel ... I seem to have all the right libraries)
> ----- my error  -----
> ./configure --with-GL=/usr
               ^^^^^^^^^^^^^^
                  Why this?

> /usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
> glthread.o(.text+0x28): undefined reference to `pthread_key_create'

It seems to be missing Pthreads (-lpthread)

Some versions of Mesa need it - and are not pre-linked with it...so
OpenGL applications under Linux are recommended to link to pthreads
even if they don't explicitly need it.

I've never seen this be a problem with ./configure though.

Does a straight "./configure" without the "--with-GL=/usr" work?

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] ./configure opengl problem

[McEvoy, N. <nic...@ds...>]

Ok so I decided to make the big switch from Windoze to Linux !  Its been something I've been wanting to do for ages ... so I decided to go with RedHat 8.0 ... well just because ... lets not get into a big discussion about this eh ! :)

Now that I've made the switch I want to get back into my games development hobby with plib & ode.

But I've hit a problem (already) trying to build plib-1.6.0 !

I have installed required software eg. opengl & glut3.7 ... but ./configure says "configure: error: could not find working GL library" ... whats going on ?

(nb. I installed XFree86-devel ... the RPM says it provides Mesa-devel ... I seem to have all the right libraries)

----- my error  -----
./configure --with-GL=/usr
<...snip...>
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library

----- config.log (lots cut out) -----
<...snip...>
configure:2596: checking for glNewList in -lGL
configure:2615: gcc -o conftest -g -O2  -I/usr/include  -L/usr/lib  -L/usr/X11R6/lib conftest.c -lGL    -lSM -lICE -lXi -lXmu -lXext -lX11  -lm 1>&5
cc1: warning: changing search order for system directory "/usr/include"
cc1: warning:   as it has already been specified as a non-system directory
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_InitTSD':
glthread.o(.text+0x28): undefined reference to `pthread_key_create'
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_GetTSD':
glthread.o(.text+0x83): undefined reference to `pthread_getspecific'
/usr/X11R6/lib/libGL.a(glthread.o): In function `_glthread_SetTSD':
glthread.o(.text+0xc5): undefined reference to `pthread_setspecific'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2604 "configure"
<...snip...>
configure:2644: checking for glNewList in -lMesaGL
configure:2663: gcc -o conftest -g -O2  -I/usr/include  -L/usr/lib  -L/usr/X11R6/lib conftest.c -lMesaGL    -lSM -lICE -lXi -lXmu -lXext -lX11  -lm 1>&5
cc1: warning: changing search order for system directory "/usr/include"
cc1: warning:   as it has already been specified as a non-system directory
/usr/bin/ld: cannot find -lMesaGL
collect2: ld returned 1 exit status
configure: failed program was:
#line 2652 "configure"
<...snip...>
--------------------

I have the following:

/usr/include/GL/glext.h
/usr/include/GL/gl.h
/usr/include/GL/glu.h
/usr/include/GL/GLwDrawA.h
/usr/include/GL/GLwDrawAP.h
/usr/include/GL/GLwMDrawA.h
/usr/include/GL/GLwMDrawAP.h
/usr/include/GL/glx.h
/usr/include/GL/glxint.h
/usr/include/GL/glxmd.h
/usr/include/GL/glxproto.h
/usr/include/GL/glxtokens.h
/usr/include/GL/osmesa.h

/usr/lib/libGLcore.so.1
/usr/lib/libGLcore.so.1.0.3123
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.0.3123
/usr/lib/libGLU.so
/usr/lib/libGLU.so.1
/usr/lib/libglut.so.3

Any ideas ?

Nick

[Plib-users] ssgLOS operational?

[Jon <jtw...@ih...>]

I'm working on my project and I am trying to use the ssgLOS function to
detect when a 3d object is clicked on.  Unfortunately no matter what
vector I feed in to the ssgLOS function, it only seems to intersect with
objects that are directly below the players POV.  Can somebody confirm
that this function works as advertised?  Are there any example programs
that use ssgLOS?

Any help would be appreciated,
Jon W.

Re: [Plib-users] Mouse button release

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

John & Sebastian - do you guys know what the current state of this
problem is?   I've lost track.

Devil wrote:

> However, my first test program has a slider and a button. If I
> start moving the slider but release the mouse button when the
> mouse pointer is over the button, then pui generates a button
> callback even though the button was never actually pressed down.

That's a problem that we've fixed before - then broken again - then
fixed again.

> Is there a way to stop this? Is it a bug? pui should know that
> the slider is active and not consider a mouse release over the
> button as a button release.

Yep - it's a bug.  I'll forward this to the developer's list and
see if anyone knows what the current state of affairs is.

> Also if you press a button object but release the mouse button when the
> mouse pointer is off the button, the button object stays pressed. I
> think it should release the button.
> 
> Is this a bug or just a feature of pui?

It's a bug.  I've seen this in my own programs - and did kludge a
fix - but it broke something else.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

[Plib-users] Mouse button release

[Devil <dy...@io...>]

I have just started using pui. I need buttons and sliders on
my GLUT/OpenGL program and pui looks like the best option.

However, my first test program has a slider and a button. If I
start moving the slider but release the mouse button when the
mouse pointer is over the button, then pui generates a button
callback even though the button was never actually pressed down.

Is there a way to stop this? Is it a bug? pui should know that
the slider is active and not consider a mouse release over the
button as a button release.

Also if you press a button object but release the mouse button when the
mouse pointer is off the button, the button object stays pressed. I
think it should release the button.

Is this a bug or just a feature of pui?

Thanks.

Re: [Plib-users] Newbie question

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

David Megginson wrote:
> Marco Bancale writes:
> 
>  > Sure, changing the far plane was my first idea, but in that way
>  > all the objects would not be culled (by the far plane) anymore!
>  > Isn't it? So, if I have 100 spaceships around the solar system,
>  > I should see all of them... always. I think this is not much
>  > optimized :).
> 
> You can put the planets in a separate scene graph:
> 
>   ssgSetNearFar(1, 100000);
>   ssgCullAndDraw(ships_root);
>   ssgSetNearFar(1000, 100000000000000);
>   ssgCullAndDraw(planets_root);
> 
> The problem is that when the ships get close to planets or the sun,
> they might not be drawn properly (i.e. the planet will block the ship
> when it shouldn't).

That won't work...the values written into the Z buffer when rendering
the ships would be meaningless after you'd changed the near/far planes
for drawing the planets - so it would be quite possible for a planet
that's a million miles away to occlude a ship that's just one mile away.

There are some Z tricks you can play to avoid that (in principle) - but
this way isn't one of them.

You could draw the planets first, then clear the Z buffer, then draw the
ships...but then a ship would never be occluded by a planet - no matter
what.

> As long as you have only 100 ships, you can just put each one under an
> ssgRangeSelector to make sure it's not draw when it's too far away.
> With ssgRangeSelector, you can use the same near/far plane for
> everything and avoid the z-buffer strangeness.

Yes - that's the 'right' answer.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Newbie question

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

Marco Bancale wrote:

> Sure, changing the far plane was my first idea, but in that way
> all the objects would not be culled (by the far plane) anymore!

That's desirably though.

> Isn't it? So, if I have 100 spaceships around the solar system,
> I should see all of them... always. I think this is not much
> optimized :).

You should use the level-of-detail mechanism to control the
complexity of those spaceship models as a function of range.

If you make the lowest level of detail be just a single GL_POINT
and turn even that off beyond (say) 50 kilometers, you should
have exactly what you need.

> Am I wrong?

I hope so!

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Newbie question

[David M. <da...@me...>]

Marco Bancale writes:

 > Sure, changing the far plane was my first idea, but in that way
 > all the objects would not be culled (by the far plane) anymore!
 > Isn't it? So, if I have 100 spaceships around the solar system,
 > I should see all of them... always. I think this is not much
 > optimized :).

You can put the planets in a separate scene graph:

  ssgSetNearFar(1, 100000);
  ssgCullAndDraw(ships_root);
  ssgSetNearFar(1000, 100000000000000);
  ssgCullAndDraw(planets_root);

The problem is that when the ships get close to planets or the sun,
they might not be drawn properly (i.e. the planet will block the ship
when it shouldn't).

As long as you have only 100 ships, you can just put each one under an
ssgRangeSelector to make sure it's not draw when it's too far away.
With ssgRangeSelector, you can use the same near/far plane for
everything and avoid the z-buffer strangeness.


All the best,


David

-- 
David Megginson, da...@me..., http://www.megginson.com/

Re: [Plib-users] Newbie question

[Marco B. <F1...@so...>]

Steve Baker wrote:
> 
> I don't understand why you need any kind of special handling.
> 
> Just set the far clip plane out to a gazillion miles and draw
> sun and planets as appropriately sized spheres at the right
> distance.  So long as the eyepoint doesn't ever get too far
> from the origin relative to the sizes of the objects that you
> are actually interacting with, all should be well.
> 

Hi Steve!

Sure, changing the far plane was my first idea, but in that way
all the objects would not be culled (by the far plane) anymore!
Isn't it? So, if I have 100 spaceships around the solar system,
I should see all of them... always. I think this is not much
optimized :).

Am I wrong?

Thanks for the quick reply.

	Bye Bye
	Marco

Re: [Plib-users] Newbie question

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

Marco Bancale wrote:

> I started using PLIB two days ago and I'm porting my space combat
> game from the Panard Vision to PLIB because of many reasons.
> I like very much PLIB, but I can't still understand something.
> 
> Ok my big problem now is this...
> My game is a space sim, so I have to draw the Sun and the other
> planets, but they MUST NOT be culled! They must be seen from
> any distance, so no frustum has to be applied.

I don't understand why you need any kind of special handling.

Just set the far clip plane out to a gazillion miles and draw
sun and planets as appropriately sized spheres at the right
distance.  So long as the eyepoint doesn't ever get too far
from the origin relative to the sizes of the objects that you
are actually interacting with, all should be well.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] Newbie question

[Marco B. <F1...@so...>]

Hi!

I started using PLIB two days ago and I'm porting my space combat
game from the Panard Vision to PLIB because of many reasons.
I like very much PLIB, but I can't still understand something.

Ok my big problem now is this...
My game is a space sim, so I have to draw the Sun and the other
planets, but they MUST NOT be culled! They must be seen from
any distance, so no frustum has to be applied.
How do I get this effect?
I tried with ssgEntity::setTraversalMask(0) but the Sun is not
drawn at all! Have I use some callback?

Please help!

Thanks in advance!

	Bye Bye
	Marco

Re: [Plib-users] Runtime problem after switching from 1.4.2 to 1.6.0

[David L. <Dav...@no...>]

On 10/9/02 at 12:57 PM Steve Baker wrote:
>Well, firstly, this is probably (initially at least) a question for the
>FlightGear mailing list.
>
>I'd need a stack backtrace so I can see the function and linenumber where
>we were dying...I stand no chance of fixing it (even assuming it *is* a
>PLIB bug) unless I have a *TON* more information.
>

OK, thanks, I sort of figured this might be the case, and posted more in
hope than expectation.  If I manage to get a backtrace before I ditch the
card I'll post it.

Cheers - Dave 

Re: [Plib-users] Runtime problem after switching from 1.4.2 to 1.6.0

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

David Luff wrote:

> After switching from plib-1.4.2 to plib-1.6.0 Flightgear manages to render
> the spash-screen but crashes before rendering the main screen with one of
> those "instruction at ... referenced memory at... which could not be read"
> type errors on my system.  This is with an otherwise identical build of
> Flightgear on NT4sp6a with 3Dlabs Oxygen VX1 (32MB) with the very latest
> drivers.  This was compiled on Cygwin but other downloaded Flightgear
> binaries compiled on MSVC6 and MingW show exactly the same behaviour since
> the switch to 1.6.0.  Putting a few couts into Flightgear seems to indicate
> that it is dying in ssgCullAndDraw.   It will run fine in software
> rendering mode (256 colours) and if --disable-skyblend and
> --disable-random-objects are specified  (the tux example runs fine as
> well).
> 
> Does anyone have any suggestions as to whether this is likely to be a Plib
> bug or a 3Dlabs driver bug?  I realise the VX1 is pretty long in the tooth
> now and that a new Geforce at a fraction of its original cost will blow it
> away performance wise, but it still seems a shame to ditch it when
> framerates are still otherwise acceptable...

Well, firstly, this is probably (initially at least) a question for the
FlightGear mailing list.

I'd need a stack backtrace so I can see the function and linenumber where
we were dying...I stand no chance of fixing it (even assuming it *is* a
PLIB bug) unless I have a *TON* more information.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] Runtime problem after switching from 1.4.2 to 1.6.0

[David L. <Dav...@no...>]

Hi,

After switching from plib-1.4.2 to plib-1.6.0 Flightgear manages to render
the spash-screen but crashes before rendering the main screen with one of
those "instruction at ... referenced memory at... which could not be read"
type errors on my system.  This is with an otherwise identical build of
Flightgear on NT4sp6a with 3Dlabs Oxygen VX1 (32MB) with the very latest
drivers.  This was compiled on Cygwin but other downloaded Flightgear
binaries compiled on MSVC6 and MingW show exactly the same behaviour since
the switch to 1.6.0.  Putting a few couts into Flightgear seems to indicate
that it is dying in ssgCullAndDraw.   It will run fine in software
rendering mode (256 colours) and if --disable-skyblend and
--disable-random-objects are specified  (the tux example runs fine as
well).

Does anyone have any suggestions as to whether this is likely to be a Plib
bug or a 3Dlabs driver bug?  I realise the VX1 is pretty long in the tooth
now and that a new Geforce at a fraction of its original cost will blow it
away performance wise, but it still seems a shame to ditch it when
framerates are still otherwise acceptable...

Cheers - Dave 

Re: [Plib-users] bug in ssgOptimiser?

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

lo...@sl... wrote:
> hello all,
> 	In ssgOptimiser.cxx from CVS Sept. 30, at the end of the 
> OptVertexList::makeNormals function there is the following chunk of code 
> (roughly line 323):
> 
>   for ( i = 0 ; i < vnum ; i++ )
>     if ( sgScalarProductVec2 ( vlist[i]->normal, vlist[i]->normal ) < 
> 0.001 )
>       sgSetVec3 ( vlist[i]->normal, 0.0f, 0.0f, 1.0f ) ;
>     else
>       sgNormaliseVec3 ( vlist [ i ] -> normal ) ;
> 
> 
> My belief is that the call to sgScalarProductVec2 should really be a call 
> to sgScalarProductVec3.  Please correct me if I'm wrong.

I guess so - but this is somewhat cryptic code anyway.

The scalar product of a vector against itself is just the length of the
vector...so sgLengthVecN(vlist[i].normal) would be more readable here.

As to whether it should be Vec2 or Vec3, I'm not 100% certain what was
originally intended here.

If we assume the code is *WRONG* and it should be Vec3 - then this reads:

     If the normal is vastly too short and the normalise function might fail,
     then make the vector point straight up instead of maybe getting a divide
     by zero.

If we assume the code is *RIGHT* then it reads:

     If the normal's X/Y projection is very short - then make it point straight
     up.

In fact, both interpretations have the same consequences.   If the vector is
seriously de-normalised then it's X/Y projection will also be very short - so
we'll set the vector to (0,0,1) in either case.

If the vector is short in the X/Y plane - but has significant Z-direction length,
then setting it to (0,0,1) has a very similar effect to normalising it.

Hence, whilst I'm pretty sure this should be:

      if ( sgLengthVec3 ( vlist[i]->normal ) < 0.001 )

...it won't make *any* difference to any programs out there - except to slow
them down a teeny-tiny bit.

Anyway - I've fixed it and committed to CVS.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] intersection MAX_HITS limitation

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

lo...@sl... wrote:
> All of the code in PLIB that deals with intersection testing (ssgIsect, 
> ssgHOT, etc.) has a limit of returning 100 records of hit data (see 
> http://plib.sourceforge.net/ssg/non_class.html and the code, look for 
> MAX_HITS).  Was this an arbitrary limit or a technical limit?  The reason 
> I ask is because it seems to be an awfully low limit in my opinion but 
> maybe that's because I'm missing the reasoning behind it being 100.

I think it's an arbitary limit...I don't think it's awfully low - to the
contrary - it's rather unusual to actually intersect more than a handful
of triangles.  Remember this is using an infinitely thin ray and only
recording triangles that were actually intersected.  I think 100 is actually
a rather generous limit.

Still - it's only memory - so if you feel a desperate need to increase it,
please feel free.

I'd be suspicious of poor design elsewhere if there truly were more than
100 triangles in line for an intersection request.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] intersection MAX_HITS limitation

[<lo...@sl...>]

All of the code in PLIB that deals with intersection testing (ssgIsect, 
ssgHOT, etc.) has a limit of returning 100 records of hit data (see 
http://plib.sourceforge.net/ssg/non_class.html and the code, look for 
MAX_HITS).  Was this an arbitrary limit or a technical limit?  The reason 
I ask is because it seems to be an awfully low limit in my opinion but 
maybe that's because I'm missing the reasoning behind it being 100.

Thanks for any info,

Jeff Long


PGP public key at http://www.slothmud.org/~long/long.gpg

Re: [Plib-users] Selecting with mouse

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

Curtis L. Olson wrote:
> I think step one would be to get a general purpose vector/scene-graph
> intersection routine in plib.  Plib does have something that will
> intersect a z=up vector with the geometry (for use in finding ground
> height in a z=up game.)  But, there needs to be a more general purpose
> routine that can find intersections with any arbitrary vector.

This shouldn't be too terribly difficult.  The mouse vector can be
gotten from the modelview/projection matrices.  Either invert them
yourself or use gluUnproject().  Transform the near and far plane and
you'll get two world-space points to define your line.

Then recurse into the scene graph, testing the bounding sphere's
against the line*.  When you find a leaf whose sphere matches, test
each triangle** for intersection.  If the bounding spheres are sane,
it works in log time in the geometry complexity.

And I agree -- vector intersection should be a core plib feature.  The
landing gear code wants it too.

Andy

* This test is pretty easy -- just project the sphere centroid onto
  any 2D space perpendicular to the line and take the 2D distance
  along the plane.  That sounds harder than it is: pick any vector and
  cross it with the line direction to get a perpendicular vector.
  Cross that with the line again and normalize all three.  These three
  vectors are the columns of your rotation matrix.  Just run any
  vector from the line to the sphere centroid through this matrix, and
  ignore the coordinate along the line direction.  The remaining 2D
  distance is the distance to the line.

** This one is harder.  I'd have to look it up.  You could do it with
   the projection above -- the problem then becomes a 2D point-in-polygon
   test, which is reasonably easy.  There might be a better way, though.

-- 
Andrew J. Ross                NextBus Information Systems
Senior Software Engineer      Emeryville, CA
an...@ne...              http://www.nextbus.com
"Men go crazy in conflagrations.  They only get better one by one."
 - Sting (misquoted)

[Plib-users] bug in ssgOptimiser?

[<lo...@sl...>]

hello all,
	In ssgOptimiser.cxx from CVS Sept. 30, at the end of the 
OptVertexList::makeNormals function there is the following chunk of code 
(roughly line 323):

  for ( i = 0 ; i < vnum ; i++ )
    if ( sgScalarProductVec2 ( vlist[i]->normal, vlist[i]->normal ) < 
0.001 )
      sgSetVec3 ( vlist[i]->normal, 0.0f, 0.0f, 1.0f ) ;
    else
      sgNormaliseVec3 ( vlist [ i ] -> normal ) ;


My belief is that the call to sgScalarProductVec2 should really be a call 
to sgScalarProductVec3.  Please correct me if I'm wrong.

Thanks,

Jeff Long


PGP public key at http://www.slothmud.org/~long/long.gpg

Re: [Plib-users] Selecting with mouse

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

David Megginson wrote:
> Steve Baker writes:
> 
>  > Whilst I agree that this is useful - for selection, it's better to use
>  > the OpenGL mechanism because it allows you to select within a rubber-banded
>  > region - and it stands a good chance of being hardware accellerated.
> 
> How would you map from the OpenGL hits back to the scene graph,
> without doing a depth-first search of the whole thing?

My recollection of how it worked with PPE is that I built a table
of OpenGL "name" tags versus SSG node addresses while descending
the scene graph for cull/draw and then when I retrieve the name tags
from the OpenGL pick function, it's a simple lookup table to get
directly to the SSG node.

What vastly complicated PPE was that we needed to be able to pick
each vertex and each edge.  I don't recall how that was done.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] Selecting with mouse

[David M. <da...@me...>]

Steve Baker writes:

 > Whilst I agree that this is useful - for selection, it's better to use
 > the OpenGL mechanism because it allows you to select within a rubber-banded
 > region - and it stands a good chance of being hardware accellerated.

How would you map from the OpenGL hits back to the scene graph,
without doing a depth-first search of the whole thing?


All the best,


David

-- 
David Megginson, da...@me..., http://www.megginson.com/