plib-users

Re: [Plib-users] Possible memory leak in ssgLoadSGI.cxx

[Jan R. <slo...@gm...>]

Am Thu, 25 May 2006 19:51:49 -0500 schrieb "Tyler Ohlsen"
<tyl...@gm...>:

> In the ssgSGIHeader::openFile function, the member variable rle_temp is
> allocated.  This is not cleaned up anywhere.  I added the following to the
> ssgSGIHeader deconstructor and my app seems to still run ok.
> 
>   if (rle_temp != NULL)
>     delete [] rle_temp;

Hello Tyler,

this issue should already be fixed in the CVS HEAD. I submitted a patch
containing the same solution on April 14, and it was applied April 16:

http://sourceforge.net/mailarchive/forum.php?thread_id=10175926&forum_id=4479

Maybe anonymous CVS is still not in sync with devel CVS?!?

Kind regards,
Jan R.

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

[Plib-users] Possible memory leak in ssgLoadSGI.cxx

[Tyler O. <tyl...@gm...>]

In the ssgSGIHeader::openFile function, the member variable rle_temp is
allocated.  This is not cleaned up anywhere.  I added the following to the
ssgSGIHeader deconstructor and my app seems to still run ok.

  if (rle_temp !=3D NULL)
    delete [] rle_temp;


--=20
Tyler Ohlsen
Tyl...@gm...

[Plib-users] PLIB and C#???

[Tinoshi K. <ti...@li...>]

Hi everybody!

I'm developing some OpenGL application that requires a C# User Interface 
(Windows Form etc...). The application has three windows used to display 
OpenGL things... To make OpenGL work I've just wrapped the .dll within a C# 
class using PInvoke... and that's easy... Now I'd like to use PLIB... Do you 
think it is possible? I mean, which is the shorter way to 'wrap' PLIB so 
that I can use them in a C# application? Do I have to create a .dll for each 
.lib and do the same wrapping thing that I did with gl.dll??? Is there 
another way??? I think that it is a quite hard thing to do... probably the 
easiest way would be to modify the source code to make it suitable for C# 
(and managed) and re-compile it... but I think that it will take years! :-P
Thank you for any suggestion!!! 

RE: [Plib-users] (no subject)

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Seware,

	I must admit that I have no idea.  Does the operating system support
OpenGL?  Which parts of PLIB do you want to use?  Will PW satisfy your
needs, or will you need something a little stronger like "freeglut"?

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
 
-----Original Message-----
From: pli...@li...
[mailto:pli...@li...] On Behalf Of se...@ju...
Sent: Sunday, April 30, 2006 4:37 PM
To: pli...@li...
Subject: [Plib-users] (no subject)

I'm looking for a good toolset to do some OpenGL work on an embedded
platform (PPC) using the GreenHills Integrity OS. How difficult would it be
to get PLIB working in this environent? Thanks all.


________________________________________________________________________
Try Juno Platinum for Free! Then, only $9.95/month!
Unlimited Internet Access with 1GB of Email Storage.
Visit http://www.juno.com/value to sign up today!




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] (no subject)

[<se...@ju...>]

I'm looking for a good toolset to do some OpenGL work on an embedded pla=
tform (PPC) using the GreenHills Integrity OS. How difficult would it be=
 to get PLIB working in this environent? Thanks all.


________________________________________________________________________=

Try Juno Platinum for Free! Then, only $9.95/month!
Unlimited Internet Access with 1GB of Email Storage.
Visit http://www.juno.com/value to sign up today!

Re: [Plib-users] Problem with Plib and Dev-C++

[<coz...@gm...>]

Hello Ricardo,

Well I have to develop a small software using OpenGL, and the IDE is Dev C+=
+
> v.4.9.9.2, O.S.=3DWinXP. Soon I realized I needed to use some kind of inp=
ut
> textfield to save/load files. That is how I discovered PLIB, downloaded
> plib-1.8.4 and set the files like this (I only need the PUI):
>
[..]

> Do I have the files (.h and .lib) in the right directories? Am I linking
> the libraries the right way ? What Am I missing or doing wrong? Thanks in
> advance.
>

The downlod from the plib site is the source code of the libraries, not the
libraries compiled themselves. An easy way of doing it is installing Cygwin
and following the instructions, but I have compiled plib by installing M-SY=
S
with Mingw too.

After you do that in the examples either the makefile.in or the
makefile.amin the pui directory will tell you what libraries you need
to include for
pui programs.

-Coz

Re: [Plib-users] Problem with Plib and Dev-C++

[Jan R. <slo...@gm...>]

Am Wed, 26 Apr 2006 13:51:44 -0700 (PDT) schrieb ricardo x <rva...@ya...>:

> On project option's parameter I'm linking the following libraries:
> -lopengl32 -lglu32 -lglut32 -lpui
> (I've even tryed adding Library or Object option and it doesn't not work)
> 
> After all this I keep on having several linker errors (22)
>   [Linker error] undefined reference to `puSetDefaultStyle(int)'
>   [Linker error] undefined reference to `puSetDefaultColourScheme(float, float, float, float)'
>   [Linker error] undefined reference to `puDisplay()'

Hello Ricardo,

it's not a problem of Dev-C++ but of the mingw gcc port. The linker is
a bit picky about library order. You have to specify each library
*left* of any library that it depends on. PUI depends on libopengl32,
so the following order should work:

-lpui -lopengl32 -lglu32 -lglut32

In general there shouldn't be a problem with PLIB and Dev-C++. I'm also
using it for a big software project with several addon libraries and
the following library order:

-L"C:/DEV-CPP/lib" -lplibssg -lplibsg -lplibpu -lplibfnt -lplibul
-mwindows -lmingw32 -lSDLmain -lSDL -lgle -lglu32 -lglut32 -lopengl32
-lportaudio -lwinmm

I guess you also need -lplibfnt somewhere between -lplibpu and
-lopengl32 because PUI depends on it.

Kind regards,
Jan R.

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

Re: [Plib-users] Lost and buffered key events

[Joerg H. <jo...@lu...>]

Hi all,

I solved at least one problem, and thought it might be useful for others 
to have the solution:

[...]
> 2) I noticed as well that some of my menus are very slow to react.
>    After some searching I again printed the events inside the event
>    loop of pwX11.
>    While my application updates the frames roughly every 0.03 seconds,
>    sometimes events get not delivered at once, but are delayed, and
>    after some time suddenly all events get delivered in the same call to
>    the event handler, e.g. I press and release 'down', 'down',
>    'up'. I get the event:
>     press 'down'
>    The nothing for 'some time', while I release
>    the key, press 'down' again, release 'down', press 'up'.
>    Then suddenly there are three events reported in the event loop.

It turns out that the main reason was a big background texture 
(512x512). When the texture was disabled, everything was fine. But even 
a small texture (16x16) scaled up on the 800x600 screen would show the 
slow down.

So I guess that the X server appeared to be overloaded, since the 
texture was drawn too quickly/often - and as a result of this (again: I 
guess) keyboard events were buffered.

As a first solution, I then used some kind of 'lazy update' - only 
drawing the background picture if anything was changed on the screen. 
This worked fine, but is quite a bit of implementation work. The much 
easier solution: I added a small delay (usleep(2000)) before drawing the 
background texture, and everything is fine now - this delay is not 
noticeable for the user.

On a side note: this solution improved another user's problem of having 
a delay when going from one screen to the next as well.

Best regards,
     Joerg

-- 
----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

[Plib-users] Problem with Plib and Dev-C++

[ricardo x <rva...@ya...>]

Hello, this is my first post here.
Well I have to develop a small software using OpenGL, and the IDE is Dev C++ v.4.9.9.2, O.S.=WinXP. Soon I realized I needed to use some kind of input textfield to save/load files. That is how I discovered PLIB, downloaded plib-1.8.4 and set the files like this (I only need the PUI):

*Under C:\Dev-Cpp\include\PLIB :pu.h, puFLTK.h, puGLUT.h, puLocal.h, puNative.h, puPW.h, puSDL.h

*Under C:\Dev-Cpp\lib : pui.h

On project option's parameter I'm linking the following libraries:
-lopengl32 -lglu32 -lglut32 -lpui
(I've even tryed adding Library or Object option and it doesn't not work)

After all this I keep on having several linker errors (22)
  [Linker error] undefined reference to `puSetDefaultStyle(int)'
  [Linker error] undefined reference to `puSetDefaultColourScheme(float, float, float, float)'
  [Linker error] undefined reference to `puDisplay()'
....
Do I have the files (.h and .lib) in the right directories? Am I linking the libraries the right way ? What Am I missing or doing wrong? Thanks in advance.
			
---------------------------------
Celebrate Earth Day everyday!  Discover 10 things you can do to help slow climate change. Yahoo! Earth Day

[Plib-users] compiling FG in mac os

[Hemalatha S. <hem...@re...>]

Hi,=0AWe are trying to compile flightgear0.9.4 in mac os.=0AWe have compile=
d successfully plib and simgear. While compiling FlightGear we are getting =
following error :=0A=0A/users/apple/fgdev/include/simgear/threads/SGQueue.h=
xx: In member function 'virtual T SGBlockingQueue<T>::pop()':=0A/users/appl=
e/fgdev/include/simgear/threads/SGQueue.hxx:214: error: 'fifo' was not decl=
ared in this scope=0A=0Afifo is declared =0AIn SGQueue.hxx=0A=0A#include <q=
ueue>=0A=0A */=0Atemplate<class T>=0Aclass SGQueue=0A{=0Apublic:=0A    SGQu=
eue() {}=0A    virtual ~SGQueue() {}=0A=0A      protected:=0A      std::que=
ue<T> fifo;=0A};=0A=0A=0Awhat is the solution for the following above probl=
em.=0APlz reply me=0A=0A=0ARegards,=0AHema=0A

[Plib-users] RE: puComboBox query

[_ t. <the...@ho...>]

<html><div style='background-color:'><P>Thanks for your reply John,</P>
<P>As it turns out the puComboBox was displaying the contents upwards as a result of its position within the puGroup rather than its position relative to the entire window. Resetting the 'y' position values of both the puGroup and puComboBox's reset the puArrowButton to be defaulted to pointing downwards. Thanks for your help.</P>
<P>Stephen<BR><BR></P>
<BLOCKQUOTE style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #a0c6e5 2px solid; MARGIN-RIGHT: 0px"><FONT style="FONT-SIZE: 11px; FONT-FAMILY: tahoma,sans-serif">
<HR color=#a0c6e5 SIZE=1>
<BR><BR>
<DIV>
<DIV class=RTE>Stephen,<BR> <BR>&nbsp;&nbsp;&nbsp; I don't have the details at my fingertips, but I think I remember that<BR>the arrow direction is dictated by the relative position and size of the box<BR>in the window.&nbsp; By default it drops down, but if it is so close to the<BR>bottom of the window that it would drop outside the bottom of the window it<BR>"drops" up.&nbsp; Is that what is going on?<BR> <BR>&nbsp;&nbsp;&nbsp; Possibly a better solution would be to have the box drop down no farther<BR>than the bottom of the window and then extend up as far as is necessary.<BR>Let me know if that's necessary.<BR> <BR><BR>John F. Fay<BR>Technical Fellow, Jacobs/Sverdrup TEAS Group<BR>850-729-6330<BR>joh...@eg...<BR></FONT></DIV></DIV></BLOCKQUOTE></div></html>

RE: [Plib-users] puComboBox query

[Fay J. F Dr C. U. AFSEO/SK <joh...@eg...>]

Stephen,
 
    I don't have the details at my fingertips, but I think I remember that
the arrow direction is dictated by the relative position and size of the box
in the window.  By default it drops down, but if it is so close to the
bottom of the window that it would drop outside the bottom of the window it
"drops" up.  Is that what is going on?
 
    Possibly a better solution would be to have the box drop down no farther
than the bottom of the window and then extend up as far as is necessary.
Let me know if that's necessary.
 

John F. Fay
Technical Fellow, Jacobs/Sverdrup TEAS Group
850-729-6330
joh...@eg...
  

 

  _____  

From: pli...@li...
[mailto:pli...@li...] On Behalf Of _
thethirdgentleman
Sent: Wednesday, March 15, 2006 1:42 PM
To: pli...@li...
Subject: [Plib-users] puComboBox query


Hi, 
 
I was wondering if it was possible to specify the direction of the
puArrowButton in this class. Currently, I have employed several Combo boxes
to a puGroup and the items held in each are going outside the window as the
list is going upwards. I need to have this as a drop 'down' list.
 
I'd appreciate any assistance on this matter as I cannot seem to come up
with a solution. 
 
PUI version 1.128
Latest OpenGL libraries in the MS Visual C++ 6.0 environment
 
Thanks
Stephen
------------------------------------------------------- This SF.Net email is
sponsored by xPML, a groundbreaking scripting language that extends
applications into web and mobile media. Attend the live webcast and join the
prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________ plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] puComboBox query

[_ t. <the...@ho...>]

<html><div style='background-color:'><DIV class=RTE>Hi, </DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I was wondering if it was possible to specify the direction of the puArrowButton in this class. Currently, I have employed several Combo boxes to a puGroup and the items held in each are going outside the window as the list is going upwards. I need to have this as a drop 'down' list.</DIV>
<DIV class=RTE>&nbsp;</DIV>
<DIV class=RTE>I'd appreciate any assistance on this matter as I cannot seem to come up with a solution. </DIV>
<DIV class=RTE><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"></SPAN></FONT>&nbsp;</DIV>
<DIV class=RTE><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">PUI version 1.128<BR></SPAN></FONT><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Latest OpenGL libraries in the MS Visual C++ 6.0 environment</SPAN></FONT></DIV>
<DIV class=RTE><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'"></SPAN></FONT>&nbsp;</DIV>
<DIV class=RTE><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Thanks</SPAN></FONT></DIV>
<DIV class=RTE><FONT face="Courier New" size=2><SPAN lang=EN-GB style="FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'">Stephen</SPAN></FONT></DIV></div></html>

[Plib-users] Lost and buffered key events

[Joerg H. <jo...@lu...>]

Hi all,

I have a problem with plib/pw: it appears that sometimes key events get 
lost, or are buffered - I guess those issues are related:

1) immediately after starting my plib test program, I press 'up',
    and after a few seconds (without releasing arrow up) pressing
    'left'. Often (though not always) there will be no 'left'
    event recognised by pw.
    Once I release the left key, and press it again, everything works
    fine (just for the record: I don't press more than these two keys,
    so I don't think that this is related to dead keys when pressing
    four keys).
    I printed the events inside pwX11, and:
    - sometimes no key event at all gets delivered for the first
      time I press and release 'left'
    - sometimes I only get a "key release" event, without any previous
      "key press" event for the 'left' key.

2) I noticed as well that some of my menus are very slow to react.
    After some searching I again printed the events inside the event
    loop of pwX11.
    While my application updates the frames roughly every 0.03 seconds,
    sometimes events get not delivered at once, but are delayed, and
    after some time suddenly all events get delivered in the same call to
    the event handler, e.g. I press and release 'down', 'down',
    'up'. I get the event:
     press 'down'
    The nothing for 'some time', while I release
    the key, press 'down' again, release 'down', press 'up'.
    Then suddenly there are three events reported in the event loop.

Now, I was convinced that this was an error in my application, but after 
some tests I noticed that the original tuxkart sometimes (though not as 
common as my test program) has the same problem: the kart does not turn 
left (or right) the first time I press left while accelerating (tuxkart 
version: 0.40)..

My system:
centrino laptop (intel, 1.5GHZ)., with Linux suse 10.0, plib-1.8.4-6;
Xfree 6.8.2, kernel: 2.6.13-15.
I tested the  latest plib cvs version as well - same problem.

I had the same issues on an Intel 64 bit desktop (with similar suse 10.0 
64 bit installation), but on an AMD 64 bit dual core (same suse 
installation) I don't see this problem.

Any ideas what might be responsible for this? And how to avoid it?

Any help and hints would be appreciated!

Best regards,
    Joerg


-- 
----------------------------------------------------------------
Joerg Henrichs
Luding Administration
e-mail: jo...@lu...
URL:    http://luding.org

[Plib-users] correct texture mapping for loaded models / problems with AC3d models/loader

[Jakob G. <pi...@st...>]

 I've been trying to use (rather simple) texture mapping with SSG,
 for objects created in AC3D 5.0.21 (a modeller whose no-nonsense interface
I
 like).
    However, the textures come up all skewed when I display the objects
 with SSG, and not at all the way they look in AC3D.
 http://home1.stofanet.dk/pilgrim/withSSG.jpg
 http://home1.stofanet.dk/pilgrim/withAc3d.jpg
    Even when I cut it down to the most primitive - a rectangle - the
texture looks weird, no matter if the rectangle is x, y or z aligned.
 But it's not just flat polygons that fail - I get same problem with e.g. a
box.

 I wonder if this is a known problem between SSG and Ac3d, or if I'm doing
 something "known" wrong?

 Also, I would like to hear suggestions of which formats/editors are good
candidates
 for doing (correctly texturemapped) 3d objects for SSG. I am aware of this
table
 http://plib.sourceforge.net/ssg/non_class.html
 - but this table also lists textures as supposed to be working with Ac3d,
 so I'd like to know beforehand before I buy the next 3d editor...

 I was thinking of using PrettyPoly instead, but it either refused to load
my models
 and/or crashed on me without any dying message, so I guess it's not yet
ready
 for prime time (?).

R: [Plib-users] ssg camera woes / tranformation/coordsystem confusion

[Paolo L. <p.l...@ci...>]

> -----Messaggio originale-----
> Da: pli...@li...
[mailto:pli...@li...]=20
> Per conto di Eduardo Alberto Hern=E1ndez Mu=F1oz
> Inviato: domenica 12 febbraio 2006 21.49
> A: pli...@li...
> Oggetto: Re: [Plib-users] ssg camera woes / tranformation/coordsystem
confusion
>=20
>=20
> > Hi. I have some pre-SSG/own code, I'm trying to migrate to SSG.=20
> > However, my camera code screws up; it's as if the axes are switched, =
or
> > worse.
> >=20
> > For example, my code has a direction/rotation matrix, that indicates
> > the users' rotation around the y axis (it could be a rotation angle
instead,=20
> > but I'm exploiting that it's a matrix).
> >=20
> > However, when I multiply this matrix onto the ssg camera, it rotates
around
> > the _Z_ axis instead!
> >   Similar problems happen with other parts of the transform (which =
I've=20
> > commented out to dissect the problem).
>=20
>=20
> This is a quote from a page at Steve Baker's tuxkart site at
> http://tuxkart.sourceforge.net/trackdesign.html :
>=20
> "I come from a flight-simulation background where we use the =
convention
that Z-is-up - so all my
> software works like that. However, the PLIB loaders know that some
modellers use Y-is-up and do
>  the axis swap as needed. Hence, in AC3D, Y-is-up - but in the game, =
your
models will be converted
> to Z-is-up. If you find this confusing, forget I mentioned it - =
everything
comes out OK automagically."
>=20
> So I would beleive the Z axis is the Y axis are swapped in plib, so =
just
swapping these values when you
> load models and in your coordinate handling code would do the trick.
>=20
> -Coz

To be more precise, the matrix used for such SSG to OpenGL coordinate
adaption can be found in ssg.cxx:

sgMat4 _ssgOpenGLAxisSwapMatrix =3D
{
  {  1.0f,  0.0f,  0.0f,  0.0f },
  {  0.0f,  0.0f, -1.0f,  0.0f },
  {  0.0f,  1.0f,  0.0f,  0.0f },
  {  0.0f,  0.0f,  0.0f,  1.0f }
} ;

This actually describes a 90=B0 rotation around the x-axis, in such a =
way that
SSG is "z+ is up, y+ points towards the observer", OpenGL is "y+ is up, =
z+
points inside the screen" (I think it's the same handness).

Greetings -

Paolo Leoncini

Re: [Plib-users] ssg camera woes / tranformation/coordsystem confusion

[Jakob G. <pi...@st...>]

Thank you very very much!
   This was the only thing I hadn't considered...
Considering the totally different directions I was looking for the =
problem in,
you've saved me very much frustration...
  ----- Original Message -----=20
  From: Eduardo Alberto Hern=E1ndez Mu=F1oz=20
  To: pli...@li...=20
  Sent: Sunday, February 12, 2006 9:48 PM
  Subject: Re: [Plib-users] ssg camera woes / tranformation/coordsystem =
confusion


    Hi. I have some pre-SSG/own code, I'm trying to migrate to SSG.=20
    However, my camera code screws up; it's as if the axes are switched, =
or
    worse.

    For example, my code has a direction/rotation matrix, that indicates
    the users' rotation around the y axis (it could be a rotation angle =
instead,=20
    but I'm exploiting that it's a matrix).

    However, when I multiply this matrix onto the ssg camera, it rotates =
around
    the _Z_ axis instead!
      Similar problems happen with other parts of the transform (which =
I've=20
    commented out to dissect the problem).


  This is a quote from a page at Steve Baker's tuxkart site at =
http://tuxkart.sourceforge.net/trackdesign.html :

  "I come from a flight-simulation background where we use the =
convention that Z-is-up - so all my software works like that. However, =
the PLIB loaders know that some modellers use Y-is-up and do the axis =
swap as needed. Hence, in AC3D, Y-is-up - but in the game, your models =
will be converted to Z-is-up. If you find this confusing, forget I =
mentioned it - everything comes out OK automagically."

  So I would beleive the Z axis is the Y axis are swapped in plib, so =
just swapping these values when you load models and in your coordinate =
handling code would do the trick.

  -Coz



-------------------------------------------------------------------------=
-----


  No virus found in this incoming message.
  Checked by AVG Free Edition.
  Version: 7.1.375 / Virus Database: 267.15.6/257 - Release Date: =
10/02/2006

Re: [Plib-users] ssg camera woes / tranformation/coordsystem confusion

[<coz...@gm...>]

>
> Hi. I have some pre-SSG/own code, I'm trying to migrate to SSG.
> However, my camera code screws up; it's as if the axes are switched, or
> worse.
>
> For example, my code has a direction/rotation matrix, that indicates
> the users' rotation around the y axis (it could be a rotation angle
> instead,
> but I'm exploiting that it's a matrix).
>
> However, when I multiply this matrix onto the ssg camera, it rotates
> around
> the _Z_ axis instead!
>   Similar problems happen with other parts of the transform (which I've
> commented out to dissect the problem).


This is a quote from a page at Steve Baker's tuxkart site at
http://tuxkart.sourceforge.net/trackdesign.html :

"I come from a flight-simulation background where we use the convention tha=
t
Z-is-up - so all my software works like that. However, the PLIB loaders kno=
w
that some modellers use Y-is-up and do the axis swap as needed. Hence, in
AC3D, Y-is-up - but in the game, your models will be converted to Z-is-up.
If you find this confusing, forget I mentioned it - everything comes out OK
automagically."

So I would beleive the Z axis is the Y axis are swapped in plib, so just
swapping these values when you load models and in your coordinate handling
code would do the trick.

-Coz

[Plib-users] ssg camera woes / tranformation/coordsystem confusion

[Jakob G. <pi...@st...>]

 Hi. I have some pre-SSG/own code, I'm trying to migrate to SSG.
However, my camera code screws up; it's as if the axes are switched, or
worse.

For example, my code has a direction/rotation matrix, that indicates
the users' rotation around the y axis (it could be a rotation angle instead,
but I'm exploiting that it's a matrix).

However, when I multiply this matrix onto the ssg camera, it rotates around
the _Z_ axis instead!
  Similar problems happen with other parts of the transform (which I've
commented out to dissect the problem).

I wonder if it's a left/righthand coordsys screwup, or maybe that I get the
perspective configured wrongly...

Here snippets from the code that I hope include enough info to illustrate
what I'm doing:

// this updates the direction rotate-matrix that at least has worked OK
"until SSG":
...
      case GLUT_KEY_LEFT:  direction.Rotate(-rotateStep, 0,1,0); break;
      case GLUT_KEY_RIGHT: direction.Rotate( rotateStep, 0,1,0); break;
...

// this how I try to apply my camera for SSG:

  virtual void cameraForSSG(sgMat4& mat) {
    sgMakeIdentMat4(mat);
    sgPostMultMat4(mat, direction.a);
    ... (+ more similar code currently commented out to isolate the problem.
  }



And finally, the render code context it's called from.
Note that this first does non-SSG render, but that... shouldn't be a
problem, as far as I understand?
(the whole point of the exercise is to gradually move all the non-ssg code
to ssg... So
I like to let the non-ssg code do its thing until I know a given part works
well with ssg).

  virtual void renderHandler() { // draw/callback function.
    glClear(GL_COLOR_BUFFER_BIT   | GL_DEPTH_BUFFER_BIT);
    // reset modelview matrix
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    nav->renderSetCamera();
    data.world.RenderMe();

    // now render ssg
    glLoadIdentity(); // not really necessary, but not dangerous either?
    sgMat4 cameraMat;
    nav->cameraForSSG(cameraMat);
    ssgSetCamera(cameraMat);
    ssgCullAndDraw(my_ssgScene);  // and here/now it's all wrong...

    glutSwapBuffers();  // necessary change for double buffer mode.
}




One of the things I wondered might be a problem, could be that maybe I don't
succeed in configuring
the non-ssg frustrum and the ssg frustrum the same way.
   The non-ssg frustrum I set with gluPerspective().
The ssg frustrum I set this way:

class FrustumArgs {
public:
  GLfloat top,bottom,left,right,znear,zfar;

  FrustumArgs() {
    top=bottom=left=right=znear=zfar= 0.0;
  }

  void calcFromPerspective(
    GLfloat vFovDeg, // 60.0f, // vertical fov
    GLfloat aspectRatio,
    GLfloat near_, //0.2, // 1.0,  // near clipping plane
    GLfloat far_ //400.0 // far clipping plane
  ) {
    // JG: I call them 'z' because near/far seems to be C++ keywords...
    znear = near_;
    zfar = far_;

    GLfloat vFovRad = vFovDeg * SG_DEGREES_TO_RADIANS; //SG_PI/360.0;

    // from openGL faq: based on fact that
    // vFov*0.5 == atan( (top-bottom)*0.5 / near)
    top = tan(vFovRad*0.5)*znear;
    bottom = -top;
    left  = bottom * aspectRatio;
    right = top * aspectRatio;
  }

};




And then I use it like this:
   ...
    gluPerspective(
      60.0f, // vertical fov
      fAspect,
      0.2, // 1.0,  // near clipping plane
      400.0 // far clipping plane
    );

    frustrumArgs.calcFromPerspective(
      60.0f, // vertical fov
      fAspect,
      0.2, // 1.0,  // near clipping plane
      400.0 // far clipping plane
    );

    ssgSetFrustum(
      frustrumArgs.left,  // JG: I now know that
      frustrumArgs.right, // left/r/b/t is the size of the 'rectangle' at
distance znear!
      frustrumArgs.bottom,
      frustrumArgs.top,
      frustrumArgs.znear,
      frustrumArgs.zfar
    );
   ....

Actually, I don't think this part is the problem,
because I think the ssg frustrum "wins" - the gluPerspective is only set
once,
so after a certain point only the ssg frustrum gets set, again and again (at
least I assume);
so the ssg frustrum is used for all (and the camera stuff still works OK
for all the non-ssg stuff rendered at the same time).


Cheers, and grateful for any help/suggestions/comments offered,
Jakob Gaardsted.

Re: [Plib-users] modifying materials of loaded models on the fly

[Jakob G. <pi...@st...>]

> So my question: Am I just misunderstanding how SSG works
>  - does each and every ssgLeaf need its own separate ssgState?
> I would have thought that 'last used state' would carry through for
> ssgLeafs with NULL ssgState?

A clarification to this: I know that when/if I set the same ssgState pointer
in all of the places, of course in a way I don't have "separate" states.
  But I was hoping SSG would avoid comparing the states and checking
whether it should update the state or not (being NULL is a pretty
solid indicator that you're not going to change any state...)

Cheers, Jakob.

[Plib-users] modifying materials of loaded models on the fly

[Jakob G. <pi...@st...>]

Hi. I'm trying to change the material properties of AC3D models after I load
them.
(think of a bottle model which is then used to render bottles with different
surface properties).
   I can, sort of, achieve this following Steve Bakers earlier suggestion
of locating the ssgSimpleState objects in the loaded model and then
modifying them.
  However, it only works if I update and replace ALL of them.
I was hoping I could just do
myLeaf->setState(NULL)
on all but the first one, and that the state set when starting the rendering
would
then "carry through" throughout the render of the whole object.
   Instead, this leaves the rest of the object uncoloured/white.

There is one optimization that seems to work though
 - I can pick up the first ssgSimpleState, and then replace all the
subsequent ssgstates with it.
From this I at least get, that I only have to modify attributes of one
ssgState.

So my question: Am I just misunderstanding how SSG works
 - does each and every ssgLeaf need its own separate ssgState?
I would have thought that 'last used state' would carry through for
ssgLeafs with NULL ssgState?

I include part of the code here, to illustrate what I'm doing.

class MyTraverser : public TraverserBase {
public:
  ssgState* firstState;
private:
  int leafType;

  virtual bool visit(ssgEntity* pEnt) {
    if (!pEnt->isAKindOf(leafType)) {
      return true; // search on
    }
    ssgLeaf* pLeaf = static_cast<ssgLeaf*>(pEnt);
    ssgState* leafState = pLeaf->getState();
    if (leafState != NULL) {
      if (firstState == NULL) {
        firstState = leafState;
      } else {
        //pLeaf->setState(NULL);
        //pLeaf->setState(new ssgSimpleState);
        pLeaf->setState(firstState);
      }

      /*
      ssgSimpleState* thestate = static_cast<ssgSimpleState*>(leafState);
      thestate->set(GL_COLOR_MATERIAL, false);
      thestate->setMaterial(GL_DIFFUSE, 0.99, 0.1, 0.1, 1.0);
      thestate->setMaterial(GL_AMBIENT, 0.6, 0.2, 0.4, 1.0);
      thestate->setMaterial(GL_SPECULAR,0.4, 0.6, 0.2, 1.0);
      */
    }
    return true;
  }

public:
  MyTraverser() {
    leafType = ssgTypeLeaf();
    firstState = NULL;
  }
};



This I then call like this:

...
    MyTraverser trav;
    trav.findLeafs(my_ssgScene);
    if (trav.firstState) {
      ssgSimpleState* thestate =
static_cast<ssgSimpleState*>(trav.firstState);

      thestate->set(GL_COLOR_MATERIAL, false); // nothing worked without
this...
      thestate->setMaterial(GL_DIFFUSE, 0.99, 0.1, 0.1, 1.0);
      thestate->setMaterial(GL_AMBIENT, 0.6, 0.2, 0.4, 1.0);
      thestate->setMaterial(GL_SPECULAR,0.4, 0.6, 0.2, 1.0);
    }

    ssgFlatten(themodel);
    ssgStripify(tra);



I hope some more experienced users can clarify this.
Cheers and thanks in advance,
Jakob Gaardsted.

[Plib-users] problem with plib recognizing yoke movements of my CH Fighterstick USB

[<da...@ty...>]

Hi,

I just got a CH Fighterstick USB, and wanted to take it for a spin with
FlightGear, which uses plib. I started to check on the joystick with
js_demo that comes with FlightGear.

To my surprise, js_demo does not recognize the yoke movements of the
FighterStick - even though it sees the button presses. Also, if I have
an additional CH Pro Pedal connected, that is recognized properly.

I talked to the FlightGear people, and they told me to contact the plib
crew regarding this issue. so here I am.

I'm running Gentoo Linux, kernel 2.6.13, I have plib 1.8.4 installed.
Some additional info:

$ /usr/sbin/lsusb
Bus 004 Device 002: ID 049f:0086 Compaq Computer Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 005: ID 068e:00f3 CH Products, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
$ js_demo
Joystick test program.
~~~~~~~~~~~~~~~~~~~~~~
Joystick 0: "CH PRODUCTS CH FIGHTERSTICK USB "
Joystick 1 not detected
Joystick 2 not detected
Joystick 3 not detected
Joystick 4 not detected
Joystick 5 not detected
Joystick 6 not detected
Joystick 7 not detected
+--------------------JS.0----------------------+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4                |
+----------------------------------------------+
| 0000 +0.0 +0.0 +0.0 +0.0 +0.0   .    .    .  |


with the primary fire button pressed, it says:

| 0001 +0.0 +0.0 +0.0 +0.0 +0.0   .    .    .  |


if I have the pedal plugged in as well:

$ /usr/sbin/lsusb
Bus 004 Device 002: ID 049f:0086 Compaq Computer Corp.
Bus 004 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 002 Device 006: ID 068e:0501 CH Products, Inc. CH Pro Pedals
Bus 002 Device 005: ID 068e:00f3 CH Products, Inc.
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 001: ID 0000:0000
$ js_demo
Joystick test program.
~~~~~~~~~~~~~~~~~~~~~~
Joystick 0: "CH PRODUCTS CH FIGHTERSTICK USB "
Joystick 1: "CH Products  CH Pro Pedals USB Rudder Pedals "
Joystick 2 not detected
Joystick 3 not detected
Joystick 4 not detected
Joystick 5 not detected
Joystick 6 not detected
Joystick 7 not detected
+--------------------JS.0----------------------+--------------------JS.1----------------------+
| Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4                | Btns Ax:0 Ax:1 Ax:2
                      |
+----------------------------------------------+----------------------------------------------+
| 0000 +0.0 +0.0 +0.0 +0.0 +0.0   .    .    .  | 0000 -0.4 -1.0 -0.2   .
   .    .    .    .  |



what could be wrong?


Akos

R: [Plib-users] gluUnProject help!

[Paolo L. <p.l...@ci...>]

Don't know if it's useful to you, this is the code I use taken from a =
recent
post to the list:


int Project2d3d ( int x2, int y2, float& x3, float& y3, float& z3 )
// does transform 2d into 3d coordinates
{
	GLint viewport[4] ;
	GLdouble modvmatrix[16], projmatrix[16] ;

	glGetIntegerv ( GL_VIEWPORT, viewport ) ;
	/* OpenGL y starts at lower left, X/Windows y starts at top left */
	GLdouble y2gl =3D viewport[3] - y2 ;

	/* Update the Modelview and Projectionmatrix */
	glMatrixMode ( GL_MODELVIEW ) ;  ssgLoadModelviewMatrix () ;
	glMatrixMode ( GL_PROJECTION ) ; ssgLoadProjectionMatrix () ;

	/* Use GL power to find the depth of the projection */
	GLfloat z2 ;
	glReadPixels ( x2, y2gl, 1, 1, GL_DEPTH_COMPONENT, GL_FLOAT, &z2 ) ;
	if ( z2 >=3D 1 ) return 0;

	/* Some more GL magic. Get the projection and modelview matrices */
	glGetDoublev (  GL_MODELVIEW_MATRIX,  modvmatrix ) ;
	glGetDoublev (  GL_PROJECTION_MATRIX, projmatrix ) ;

	GLdouble dx, dy, dz ;

	/* convert screen coords to object coords. */
	int retcode =3D gluUnProject ( x2, y2gl, z2, modvmatrix, projmatrix,
viewport, &dx, &dy, &dz ) ;
	x3 =3D dx ;
	y3 =3D dy ;
	z3 =3D dz ;
	return retcode;
}

Greetings -

Paolo Leoncini


> -----Messaggio originale-----
> Da: pli...@li...=20
> [mailto:pli...@li...] Per conto di=20
> Tinoshi Kitazawa
> Inviato: luned=EC 23 gennaio 2006 20.40
> A: pli...@li...
> Oggetto: [Plib-users] gluUnProject help!
>=20
>=20
> Hello everybody!
>=20
> Do you know how to use the gluUnProject with PLIB??? I need=20
> to do something=20
> like Sim City, so I have a terrain (a scenegraph) built using=20
> PLIB, and I=20
> need to put objects over it clicking with mouse! I'm trying to=20
> gluUnProject(x,y,0.0,...) and gluUnProject(x,y,1.0,...), and=20
> I create a=20
> sgLineSegment3 to connect the two points. Then I'd like to=20
> ssgLOS() this=20
> line with the scenegraph... but I'm going crazy!!! Do you=20
> know a easier way=20
> to do something like that??? Thanks!!!=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep=20
> through log files for problems?  Stop!  Download the new AJAX=20
> search engine that makes searching your log files as easy as=20
> surfing the  web.  DOWNLOAD SPLUNK!=20
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&
dat=3D121642
_______________________________________________
plib-users mailing list
pli...@li...
https://lists.sourceforge.net/lists/listinfo/plib-users

[Plib-users] gluUnProject help!

[Tinoshi K. <ti...@li...>]

Hello everybody!

Do you know how to use the gluUnProject with PLIB??? I need to do something 
like Sim City, so I have a terrain (a scenegraph) built using PLIB, and I 
need to put objects over it clicking with mouse! I'm trying to 
gluUnProject(x,y,0.0,...) and gluUnProject(x,y,1.0,...), and I create a 
sgLineSegment3 to connect the two points. Then I'd like to ssgLOS() this 
line with the scenegraph... but I'm going crazy!!! Do you know a easier way 
to do something like that??? Thanks!!! 

Re: [Plib-users] Threads and textures

[Tinoshi K. <ti...@li...>]

Messaggio
  Thanks for the answers!!!
  Now I preload textures and everything seems to work...