plib-users

[Plib-users] Bluey White Screen when running apps

[<fa...@ya...>]

When I try to run plib apps using ssg (such as Tux
AQFH and Tux Kart), the application starts fine and
runs the PUI elements and sound fine. But the area
where the 3D part of the game should be drawn is just
a blank light blue area, with nothing being drawn.
Mesa is running in h/w via DRI (games like GLTron run
fine), and I have not experienced any problems like
this with other OpenGL apps. I have an ATI Rage Fury
Pro with ATI Rage 128 (pro?) chipset. Any ideas?

Simon Foster.

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

Re: [Plib-users] HappyPenguin.

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

BTW, the "experimental version" link points to 1.3.1.

Bye bye,
Wolfram.

[Plib-users] incorrect line termination

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

Hi,

I noticed the file plib/src/pui/puLargeInput.cxx needs to be parsed into
a to_unix script (at least this is needed for Irix MipsPro compilers).

Erik

[Plib-users] HappyPenguin.

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

OK - so we have 600 people subscribed to the user list and around 200 on
the developer's list and only *ONE* person has been to www.happypenguin.org
to rate the library?

(Hint: CrystalSpace has five stars and we have only four!)

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] ANNOUNCING PLIB 1.3.2.

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

Announcing PLIB 1.3.2.
~~~~~~~~~~~~~~~~~~~~~~

This is the first PLIB release since September 2000 and although it's another
odd-numbered (ie potentially unstable) release, it is in feature-freeze and
will become PLIB 1.4.0 within the next week or so.

If you are a PLIB application author, you should now port your PLIB code to
1.3.2 and check that it's all working correctly so that we can get any
last-minute fixes into 1.4.0.

The MAJOR non-reverse compatible change with 1.3.2 onwards is that the
SSG loader functions now require a new argument to pass 'ssgLoaderOptions'
rather than the old ad-hoc collection of function hooks.

Reference counting has also been added to ssgState objects so if you load
your textures and states once at the start of your code and delete the
models as you progress from one level of the game to another (As TuxKart
and TuxAQFH do for example) then you'll need to manually 'ref()' each
state and texture as you create it in order to avoid them being deleted
when the last model that refers to them is removed.

There are *MANY* significant enhancements and bug fixes.

You can grab PLIB 1.3.2 at http://plib.sf.net  (notice that 'sourceforge'
can now be abbreviated to 'sf' in URL's).

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] How to compute screen coordinates

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

> Corto Maltese wrote:

> I want to compute the screen (pixels) coordinates in the viewport of a world 3d point.
> How to do that ?
> I know that gluProject can do that....

  "Use the Source Luke".

The sources for gluProject are available from either the SGI reference implementation
of OpenGL or Mesa.

The Mesa source is:

static void transform_point( GLdouble out[4], const GLdouble m[16],
                             const GLdouble in[4] )
{
#define M(row,col)  m[col*4+row]
   out[0] = M(0,0) * in[0] + M(0,1) * in[1] + M(0,2) * in[2] + M(0,3) * in[3];
   out[1] = M(1,0) * in[0] + M(1,1) * in[1] + M(1,2) * in[2] + M(1,3) * in[3];
   out[2] = M(2,0) * in[0] + M(2,1) * in[1] + M(2,2) * in[2] + M(2,3) * in[3];
   out[3] = M(3,0) * in[0] + M(3,1) * in[1] + M(3,2) * in[2] + M(3,3) * in[3];
#undef M
}


GLint GLAPIENTRY gluProject(GLdouble objx,GLdouble objy,GLdouble objz,
                          const GLdouble model[16],const GLdouble proj[16],
                          const GLint viewport[4],
                          GLdouble *winx,GLdouble *winy,GLdouble *winz)
{
    /* matrice de transformation */
    GLdouble in[4],out[4];
 
    /* initilise la matrice et le vecteur a transformer */
    in[0]=objx; in[1]=objy; in[2]=objz; in[3]=1.0;
    transform_point(out,model,in);
    transform_point(in,proj,out);
 
    /* d'ou le resultat normalise entre -1 et 1*/
    if (in[3]==0.0)
       return GL_FALSE;
 
    in[0]/=in[3]; in[1]/=in[3]; in[2]/=in[3];
 
    /* en coordonnees ecran */
    *winx = viewport[0]+(1+in[0])*viewport[2]/2;
    *winy = viewport[1]+(1+in[1])*viewport[3]/2;
    /* entre 0 et 1 suivant z */
    *winz = (1+in[2])/2;
    return GL_TRUE;
}
  

[Cool!  Comments in French!]
                                                                              
> For Steve Baker : You've done a pretty great job with Plib. Bravo!

Let's hope you still feel that way after we produce 1.3.2 later today.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

[Plib-users] How to compute screen coordinates

[Corto M. <ma...@no...>]

Hi all=20

I want to compute the screen (pixels) coordinates in the viewport of a =
world 3d point.
How to do that ?
I know that gluProject can do that, but i want to know the formulas =
because my real objective is to estimate how much a vector visualy =
increase/decrease in pixel size when the camera move with a given speed =
vector in a known direction.
I need this to make some kind of a auto LOD simplication/refinement of a =
very complex surface. I can't do simple LOD switch because its visualy =
ugly and consume too much memory and/or time. So i need to do an =
incremental simplication/refinement of the mesh surface.

Thanks for help.

PS:
For Steve Baker : You've done a pretty great job with Plib. Bravo!

Malt.

Re: [Plib-users] Loading geometry information

[Sam S. <sa...@sp...>]

----- Original Message -----
From: "Steve Baker" <sjb...@ai...>
To: <pli...@li...>
Sent: Sunday, June 10, 2001 11:44 AM
Subject: Re: [Plib-users] Loading geometry information


> Ben Woodhead wrote:
>
> > Is it possible to send geometry information without using a model
> > loader.
>
> You can *create* geometry without a loader - yes.
>
> > I would like to send the model information across a network
> > using worldforge.
>
> I don't know much about worldforge.  Generally, to sent something
> over a network, you have to convert it to a neutral format - and
> probably the best way to do that would be to save it to disk and
> transmit the file across the net...but it depends a LOT on how
> much generality you need and the volume and speed of data you expect
> to send.

Hmmm.. I saw a library on sorceforge that could send model information over
a network - I think it had it's own (basic) scenegraph library as well.  If
I remember correctly it could do model deformation as well. I'll see if I
can dig out the homepage for ya.

But, aside from using that library, it quite a task to do.  If I were you
I'd do like Steve suggests pick a compact (or easily compressable)
file-format - perhaps write your own ssg exporter.  You can send this file
to the clients along with a GUID of some type to reference it.

What you do also depends if you intend on sending models only when a client
connects, or if you want to be sending them at other times as well (ie.
during gameplay). (If it's the later you'll need some way - or WorldForge
will - to prioritze data streams so you don't flood connections).

If you are also using a LOD system for your models (with seperate meshes),
you can send the low-detail ones first so the client should always have
something to display.  For a worst case situation keep the most basic meshes
very very simple (ie. a rectangle, or a sphere - use ssgAux's shapes to
describe them and you can keep the file sizes down a lot).

But if you want to do more complex stuff (deformation of vertex meshes
etc.), then it's a LOT more work.

Sam

Re: [Plib-users] clipping performance question.

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

"Curtis L. Olson" wrote:
> 
> Gouthas, Themie writes:
> > Just an optimization question for frustrum clipping, which would better be
> > directed to an OpenGL format, but this forum is more convenient at this
> > point in time..
> >
> > For basic line strips, say of 100's to 1000's of points. Is it worthwhile
> > going to the trouble of calculating a bounding spehere  for clipping to the
> > view frustrum, or is line clipping pretty efficient.

Depends on:

  1) How often your points are updated. (Do you have to update the bsphere
     every frame).

  2) How fast they move relative to the radius of the sphere. (You could for
     example increase the radius of the sphere by the speed of the fastest
     point every frame until the size of the sphere hit some magic limit,
     and only *then* go and recompute it.  If your points are *basically*
     buzzing around in a small area then this could be a big win.)

  3) Is there some incremental way to update the bounding sphere?

  4) The number of points in the cluster.

  5) (Critically) Do you want to run on older hardware without hardware
     Transforms & Lighting. (If you *do* then doing work in the CPU to
     save work in the CPU might make a lot of sense - but if you have
     hardware doing the clipping, it may be easier to simply squirt the
     points at the hardware and let T&L do the work.)

For line strips, you only need to find the six points with the largest
and smallest X, Y and Z coordinates - imagine a bounding cubeoid around
those limiting coordinates and then wrap your bounding sphere around
that.  That makes the bsphere a bit too large - but it's pretty cheap
to compute.

> > You would think that an
> > intelligent implementation would check the end points of a line segment
> > first and not attempt to draw it if both were out of the clipping rectangle.
> > Anyone have an idea what OpenGL does?

Probably uses the Sutherland outcode test.

> The middle of the line strip could intersect the view volume even if
> niether end point was visible.  Also, there's nothing that says a set
> of points have to be in a straight line, so it could wind in and out
> of the view volume several times.

The Sutherland algorithm gets around that efficiently.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

Re: [Plib-users] Loading geometry information

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

Ben Woodhead wrote:

> Is it possible to send geometry information without using a model
> loader.

You can *create* geometry without a loader - yes.

> I would like to send the model information across a network
> using worldforge.

I don't know much about worldforge.  Generally, to sent something
over a network, you have to convert it to a neutral format - and
probably the best way to do that would be to save it to disk and
transmit the file across the net...but it depends a LOT on how
much generality you need and the volume and speed of data you expect
to send.

> Also how do I setup a height field.
 
You could check the example program:

    examples/src/ssg/majik

...that creates a polygonal skin from a regular height field.

----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net     http://tuxaqfh.sf.net  http://tuxkart.sf.net
           http://agtoys.sf.net   http://prettypoly.sf.net
           http://freeglut.sf.net http://toobular.sf.net

RE: [Plib-users] problem with plib compilation

[Norman V. <nh...@ca...>]

>
>>there is 2 files
>>Makefile.am and Makefile.in
>>I going to edit Makefile.am and rename in Makefile
>
>I am pretty sure renaming is bad.
>
>For the others: Gael has the problem of the missing makefile in
>ssgAux. Can someone using makefiles help him?
>Looking through old posts, he has to add ssgAux to some file and then
>probably to redo the config process?

There are two problems with the 1.2 release

1) #include <float.h> is missing for some platforms in ul.h
2) at the end of in config.in

AC_OUTPUT( \
	Makefile \
	src/Makefile \
	src/include/Makefile \
	src/js/Makefile \
	src/util/Makefile \
	src/pui/Makefile \
	src/sg/Makefile \
	src/sl/Makefile \
	src/ssg/Makefile \
	src/ssgAux/Makefile \
	src/fnt/Makefile \
	src/net/Makefile )

The ssgAux entry is missing

so Gael needs to add the #include <float.h> to ul.h

and replace the AC_OUTPUT( \
...
)

in plib / src / config.in with the above 
then do

% cd plib
% rm config.cache
% aclocal
% automake -a
% autoconf
% ./configure
% make

Cheers

Norman

Re: [Plib-users] problem with plib compilation

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

Gael wrote:

>there is 2 files
>Makefile.am and Makefile.in
>I going to edit Makefile.am and rename in Makefile

I am pretty sure renaming is bad.

=46or the others: Gael has the problem of the missing makefile in
ssgAux. Can someone using makefiles help him?
Looking through old posts, he has to add ssgAux to some file and then
probably to redo the config process?

Bye bye,
Wolfram.

RE: [Plib-users] problem with plib compilation

[gael <gae...@fr...>]

there is 2 files
Makefile.am and Makefile.in
I going to edit Makefile.am and rename in Makefile

Re: [Plib-users] problem with plib compilation

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

Please add

#include <float.h>=20

in ul.h

This is fixed in the current development code.

Bye bye,
Wolfram.

RE: [Plib-users] clipping performance question.

[Dave M. <Dav...@dy...>]

If you are doing bounding sphere checks for each line segment, it might be
better to hand it all to opengl because it's roughly the same amount of
work.  but if, as you say, the strips contain 100s to 1000s of points then
view frustum culling on each strip is probably worth it  regardless of how
the opengl implementation handles it.  the number of computations is of a
different magnitude.

it also depends on where your viewpoint is.  if you have a god view where
everything is in view and nothing is view frustum culled, then you won't see
improvement.  but if you are inside a _room_ then view frustum culling makes
a big impact.

we've actually tested this on game console where we thought that perhaps an
uber display list (with all geometry) would be _a good thing_ since the main
CPU is a dog and the 3d processor is very fast.  we would eliminate the
overhead for many (several hundred) display lists and pass a single DMA
packet to the 3d processor.  but we found that view frustum culling (ssg
style) is very well worth it, even there.

-- Dave McClurg

-----Original Message-----
From: pli...@li...
[mailto:pli...@li...]On Behalf Of Gouthas,
Themie
Sent: Wednesday, May 30, 2001 10:40 PM
To: 'pli...@li...'
Subject: [Plib-users] clipping performance question.

Just an optimization question for frustrum clipping, which would better be
directed to an OpenGL format, but this forum is more convenient at this
point in time.. 

For basic line strips, say of 100's to 1000's of points. Is it worthwhile
going to the trouble of calculating a bounding spehere  for clipping to the
view frustrum, or is line clipping pretty efficient. You would think that an
intelligent implementation would check the end points of a line segment
first and not attempt to draw it if both were out of the clipping rectangle.
Anyone have an idea what OpenGL does? 
 
Thanks, Themie

[Plib-users] problem with plib compilation

[gael <gae...@fr...>]

Hello ,
I can't compile plib, I have got needed librairies (glibc2.2.2, opengl 
NVIDIA, glut 3.7.0)
In file included from pu.h:27,
                 from puLocal.h:31,
                 from pu.cxx:2:
../../src/sg/sg.h: In method `void sgBox::empty ()':
../../src/sg/sg.h:842: `FLT_MAX' undeclared (first use this function)
../../src/sg/sg.h:842: (Each undeclared identifier is reported only
once for each function it appears in.)
../../src/sg/sg.h: In method `void sgdBox::empty ()':
../../src/sg/sg.h:1961: `DBL_MAX' undeclared (first use this function)
make[2]: *** [pu.o] Erreur 1
make[2]: Quitte le répertoire `/root/plib-1.2.0/src/pui'
make[1]: *** [all-recursive] Erreur 1
make[1]: Quitte le répertoire `/root/plib-1.2.0/src'
make: *** [all-recursive] Erreur 1
I don't know if I forgot to install a librairie
Thank  

[Plib-users] problem with plib compilation

[gael <gae...@fr...>]

Hello ,
I can't compile plib, I have got needed librairies (glibc2.2.2, opengl 
NVIDIA, glut 3.7.0)
In file included from pu.h:27,
                 from puLocal.h:31,
                 from pu.cxx:2:
../../src/sg/sg.h: In method `void sgBox::empty ()':
../../src/sg/sg.h:842: `FLT_MAX' undeclared (first use this function)
../../src/sg/sg.h:842: (Each undeclared identifier is reported only
once for each function it appears in.)
../../src/sg/sg.h: In method `void sgdBox::empty ()':
../../src/sg/sg.h:1961: `DBL_MAX' undeclared (first use this function)
make[2]: *** [pu.o] Erreur 1
make[2]: Quitte le répertoire `/root/plib-1.2.0/src/pui'
make[1]: *** [all-recursive] Erreur 1
make[1]: Quitte le répertoire `/root/plib-1.2.0/src'
make: *** [all-recursive] Erreur 1
I don't know if I forgot to install a librairie
Thank  

Re: [Plib-users] Segfault in ssgBase.cxx

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

This is a PPE problem.

I have moved the discussion to ppe-devel.

Thanks for the report,
Wolfram.

[Plib-users] Segfault in ssgBase.cxx

[Cameron M. <li...@to...>]

I grabbed PPE from CVS tonight to play with it a little and stumbled
onto a segfault.  Both plib and ppe were taken from CVS just moments
ago.  My revision number for ssgBase.cxx is v1.15.

To reproduce:
- run ppe
- open Material/Map Browser
- toggle Auto Update
- SIGSEGV

GDB output:
(gdb) run
Starting program: /usr/local/bin/ppe 
[New Thread 1024 (LWP 19235)]
initializing thumbnail
curr_viewer 0x8229ee0   Viewer 0x8229ee0
in main
Running /usr/local/share/ppe/scripts/default_bindings.py
default_bindings are at:
/usr/local/share/ppe/scripts/default_bindings.py 
Loading Default Bindings...
End of Default Bindings.
Reading personal resource script from '/home/cameron/.ppe_rc'

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 19235)]
0x80eaf5e in ssgBase::copy_from (this=0x82e9c50, src=0x0, clone_flags=0)
    at ssgBase.cxx:45
45        spare = src -> getSpare () ;
(gdb)

System:
  Debian unstable/sid
  Linux 2.4.4
  gcc 2.95.4 20010522
  glibc 2.2.3-4
--
Cameron Moore

Re: [Plib-users] clipping performance question.

[Curtis L. O. <cu...@me...>]

Gouthas, Themie writes:
> Just an optimization question for frustrum clipping, which would better be
> directed to an OpenGL format, but this forum is more convenient at this
> point in time.. 
> 
> For basic line strips, say of 100's to 1000's of points. Is it worthwhile
> going to the trouble of calculating a bounding spehere  for clipping to the
> view frustrum, or is line clipping pretty efficient. You would think that an
> intelligent implementation would check the end points of a line segment
> first and not attempt to draw it if both were out of the clipping rectangle.
> Anyone have an idea what OpenGL does? 

The middle of the line strip could intersect the view volume even if
niether end point was visible.  Also, there's nothing that says a set
of points have to be in a straight line, so it could wind in and out
of the view volume several times.

Curt.
-- 
Curtis Olson   Human Factors Research Lab       FlightGear Project
Twin Cities    cu...@hf...                cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-users] clipping performance question.

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

Themie wrote:

>For basic line strips, say of 100's to 1000's of points. Is it =
worthwhile
>going to the trouble of calculating a bounding spehere  for clipping to =
the
>view frustrum, or is line clipping pretty efficient.=20

If I am not missunderstanding, then the b. sphere is used to decide
whether the whole thing is completely inside, completely outside (or=20
clipping the edge). This can be done once. Any line clipping is done
100 to 1000 times.

>Thanks, Themie

Bye bye,
Wolfram.

[Plib-users] clipping performance question.

[Gouthas, T. <the...@ds...>]

Just an optimization question for frustrum clipping, which would better be
directed to an OpenGL format, but this forum is more convenient at this
point in time.. 

For basic line strips, say of 100's to 1000's of points. Is it worthwhile
going to the trouble of calculating a bounding spehere  for clipping to the
view frustrum, or is line clipping pretty efficient. You would think that an
intelligent implementation would check the end points of a line segment
first and not attempt to draw it if both were out of the clipping rectangle.
Anyone have an idea what OpenGL does? 
 
Thanks, Themie

Re: [Plib-users] Loading geometry information

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

Ben Woodhead <be...@ec...> wrote:

>Hello
>
>Is it possible to send geometry information without using a model=20
>loader. I would like to send the model information across a network=20
>using worldforge.

You can create a ssgVertexArray and do a addKid.
I would suggest you start with a loader, either by tweaking the code
or by understand a loader and then coding what you need from scratch.
A simple one is ssgLoadTRI.

> Also how do I setup a height field.

You have the heights for a regular 2D grid? Then I would
"manually" create TriStrips or QuadStrips. Most things you know from
OpenGL may be used in PLIB.

>Thanks Ben

Bye bye,
Wolfram.

[Plib-users] Loading geometry information

[Ben W. <be...@ec...>]

Hello

Is it possible to send geometry information without using a model 
loader. I would like to send the model information across a network 
using worldforge. Also how do I setup a height field.

Thanks Ben

-- 
Programming law 1:
It's easy to make things complex but it's hard to make them simple.

Programming law 2:
In theory, theory and practice are the same.
In practice they're NOT!

RE: [Plib-users] Memory Leaks

[Dave M. <Dav...@dy...>]

Larry Alejo wrote:
> I have made an attempt, on my version of plib, to
> squash a few of these memory leaks and respectfully
> offer the following code changes to the contributors
> of plib for consideration and inclusion into the library.

thanks!  i made the commit to CVS.

-- Dave McClurg