plib-devel

Re: ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG examples)

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

Sam Stickland wrote:
> 
> RE: [Plib-devel] Simple SSG examplesThere were a couple of problems with
> it - one was my fault (polygon winding issues - should had realised back
> face culling was on by default, doh! ), and the other is a bug in ssg.
> 
> The ssgContext class initialises the camera matrix to the identity
> matrix and not _ssgOpenGLAxisSwapMatrix.  So if you do nothing with the
> camera you end up with opengl's coordinate covention (y is up), rather
> than ssg's (z is up).

Hmmm - yes - you are exactly right.

I have never written a program where the camera wasn't initialised
explicitly.

I'll fix it right now.

> Anyway it works now, so by tomorrow I should have some real simple ssg
> examples to contribute.  I've got a simple textured spinning cube, an
> explosion, and a simple scene you can fly round (using the quaternion
> routines).  Nothing hot, but I always find I learn a damn site quicker
> from examples than documentation so I imagine these will be of use to
> people.

Great!

Sample programs are always a horrible chore for experts in the API to
write (we want to build big, complicated programs)...so ironically,
the best source for example programs may well be in people who have
just picked up the package and are experimenting with it.

Do you want CVS write-access to contribute these examples?  If so,
I need to know your Sourceforge user ID.

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

Re: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass wrote:

> there is a new game in town that uses plib:
> 
>    Kobayashi Maru      kobayashimaru.sourceforge.net

I'll check it out - do you have a small logo that I could put
on the PLIB home page as a link to the game?

> Arg! It took me a whole month experimenting with euler angles,
> rotating starfighters, completely failing.

Ah - perhaps you should ask for help next time!

> Then I switched to up-right-forward-direction vectors and succeded.
> 
> Exacly one day later, I stumbled across 'Euler Angles are Evil' by
> Steve, and I knew why I failed a whole month.
> 
> Dear Steve, I could kiss you all day long for plib and Tux, but
> I'll gonna kick your ass sometime because it would be very very
> better if you'd put at least 'Euler Angles are Evil' and
> 'Matrices can be your Friends' on the _plib_homepage_, so that
> even an idiot like me will stumble over it before he looses time.

Actually - neither being kissed all day long nor having my ass
kicked sound all *that* attractive.  :-)

Mailing me requests written on the back of $100 bills gets my
attention though   ;-)

On the "math_help" page - where you are heaping praise on my
FAQ page and running me into the ground for my web-organizational
skills, you describe me as a "non-professional" - that's not too
accurate.  I write flight sim graphics for a living.

Also, after all you said about the FAQ page, you didn't provide a
link to it!

The "matrices can be your friend" document is an example one of
those documents you either love or hate.  Several mathematicians have
come close to death threats over it.  Offers of 24hr kissings are
also not as uncommon as you might expect.  :-)

I came across that explanation for how a matrix works completely
by accident.  When I was just starting out doing 3D, I was
blinded by the inscrutability of matrices - so I decided to try
to invent a new way to do 3D transforms.  I wanted to think about
what happened to the unit cube - and then use extrapolation to
figure out what happened to the rest of the model.  So, I wrote
down the coordinates that the unit cube would move to - and
then said "well, a point at (10,12,14) will end up ten times
further than where the X axis of the cube went, 12 times where
the Y axis went and 14 times where the Z axis was." 

That trick worked *perfectly* - and so - being very proud of
having discovered this brand new way to do rotation/translation/shear,
I showed my supervisor...who pointed out that the math in my
final result was in fact identical to matrix math!  Sheepishly,
I went back to my desk - realising that I had not stumbled on
some great new mechanism that would revolutionise 3D rendering.

Working back carefully, I realised that by writing down the
final position of the unit cube - I was just writing down the
rows of the damned matrix that I hated so much. At that point,
a bolt of lightning flashed from the heavens - angels sang, etc, etc.

I *grokked* matrices by re-inventing them from the ground up.
"grok" is a good word here.  It means more than "understand" - it
means that you have 'internalized' not just the bare facts - but
all the reasons *why* it works, *how* it works, etc.

Once you have that little unit cube dancing around in your head,
you can never again forget how matrix math implements 3D transformations.

If only math teachers could figure out the importance of teaching
*some* students that way.

Other people on the other hand, prefer the raw math - and proof in
a symbolic manner - they don't need to visualise what's going on...
and they *HATE* my explanation.

> I also want to have you a look at KobayashiMaru, because I am even
> worse in designing spaceships than in maths, and so I took the
> models that came with Tux_aqfh for my own project, please allow me
> to use them in my game.

Sure - that's what OpenSource is all about.  The models that come
with Tux{AQFH,Kart} are licensed under GPL - just like the game itself,
and so long as your game is also released as source code under GPL (or
something compatible) then you are all set to go - and you don't even
need to ask permission. (Although it's nice that you did)
 
> Your authorship is of course mentioned.

Thank-you!
 
> I am some time now receiving the plib-* mailing lists, but I actually
> never had time to read them, so it could be that I am using plib
> not in the optimum way to give best performance.
> All calls to plibssg have been capsulated in class KobScene and
> KobSceneObject, if there is something to impove, let me know.
> 
> I am also having the problem of being not able to use a 3D modeler
> at all (tried,failed,tried,failed,tried,failed,gave up), couldn't
> even make a Tie Fighter, and all free 3D objects I found
> in the net where designed for ray-traying and had far too many
> polygons and no texture - I'm desperate.

Hmmm - the problem of getting appropriate free artwork is a hard one.

Many people have mentioned the reluctance of artists to donate their
work to the OpenSource community...there was a LONG thread about this
on the Linux Games Developers list which resulted in the formation of
a mailing list for artists working in the OpenSource community to get
together and spread the word.

> So, if there is anyone out there dreaming like me to see X-Wings and
> Tie-Fighers and Klingons and Borgs and the not-yet-created ships
> from the Free Stars Foundation (FSF) (their High Priest is a Holy Gnu -
> a really weird hairy animal ;-) and the TuxFleet (a horde of inter-
> stellar penguins flying giant Iceberg-shaped glistering StarLiberators,
> they cooperate in an alliance with the FSF to fight
> Imperator Raw-Ass The Utterly Evil - aka me, in this game I wanna be
>  the bad guy)

:-)

Well, you'd do well to steer clear of X-wings, Tie Fighters, Klingons
and Borg because you'll get your ass sued for sure.

Rip the rotors off the 'tuxcopter' in TuxAQFH and you'd have a
usable 'StarLiberator' shuttlecraft.  :-)

I'll ask Oliver if he'd consider building you some spaceships - he
likes doing stuff like that.  He's away from home until next weekend
though...be patient!

> I'll do the coding till my fingers bleed, but please, please, PLEASE
> 
>     can't anyone out there design 3D Models for this game?
> 
> I need models with few polygons as possible, in low,mid and high detail,
> and with _lots_ of texture, since that's what a modern Gfx-Card
> (exept GForce) can take.
> You can even create more detail levels in between, but I need
> anything that runs on a todays computer (and - in low detail - even
> on old ones).

Fortunately, space ships can be anything from a Borg Cube (Six textured
quadrilaterals) to the ship in "The Last Starfighter" - which at the
time was the most complex object ever modelled inside a computer - at
over 1 million (untextured) triangles.

The artists working on StarTrek must have wanted to go home early on
the day they designed the Borg ship!  :-)

> I also dream about running Kobayashi Maru on a PDA running linux -
> ever there ever is something like a 'fastGLforPDA' available,
> you'd need even low low detail ;-)

They announced 'MiniGL' (which runs on PalmPilot) last week at SigGraph.
It's likely to be *horrificly* slow - and with only 5-grey-shade monochrome
with no Z buffer, I don't think you *really* want to go there yet.

There was also an announcement of a formal standard for an OpenGL subset
that runs on Cell phones and pagers (presumably not *this* generation of
such devices) - but no implementation is available yet.   :-)

> Now again thoughts about plibssg performance.
> I have not much performance on my Athlon500/Tnt2, some is wasted in
> my code (I know exactly where), but a large part is lost in ssgCullAndDraw().
> If there is something to be improved in KobScene/KobSceneObject, please
> do that.

Well, in TNT-2, all your transform and lighting code is in software,
so you should expect ~90% of your CPU time (for a typical game) to
be in ssgCullAndDraw().  Now, if (whilst it's consuming that much
CPU time), you are not getting reasonable polygon throughput rates,
we have a problem.

How many polygons are you drawing - and what kind of frame rate are
you getting - with what percentage of your CPU time going into ssgCullAndDraw?

Looking at your screenshot, I'd guess that a TON of time is being wasted drawing
the text.  It *looks* to me like it's being drawn using GLUT's fonts - which
are REALLY slow on most graphics cards.

You really need to draw text using textured quadrilaterals - for which there
is (of course) a PLIB library 'FNT'.

However, for a fast action game, nobody will have time to read all that tiny
text anyway.  It's generally considered a good idea to use as little text
as possible in a game - preferably none at all.

Also, that spider's web looking thingy - I presume it's a radar display - is
consuming a LOT of throughput if it's being drawn as OpenGL lines - there appear
to be at least 120 lines being drawn.  Most PC graphics hardware does a very poor
job of drawing lines - so you'd be better off painting a really nice radar display
in GIMP (or whatever paint program you prefer) - and drawing that as a single
textured quad.

> But the capsulation of the Scenegraph the game uses in KobScene will
> make it possible to 'switch' between different Scenegraphs (at least
> at compile time).

OK...but all that abstraction and layering costs time - why do you think
you need it?   I know it's nice *in theory* to have a choice of scenegraph
API's but what actual benefit does it bring?   Well, I suppose it lets
you choose non-portable scene-graphs for specific platforms - but I very
much doubt that you could reconcile all the little itty-bitty features
you'll come to need across a wide range of scene graph platforms.

SSG already acts as a portability layer - why go and build a portability
layer ON TOP of a portability layer?

> The aim should be that KobayashiMaru should be able to compile for any
> Scenegraph and any Soundhandler at any time.
> I'd really like to use a glDoom/glQuake/Quakeforge/Aftershock-based
> Scenegraph, if you could give me a pointer to where to find good
> docu and easy-to-use examples...

Those tend to be highly oriented to the kinds of game they come from.

I don't think you could do a good space game using a first-person-perspective
shooter "game engine".

I don't know about glDoom or Aftershock - but Quake/Quakeforge are tuned
for all the fancy flickering torchlight lighting effects and 'portal'
clipping that being in a dark closed space entails.  That's pretty much
the opposite of a space game.

> Other Scenegraphs I've thought of are SGI Performer, Crystal Space,
> Genesis3D, PVision...Direct3D

Yep - all of those are possible.

Performer and Direct3D are of course utterly non-portable. (Well, Performer
runs under IRIX and Linux - but nothing else).

Crystal Space is also heavily slanted towards FPS games (in my opinion).

I don't know enough about PVision or Genesis3D to comment on those.

There are also some others that you missed - OpenSG for example.

> I had yet no time to look at those, can't anyone else do that and
> mail me a summary?
> What a Scenegraph for KobayasiMaru should be able to do can be seen
> by reading kob_scene.h/cxx

Well, SSG is a LOT like Performer - in fact, if you look far enough
back into it's origins, it actually started out as a clone of Performer's
scene graph functions.
 
> At the moment I use plibsl for very very basic sound effects, but for
> a game like that I need full-stereo-full-pitching-xxx-channels etc,
> even 3D sound will be possible with the right underlying Soundhandler,

Then I think you should look into 'OpenAL' - which is big-time into
3D spatialised sound.

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

ssgVtxArrary and ssgSimpleList addtions + pui resize additions (was Re: [Plib-devel] Changing VTable triangles (+ blend and texture modes))

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

Well, obviously I should had been using ssgVxtTable rather than the
obsolute ssgVTable - which means the set methods I mentioned need to be
a part of ssgSimpleList.

In my copy I've added:

  void raw_set (unsigned int n, char *thing )
  {
    if(n < total)
      memcpy ( & list [ sizeof * n ], thing, size_of ) ;
  };

in ssgSimpleList, and equivlent methods in ssgVertexArray,
ssgTexCoordArray, ssgNormalArray, ssgColourArray, ie:

  void  set ( unsigned int n , sgVec3 thing ) { raw_set ( n, (char *)
thing ) ; } ;

in ssgVertexArray.

And then in ssgVtxArrary:

  void setVertex  (int i, sgVec3 thing){ if(i<getNumVertices
())vertices ->set(i, thing)}
  void setNormal  (int i, sgVec3 thing){ if(i<getNumNormals
())normals  ->set(i, thing)}
  void setTexCoord(int i, sgVec2
hing){ if(i<getNumTexCoords())texcoords->set(i, thing)}
  void setColour  (int i, sgVec4 thing){ if(i<getNumColours
())colours  ->set(i, thing)}

If it's liked I'd appreciate this code being added to the CVS version.


I've also hacked my copy of pui so that gadget sizes can be specified in
opengl co-ordinates, rather than pixels.  It's very simple - it uses
this code from the non-glut part of pui:

static int puWindowWidth  = 400 ;
static int puWindowHeight = 400 ;

int puGetWindowHeight () { return puWindowHeight ; }
int puGetWindowWidth  () { return puWindowWidth  ; }

void puSetWindowSize ( int width, int height )
{
  puWindowWidth  = width  ;
  puWindowHeight = height ;
}

I need this because I use some of the pui gadgets (well actually
subclasses of the pui gadgets), to add controls to my HUD (this is also
coupled with calling  puGetUltimateLiveInterface () -> draw ( 0, 0 ) ;
myself rather than calling puDisplay() - as this would cause a redundant
glViewport call).

If anyone else is interested in this I'll knock up an alteration so that
it can be enabled at runtime.

Sam

RE: [Plib-devel] KobayashiMaru & plib

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

Alexander Rawass writes:

>there is a new game in town that uses plib:
>
>   Kobayashi Maru      kobayashimaru.sourceforge.net

Congratulations to Alexander,  and also to Steve and all the others
helping to keep PLib cross platform.

Except for changing the set_callback code in one derived puObject
to use a staticly defined function instead of a class member

This code compiles and runs on my Win98 box with Cygwin V1.1.3
by only changing the CXXFLAGS, LDFLAGS and LDLIBS
variables in the makefile !!!

Norman

FYI
!!! makefile mods for Cygwin V1.1.3
INCDIRS= -I/usr/local/include
LDFLAGS= -L/usr/local/lib
GLLIBS= -lglut32  -lopengl32 -lglu32
CXXFLAGS= -Wall -DWIN32

!!! puScrollList.h mods
//  void slider_callback(puObject *pob);

!!! puScrollList.cxx mods
!! replace method with smae name with this static
static void slider_callback(puObject *pob){
  //  printf("in slider callback\n");
  puSlider  *psl=(puSlider *) pob;
  //float val= pob->getValue();
}

!!! change this line in constructor
//    slider->setCallback( (void (*)(puObject *))
(&puScrollList::slider_callback) );
    slider->setCallback(slider_callback);

[Plib-devel] Changing VTable triangles (+ blend and texture modes)

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

Hi,

I'm currently putting together an explosion class for an ssg example
(sparks, smoke, debris that sort of thing).  It seems quite an overhead
to have this structure:

explosion
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
    +----- ssgTransform
    |            |
    |            +------- ssgVTable (spark)
    |
   etc.

If there was a setVertex(int n, sgVec3) method in ssgVTable then I could
get rid of all transforms and individual spark nodes and just have one
ssgVTable that rendered the lot (and also one bounding sphere). ie:

explosion
    |
    +----- ssgVTable (sparks)
    |
    +----- ssgVTable (smoke)
    |
   etc.

Does it seem sensible to add this method (I'll try it when I have some
working code and test the speed difference).  The only oddity it would
have is that you'd have to destroy and recreate the display list if it's
been created (but then you shouldn't be calling setVertex on a diplay
list node now should you :) ).

Another question (should probably go to plib-users but I don't seem to
get the subscribe confirmation messages back at the moment) - blend and
texture modes.  How are these set?

There's the enable (GL_BLEND) in ssgSimpleState, but where do you set
the blend mode parameters?  Likewise for the texture environment modes.
Do you use the pre and post draw callbacks?  That seems a little bit
ugly to me - am I missing something?

Sam

[Plib-devel] Changing triangles in a ssgVTable

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

Hi,

I'm currently putting together an example that draws an explosion
(smoke, sparks, debris that sort of thing).  It seems a very high
overhead to have this sort of structure:

explosion

[Plib-devel] KobayashiMaru & plib

[Alexander R. <ale...@us...>]

Hi,


this is an 'Open Letter' to Steve and Oliver Baker and all other people
 behind plib, Tux_aqfh and Tuxkart:

there is a new game in town that uses plib:

   Kobayashi Maru      kobayashimaru.sourceforge.net

a Mailing List kob...@li... has been
created

It's goal is to write a flexible, extensible, multi-platform (blah blah
 blah :-) Space Fight Simulator in 3D

I searched a long time for a scenegraph I could easyly use, because
I didn't knew GL at that time, and the onlu useable I found was plib.

Arg! It took me a whole month experimenting with euler angles,
rotating starfighters, completely failing.
Then I switched to up-right-forward-direction vectors and succeded.

Exacly one day later, I stumbled across 'Euler Angles are Evil' by
Steve, and I knew why I failed a whole month.

Dear Steve, I could kiss you all day long for plib and Tux, but
I'll gonna kick your ass sometime because it would be very very
better if you'd put at least 'Euler Angles are Evil' and
'Matrices can be your Friends' on the _plib_homepage_, so that
even an idiot like me will stumble over it before he looses time.

I also want to have you a look at KobayashiMaru, because I am even
worse in designing spaceships than in maths, and so I took the
models that came with Tux_aqfh for my own project, please allow me
to use them in my game.

Your authorship is of course mentioned.

I am some time now receiving the plib-* mailing lists, but I actually
never had time to read them, so it could be that I am using plib
not in the optimum way to give best performance.
All calls to plibssg have been capsulated in class KobScene and
KobSceneObject, if there is something to impove, let me know.

I am also having the problem of being not able to use a 3D modeler
at all (tried,failed,tried,failed,tried,failed,gave up), couldn't
even make a Tie Fighter, and all free 3D objects I found
in the net where designed for ray-traying and had far too many
polygons and no texture - I'm desperate.

So, if there is anyone out there dreaming like me to see X-Wings and
Tie-Fighers and Klingons and Borgs and the not-yet-created ships
from the Free Stars Foundation (FSF) (their High Priest is a Holy Gnu -
a really weird hairy animal ;-) and the TuxFleet (a horde of inter-
stellar penguins flying giant Iceberg-shaped glistering StarLiberators,
they cooperate in an alliance with the FSF to fight
Imperator Raw-Ass The Utterly Evil - aka me, in this game I wanna be
 the bad guy)

I'll do the coding till my fingers bleed, but please, please, PLEASE

    can't anyone out there design 3D Models for this game?

I need models with few polygons as possible, in low,mid and high detail,
and with _lots_ of texture, since that's what a modern Gfx-Card
(exept GForce) can take.
You can even create more detail levels in between, but I need
anything that runs on a todays computer (and - in low detail - even
on old ones).
I also dream about running Kobayashi Maru on a PDA running linux -
ever there ever is something like a 'fastGLforPDA' available,
you'd need even low low detail ;-)

I also want to have the plib community to look at ssgUtil.cxx (maybe
there is something to go to plibsg/plibssg) and at class puScrollList
I've implemented - puScrollList even doesn't work correct for me,
but you could take up the Idea and implement a cleanly designed/working
puScrollList (or is there an easier way?)

I also have to say that (for my implementation of puScrollList I badly
need something like puObject->setLegendPlace, in Mission/Model Selection
the scroll-list in the top-right corner looks like shit - the legends
should be aligned to the left (inside the widgets).

Now again thoughts about plibssg performance.
I have not much performance on my Athlon500/Tnt2, some is wasted in
my code (I know exactly where), but a large part is lost in ssgCullAndDraw().
If there is something to be improved in KobScene/KobSceneObject, please
do that.
But the capsulation of the Scenegraph the game uses in KobScene will
make it possible to 'switch' between different Scenegraphs (at least
at compile time).
The aim should be that KobayashiMaru should be able to compile for any
Scenegraph and any Soundhandler at any time.
I'd really like to use a glDoom/glQuake/Quakeforge/Aftershock-based
Scenegraph, if you could give me a pointer to where to find good
docu and easy-to-use examples...
Other Scenegraphs I've thought of are SGI Performer, Crystal Space, 
Genesis3D, PVision, and - as a very very optional native implementation -
Direct3D (urks) would also be possible, if someone is mad enough.
I had yet no time to look at those, can't anyone else do that and
mail me a summary?
What a Scenegraph for KobayasiMaru should be able to do can be seen
by reading kob_scene.h/cxx

At the moment I use plibsl for very very basic sound effects, but for
a game like that I need full-stereo-full-pitching-xxx-channels etc,
even 3D sound will be possible with the right underlying Soundhandler,
but, as like for the Scenegraph, KobayashiMaru will compile at any
time optionally for plibsl , with the limitations plibsl has, of course.
But which other portable open source sound system, that features at
least 4 to 8-channel-stereo with modern soundcards, I don't have
experience in that, the only Idea I have is to have a look at
SDL from Loki. Any other Ideas?


Please reply to the KobayashiMaru Mailing List, I hope I hear
from you.



Alex

Notice: this 'Open Letter' will also be (seperately) mailed to
        the KobayashiMaru mailing-list to archive it
        better use the mailing-list for your answer, to keep it
        in the public

ssgContext bug and remedy (was Re: [Plib-devel] Simple SSG examples)

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

RE: [Plib-devel] Simple SSG examplesThere were a couple of problems with
it - one was my fault (polygon winding issues - should had realised back
face culling was on by default, doh! ), and the other is a bug in ssg.

The ssgContext class initialises the camera matrix to the identity
matrix and not _ssgOpenGLAxisSwapMatrix.  So if you do nothing with the
camera you end up with opengl's coordinate covention (y is up), rather
than ssg's (z is up).

Anyway it works now, so by tomorrow I should have some real simple ssg
examples to contribute.  I've got a simple textured spinning cube, an
explosion, and a simple scene you can fly round (using the quaternion
routines).  Nothing hot, but I always find I learn a damn site quicker
from examples than documentation so I imagine these will be of use to
people.

Sam

Re: [Plib-devel] disappearing texture problem

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

Darrell Walisser wrote:
> 
> >From Brian Speece (ATI), commenting on bug :
> 
> > I can't speak for whether Apple has seen this, but we definitely haven't.
> > We'll download the framework.  It would be great if you could point us to a
> > test case that exhibits the problem.  The RagePro did not support alpha
> > modulate (i.e multiplying the texture alpha by the vertex alpha).  I'm
> > wondering whether this is involved.  In any case, we will look at it, and
> > tell you what we find.
> 
> Does this sound possible, Steve?

Well, I knew about that horrid restriction of the RagePro - and you can actually
see it in action on the screenshot you posted.

Look at the circle of golden herring at the bottom-left of the screen.

On a legal OpenGL implementation, each of those are rendered as 50% transparent
until you have collected that gold herring - and then rendered opaque
after that.  However, the texture alpha is also used to cut out the
shape of the fish - so for the fish you have *not* yet collected, the
50% vertex alpha *should* be multiplied by the texture alpha.

However, in your image, all of the herring are opaque - which either
means you are an EXCELLENT Tux player - or this is an example of the
error that Brian is talking about.

I'd point out that failing to support that means that their implementation
presumably isn't passing the OpenGL compliance test suite - which means that
it's not legally supposed to be called OpenGL!

You see the same vertex alpha bug under Windoze too BTW.

So, no - I don't think that's related to the 'missing opaque surface' bug.

Cutting this down to a manageable test case would be REALLY difficult...

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

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

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

Curtis wrote:

>I like the flight gear FGPath class myself.  

While speaking about portable file- and path-functions:
I would like a function to add two paths. 
Two examples in Windo$ speak:

".\subdir1" plus "subdir2\file.ext" gives
".\subdir1\subdir2\file.ext".

".\subdir1" plus "c:\file.ext" gives  "c:\file.ext" .

Is there such a beast in the flightGear code?
It would be nice if we had something like this in
the coming plib-functions.


>Curt.

Re: [Plib-devel] disappearing texture problem

[Darrell W. <dwa...@pu...>]

From Brian Speece (ATI), commenting on bug :

> I can't speak for whether Apple has seen this, but we definitely haven't.
> We'll download the framework.  It would be great if you could point us to a
> test case that exhibits the problem.  The RagePro did not support alpha
> modulate (i.e multiplying the texture alpha by the vertex alpha).  I'm
> wondering whether this is involved.  In any case, we will look at it, and
> tell you what we find.
> 

Does this sound possible, Steve?

Re: [Plib-devel] ssgVtxArray bug(s) ?

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

Dave McClurg wrote:
> 
> Steve wrote:
> > I was looking in the ssgVtxTable class code and spotted a bug ...
> yikes!
> 
> <snip>
> > I'm suprised that this wouldn't have shown up MUCH earlier.
> > Do I have a crossed wire here - or is this really a bug?
> >
> i think these are really bugs. :(  Mark?
> 
> > Is anyone actually using ssgVtxArray?
> >
> i'm using it heavily since i modified the ssgLoadASE loader to use
> ssgVtxArray for all leaves.  ASE models are already in indexed form.  i
> noticed a 50% frame rate boost on my geforce 256.  thanks Mark!

Yep - that's known to be "A Good Thing" for GeForce.  The other thing
that we need to change for efficiency is to use (IIRC) short's for
normals and char's for colours.   I think we can hack ssgVtxArray to
do that without too many problems.

Once Linux OpenGL implementations start to support the OpenGL ABI, we
can also use the Compiled Vertex Array extension and get still more
speedup.

> i pre-light most of my models and don't use normals.  also, i'm not
> transforming the model yet, just rotating the camera around the model.

The 'transform' member function isn't used for models that you move around
in realtime - it's used for the 'ssgFlatten' optimisation that multiplies
out ssgTransform nodes to cut down on redundant matrix multiplies during
realtime.  But if you aren't using normals, you certainly won't see the
*ORIGINAL* bug - I havn't yet checked ALL the places where the index-array
problem bites.

> that's probably why i haven't seen these bugs yet.  i fixed a few other bugs
> which occured when i passed NULL for the normal array.
> 
> please go ahead and make the fixes if you would be so kind or let me know if
> you don't have time and i'll give it a try.

OK - I'll patch the ones I can recognise.

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

Re: [Plib-devel] Problems, mostly with MSVC 6.0

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

Dave wrote:

>> I also have problems with some of the examples.
>> Many examples don't compile obviously since the the glu(t) stuff isn't
>> linked. For example, this is one of the error messages I get for bend:
>> 
>> Linking...
>> bend.obj : error LNK2001: unresolved external symbol
>> _glutSwapBuffers@0
>> 
>> BTW, for PPE I have glu32.lib in the linker/input-options
>> after opengl32.lib.
>
>i'm not getting that problem with MSVC 6.0
>AFAICT, plib does *not* use glu32.lib.

I just downloaded and tested plib on another computer, with the same
link-problem. Have a look into bend.cxx, the redraw function.
It definitely uses glut.
If you download and compile everything from scratch, I would be
surprised if you could compile the bend example.

BTW, I tried to compile the debug-configuration. In release
configuration, I get even more link-problems. The
release-configuration doesnt even link plib.

>--Dave

--
Bye bye,
Wolfram.

RE: [Plib-devel] ssgVtxArray bug(s) ?

[Dave M. <dp...@ef...>]

Steve wrote:
> I was looking in the ssgVtxTable class code and spotted a bug ...
yikes!

<snip>
> I'm suprised that this wouldn't have shown up MUCH earlier.
> Do I have a crossed wire here - or is this really a bug?
>
i think these are really bugs. :(  Mark?

> Is anyone actually using ssgVtxArray?
>
i'm using it heavily since i modified the ssgLoadASE loader to use
ssgVtxArray for all leaves.  ASE models are already in indexed form.  i
noticed a 50% frame rate boost on my geforce 256.  thanks Mark!

i pre-light most of my models and don't use normals.  also, i'm not
transforming the model yet, just rotating the camera around the model.
that's probably why i haven't seen these bugs yet.  i fixed a few other bugs
which occured when i passed NULL for the normal array.

please go ahead and make the fixes if you would be so kind or let me know if
you don't have time and i'll give it a try.


--Dave

[Plib-devel] ssgVtxArray bug(s) ?

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

I was looking in the ssgVtxTable class code and spotted a bug in the 'transform'
member function. (It was translating the surface normals as well as rotating them!!)

I wondered whether the same bug might be in ssgVtxArray also - which it was - but
that's neither here nor there... but in the process of looking around in that code,
I noticed that in several places there is code like this:

  for ( i = 0 ; i < getNumIndices() ; i++ )
  {
    int ii = *( indices->get(i) );

    ...do something to vertices->get(ii)...
  }

...I'm not entirely up to speed on the ssgVtxArray code - but doesn't that
mean that there is a potential for some vertices to get operated on more
than once?

For example, I might have an index array like this:

   0 1 2 3 3 2 1 0

...if I was drawing two back-to-back quads using GL_QUADS or something.

In some cases (eg computing a bounding sphere), this is just inefficient,
but in the case of the 'transform' function (for example) - it means that
some vertices will get transformed twice just because they are referenced
twice.

I *think* that the code should (in each case) just use the underlying
ssgVtxTable code - which will work fine.

I'm suprised that this wouldn't have shown up MUCH earlier.

Do I have a crossed wire here - or is this really a bug?

Is anyone actually using ssgVtxArray?
                                                                          
-- 
Steve Baker   HomeEmail: <sjb...@ai...>
              WorkEmail: <sj...@li...>
              HomePage : http://web2.airmail.net/sjbaker1
              Projects : http://plib.sourceforge.net
                         http://tuxaqfh.sourceforge.net
                         http://tuxkart.sourceforge.net
                         http://prettypoly.sourceforge.net

Re: [Plib-devel] disappearing texture problem

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

ke...@fl... wrote:
> 
> I've seen the disappearing texture before using a Rage Pro -
> then took the same app to another Mac with a Rage 128, and the
> textures appear.  Just got to have the texture memory on the
> card...

So why do only the alpha textures appear - and how come forcing
them all to be alpha fixes it?

I suppose you could hypothesise that since I render translucent
surfaces after opaque ones (for Z-buffer reasons), the system 
renders the opaque surfaces on the first frame - then the translucent
ones - but since it doesn't have enough texture memory, that
would push the opaque ones out to make room.

THEN, on subsequent frames, the system is too stupid to realise
that the opaque maps are no longer in texture memory and doesn't
reload them - so only the last handful of maps to be rendered
on the first frame are visible subsequently.

So, if that's true - then making all maps have alpha components
(and hence appear to be translucent) would randomize the draw
order - so *perhaps* some OTHER textures are now not being rendered...
but whatever those things are doesn't happen to be so noticable as
the entire terrain AND the hero of the game being missing.

Well, it's an interesting theory.

The way to test it is to get some kind of image processing
program and chop all the texture maps down to (say) 8x8 texels.

Then they should all fit in memory - and even without forcing them
all to have alpha components, you should be able to see every
object in the scene.

Anyway - if that's it then it's CERTAINLY an OpenGL bug that should
be reported.


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

[Plib-devel] disappearing texture problem

[<ke...@fl...>]

I've seen the disappearing texture before using a Rage Pro - 
then took the same app to another Mac with a Rage 128, and the 
textures appear.  Just got to have the texture memory on the 
card...

>> Steve, the disappearing
>> texture problem is back. This may only be an issue for ATI 
Rage Pro cards
>> (looks fine in software). I will have a Voodoo3 to test on in  
a few days,
>> maybe it will work on that ;-)
> 
> It's been a while - about 100,000 emails ago probably!  Can 
you remind
> me of the symptoms?
> 

We added some code to SGI loader so that it always used an alpha 
channel,
even if the SGI file didn't contain an alpha channel. Otherwise, 
the texture
doesn't display, seemingly getting skipped by the renderer. For 
example, in
the opening screen of tux, there is just the water texture at 
the bottom,
tux's feet, and other things that contain alpha channel.

To better illustrate, here is a screen:

http://icdweb.cc.purdue.edu/~walisser/pl
______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!

[Plib-devel] (no subject)

[<ke...@fl...>]

______________________________________________________
Get Your FREE FlashMail Address now at http://www.flashmail.com
It's Free, Easy, & Fun !!!

[Plib-devel] Blender-specific WRL loader

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

i'm going to shelve my development of a Blender-specific WRL loader for a
few weeks to meet a work milestone. if anyone wants to continue the
development, here are the files:
http://www.pond.net/~davem/stuff/blender_import

the test WRL files all came from exporting the tutorial models.  as you can
tell, the blender-specific WRL format is not that hard to handle.  The
switch nodes probably should be placed in an ssgInvisible entity and then
when the visible nodes are encountered you can refer back to the nodes
already created.  I modified the ssgParser.cxx in PLIB CVS already to handle
the format of a WRL file.

If nobody does anything with this, i'll get back on it in a month or so...

BTW- is there anyone else actively working on a VRML import for PLIB?  It's
a beautiful syntax but kind of hard to handle the general case
(Blender-specific vrml 1.0 isn't bad)

--Dave

[Plib-devel] listbox and filepicker

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

i added a listbox and filepicker to pui
in the pui example called complex.cxx i hooked the filepicker to the
menu/save button

one thing i noticed in doing this is that having the callback for one dialog
create another dialog and then delete itself via puDeleteObject has problems
the reason is that pui maintains an interface *stack* in puInterface.cxx
the creation of another dialog precedes the deferred deletion of the old
dialog
which messes up the stack so when the puInterface destructor calls
puPopLiveInterface () ;
it is popping the wrong dialog (ie: the new one) and the old one (which was
destructed)
gets left on the stack.  at least this is what i think is happening.  what
is needed
is a better way to handle this because *chaining* from one dialog to another
ala
linked buttons is pretty common.  any suggestions?

--Dave

Re: [Plib-devel] Simple SSG examples

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

RE: [Plib-devel] Simple SSG examples----- Original Message -----=20
  From: Dave McClurg=20
  To: 'pli...@li...'=20
  Sent: Thursday, August 03, 2000 8:22 PM
  Subject: RE: [Plib-devel] Simple SSG examples


  Without debugging it, I noticed that=20

          // Create a simple state - no lighting, no texuring etc.=20
          ssgSimpleState *state =3D new ssgSimpleState();=20
          state->disable(SSG_GL_LIGHTING_EN);=20

  might be causing problems.  Try this instead:=20

    ssgSimpleState *state =3D new ssgSimpleState () ;=20
    state -> disable ( GL_LIGHTING       ) ;=20

  and maybe add:=20

    state -> disable ( GL_ALPHA_TEST ) ;=20
    state -> disable ( GL_BLEND ) ;=20
    state -> setOpaque () ;=20

I gave that a go, but I didn't have any luck with it.  I also tried =
passing normal and texture ararrys rather than nulls in that was having =
an effect - no joy.  I even tried explicitly setting the camera to the =
orign, and still got nothing.

I'm obviously missing something very basic in my code :/

Thanks for the reply,

Sam

RE: [Plib-devel] Mac Updates/Patches (Tux too!)

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

Steve Baker writes:
>
>Darrell Walisser wrote:
>>  
>> Hopefully that last one doesn't come up too often ;-) We 
>just have to remind
>> developers to always use relative pathnames (even on 
>UNIX/WINDOWS) and we
>> should have no problems.
>
>Iguess that makes sense because:
>
>1) It avoids the drive name issue under Windoze ('C:', etc)

AFAIK there us no why to refer to a file on another disk with
a relative path in windows.

Therefore we need to account for the drivename issue under
Windows but that is an easy on to do.

As Curt pointed out we can just borrow the Path Class from
SimGear.  I was just trying to point out that it might need a 
little tuning yet for some Mac path constructs.
 
Norman

RE: [Plib-devel] Problems, mostly with MSVC 6.0

[Dave M. <dp...@ef...>]

> PPE doesn't compile since the arguments for ssgLoad and ssgSave in the
> header- and the *.cxx-file are different.
> I added the "const" in the parameter-lists in the *.cxx-file and
> had do add a cast. This makes PPE work, but I havent looked whether
> fname should be const or not. Here are the changes for ssgSave,
> ssgLoad is analog (sp?):

thanks for catching this. should be fixed now.

let me know if you see any other 'const' problems
i added alot of 'const' to pui and ssg.
sg was already 'const' correct

> I also have problems with some of the examples.
> Many examples don't compile obviously since the the glu(t) stuff isn't
> linked. For example, this is one of the error messages I get for bend:
> 
> Linking...
> bend.obj : error LNK2001: unresolved external symbol
> _glutSwapBuffers@0
> 
> BTW, for PPE I have glu32.lib in the linker/input-options
> after opengl32.lib.

i'm not getting that problem with MSVC 6.0
AFAICT, plib does *not* use glu32.lib.

> Also, I have the following errors in majik-demo.cxx:

yes. that is broken. i'll try to fix tomorrow.

--Dave

Re: [Plib-devel] Mac Updates/Patches (Tux too!)

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

Darrell Walisser wrote:
> 
> For relative paths, I am pretty sure folders end in ':' and files do not.
> 
> For PLIB, I think we will make all our paths relative. Therefore *all* paths
> will have ':' at the beginning. Since we are not opening directories,
> I don't think we have to worry about trailing ':'
> 
> so UNIX ->  "foo.bar" -> MAC ":foo.bar"
> 
> or "../foo.bar" -> "::foo.bar"
> 
> UNIX -> /usr/local/share -> MAC ":usr:local:share"
> 
> Hopefully that last one doesn't come up too often ;-) We just have to remind
> developers to always use relative pathnames (even on UNIX/WINDOWS) and we
> should have no problems.

Iguess that makes sense because:

1) It avoids the drive name issue under Windoze ('C:', etc)

2) It's unlikely that an absolute path under one OS would even exist
   under another.

> This reminds me, when needing full paths, like for home directory or
> whatnot, I think the usual is to call  getenv ("HOME"). But MacOS has no
> concept of $HOME. In fact, the CodeWarrior C Library function getenv() on
> MacOS always returns NULL.
> 
> I think we should add getHome to our file class.
> The MacOS version can return the path to the preferences folder (global
> place where 99% of Mac apps store settings, hence why mine has 500 some-odd
> files in it ;-) ).

Yes - I think that's a good plan.
 
We'd also need a way to get a path from a 'shell variable' - or whatever
other preferences mechanism you have - that would let (for example) a game
find all it's data files.

Since the preference mechanisms vary - and the path name you get from
that mechanism will be in LOCAL form - not in the form that the
game writer was necessarily expecting - that will have to be handled
within the library.

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

Re: [Plib-devel] makefiles for test programs

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

> Dave McClurg wrote:
> 
> i see, so ./configure adds the link option
> i'm just looking at the Makefile.am (not Makefile) on a windows machine
> it was just odd to see -lplibsg and not -lplibul in Makefile.am

I did it that way so that it would build on pre-ul PLIB versions. The
check at the top of 'configure.in' tests to see if that file exists
and if it does, includes it unconditionally into every link command.

*slightly* inefficient I suppose - but definitely less hassle!

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