plib-devel

Re: [Plib-devel] import/export

[<Va...@t-...>]

Dave McClurg wrote:
> 
> looking at IVCON and AC3D,
> i'm trying to figure out what would be the most useful formats
> to add to PLIB next.  here are some quick and easy choices:
> 
> - POV file "#version 3.0" EXPORT ONLY!
> 
> i'm using IVCON because the code is pretty clean without alot of dependencies
> and it will quickly allow PLIB to support more formats.

Does the POV export support textures? AFAIK is POV 3.0 unable to support
uv-mapping...

CU,
Christian

[Plib-devel] AC3D Triangle load/save

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

I commited ssgLoadTRI and ssgSaveTRI
ssgLoad and ssgSave also look for TRI file extension

these functions handle TRI files from AC3D

--Dave

RE: [Plib-devel] SLERP

[Michael K. <neg...@ea...>]

I fixed a lot of mistakes in the Quaternion code and sent them to Steve. I
suspect he put them into the CVS tree but I actually havent check up on him
=)

I fixed errors in 3 functions and now everything works fine from what I can
tell. I even sent Steve a demo of a quaternion camera. I'm not at home or
I'd send the updates again but the essence was someone had

X*X + X*Y + Z*Z + W*W
in two functions which should be Y*Y

And the mult function was REALLY off, but it appears from your message you
found those mistakes.


-mike

[Plib-devel] import/export

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

looking at IVCON and AC3D,
i'm trying to figure out what would be the most useful formats
to add to PLIB next.  here are some quick and easy choices:

- Wavefront OBJ (not sure which version)
- SoftImage HRC file. "HRCH: Softimage 4D Creative Environment v3.00"
- Inventor file "#Inventor V2.0 ascii" 
- VRML 2.0 file "#VRML V2.0 utf8"  EXPORT ONLY!
- POV file "#version 3.0" EXPORT ONLY!

i'm using IVCON because the code is pretty clean without alot of dependencies
and it will quickly allow PLIB to support more formats.

Are any of these formats dead (no longer used much) ?
Any requests for one of the above formats ?

--Dave

PS: Other formats such as lightwave and X,
I don't have the time to tackle right now but if you know of
a free loader that exists, please let me know

[Plib-devel] DXF load/save

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

I commited ssgLoadDXF and ssgSaveDXF
ssgLoad and ssgSave also look for DXF file extension
DXF lines and faces are both supported

--mcdave

[Plib-devel] SLERP

[Philippe C.D. R. <ro...@ia...>]

Hi,

I am new to this list, so please forgive me 'dumb' questions. 

I am working on a scenegraph API of my own (http://feivel.unibe.ch/~robert),
and therefore I have a closer look to everything that is out there and useful.
In this process I came across the quaternion functions in sg and saw some wrong
implemented functions (mainly SLERP and multiplication). It seems that
everything out there related to quats is derived from the same source,since
even gamasutra printed the wrong functions...;-)
Has anybody fixed those yet, or ...?! Steve told me there was somebody working
on this, am I correct? I have fixed the multiplication, but SLERP still doesn't
work. So any input would be great.

thx!

sweet dreams, Phil
-- 
Philippe C.D. Robert | http://www.iam.unibe.ch/~robert/

Research Group Computational Geometry and Graphics
Institute of Computer Science and Appl. Mathematics (IAM), Office 205
Neubrueckstrasse 10, CH-3012 Bern Switzerland, phone: +41 31 6313321

Re: [Plib-devel] ssg sky

[Durk T. <d.t...@di...>]

Curtis L. Olson wrote:

> Dave McClurg writes:
> > Curt wrote:
> >
> > >     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
> > >
> > >I'm designing this in such a way that you can use a separate module
> > >that calculates the real positions of the sky objects so you can have
> > >a live dynamic sky that will precisely match the real world.
> >
> > cool! glad to see your hard work paid off.
> > is this intended for possible inclusion in ssg or a ssg example
> > or will it be only in flightgear.
>
> Dave,
>
> I'd certainly offer it up for potential inclusion in plib/ssg, but the
> decision would be up to Steve.  My interests are more simulation
> oriented rather than game oriented.  I've been considering putting
> together my own package of things that would sit a level up from plib,
> or be out of the scope of plib ... things like a drop in sky, terrain
> rendering/paging tools, or even a collection of vehicle dynamics
> codes.
>
> I'm thinking it would be nice to have plib + my_package = getting your
> simulation project off the ground quickly.
>

Well since this is my first post to the plib list, a quick introduction (for
people who are not subscribed to any flightgear list). The original (non
plib/ssg)  version of the astronomy code was written by me, approx. between
1997 and 1998. And in addition to this, I also worked on some other parts of
the FlightGear projects, mainly involving time code, some gui work, as well
adding a preliminary form of clouds. Because I haven't had much chance to
contribute lately, I haven't worked with plib that much.

The code that calculates the right position of the sun, moon, and planets
currently pretty much intertwined with the rest of FlightGear, and one of my
intentions is to seperate this from the core of the simulator code. Because
Astronomy and time code is pretty much intertwined, I'm currently thinking of
reorganizing this into a single time/astromomy lib. Though I'm open to
including this code in plib as well, I'm not sure if this is the right place
for this lib to go.

Eventually, I'd like to develop some code that is also suitable for use in
stuff like a Space Flight simulator, and this would impose an additional
demand on the lib. My first choice in that case would be to include the
Astronomy and Time code in something like Curt's SimGear lib. As said, I'm
open to suggestion.

Regards,
Durk

Re: [Plib-devel] ssg, transparent textures, and blending

[Durk T. <d.t...@di...>]

Curtis L. Olson wrote:

> Ok, I literally want to cry. :-)
>

Curt,

Think of it this way: If a moron is capable of writing a flight simulator,
imagine what a man who's in his right mind can do...

:-) :-) :-)

> Specifying an alpha of 1.0 in my ssgColourArray makes all my problems
> go away and suddenly everything works the way it's supposed to.  The
> sun came out, the birds started to sing, yada, yada ...

Yes, the end result turns out really nice

RE: [Plib-devel] ssg sky

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

Dave McClurg writes:
> Curt wrote:
> 
> >     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
> >
> >I'm designing this in such a way that you can use a separate module
> >that calculates the real positions of the sky objects so you can have
> >a live dynamic sky that will precisely match the real world.
> 
> cool! glad to see your hard work paid off.
> is this intended for possible inclusion in ssg or a ssg example
> or will it be only in flightgear.

Dave,

I'd certainly offer it up for potential inclusion in plib/ssg, but the
decision would be up to Steve.  My interests are more simulation
oriented rather than game oriented.  I've been considering putting
together my own package of things that would sit a level up from plib,
or be out of the scope of plib ... things like a drop in sky, terrain
rendering/paging tools, or even a collection of vehicle dynamics
codes.

I'm thinking it would be nice to have plib + my_package = getting your
simulation project off the ground quickly.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] ssg sky

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

Curt wrote:

>     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg
>
>I'm designing this in such a way that you can use a separate module
>that calculates the real positions of the sky objects so you can have
>a live dynamic sky that will precisely match the real world.

cool! glad to see your hard work paid off.
is this intended for possible inclusion in ssg or a ssg example
or will it be only in flightgear.

--mcdave

[Plib-devel] ssg sky

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

For those of you not familiar with flight gear, here is a quick screen
shot of the sky elements I am working on building with ssg.  These
things should just depend on plib (and have no flightgear
dependencies.)

     http://www.menet.umn.edu/~curt/tmp/tux-sky-demo.jpg

I'm designing this in such a way that you can use a separate module
that calculates the real positions of the sky objects so you can have
a live dynamic sky that will precisely match the real world.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssg, transparent textures, and blending

[Per L. <li...@ho...>]

On Sun, 05 Mar 2000, Curtis L. Olson wrote:
> Quick check the docs so I have some juicy proof for the public
> lynching ... and sure enough there it is ... you are supposed to build
> the ssgColourArray out of ssgVec__4__!  I'm a complete moron!  I've
> been building my all my color lists out of ssgVec__3__ leaving the
> alpha to default to 0.  Yikes!  Did I mention I'm a complete moron.
> 
> Specifying an alpha of 1.0 in my ssgColourArray makes all my problems
> go away and suddenly everything works the way it's supposed to.  The
> sun came out, the birds started to sing, yada, yada ...

It's things like this that makes me wonder why I have chosen this profession -
sometimes it seems that programming is really all about banging your head
against the monitor for hours / days / weeks just because you missed one figure
somewhere in hundreds/thousands of lines of code.

Still, I just come back for more :-)

I'm happy to hear that you made it through!

Regards,
Per

-- 
   / Per Liedman
  / li...@ho...
 / www.mdstud.chalmers.se/~md6pl
/ 031-825659 / 0705-520455

[Plib-devel] ssg, transparent textures, and blending

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

Ok, I literally want to cry. :-)

I've spent the last 4-5 days struggling with ssg, opengl states,
textures with alpha transparency, and blending ... nothing was working
right for me.  Everything was going screwy at every step of the way.
This has to have ranked right up there with the frustration level of
sorting out matrix tranformations.  You think you know how it works,
you've studied it in school, you got A's on your test, you've made
this stuff work before, but here's this proof laughing in your face,
this piece of non-working code that is saying you are obviously a
clueless idiot.

Ok, so I could get everything working correctly ... right up to the
point where I tried to enable either blending or alpha_test and blam,
my object would go away.  This morning I said to myself, "you know
Curt, it almost looks like opengl/ssg is honoring the alpha of the
underlying quad, and completely ignoring the alpha of your perfectly
good texture."

Hmmm ... interesting thought ... what is the alpha of my underlying
quad?  I suppose, if I'm GL_MODULATING my texture, the texture's alpha
would get modulated with the underlying quad's alpha, just like it is
with the RGB values.

Hmmm ... but if you build an ssgVtxTable ssgColourArray out of ssgVec3
there would be no way to specify an alpha component.  A huge obvious
oversite in the design of ssg.  If Steve wasn't on vacation I'd tear
him to shreds over this ... he just wasted the last week of my life.

Quick check the docs so I have some juicy proof for the public
lynching ... and sure enough there it is ... you are supposed to build
the ssgColourArray out of ssgVec__4__!  I'm a complete moron!  I've
been building my all my color lists out of ssgVec__3__ leaving the
alpha to default to 0.  Yikes!  Did I mention I'm a complete moron.

Specifying an alpha of 1.0 in my ssgColourArray makes all my problems
go away and suddenly everything works the way it's supposed to.  The
sun came out, the birds started to sing, yada, yada ...

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] Typo in ssg source???

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

Steve,

This is in plib-1.1.11 (src/ssg/ssgImageLoader.cxx)

void ssgImageLoader::make_mip_maps ( GLubyte *image, int xsize,
                                                 int ysize, int zsize )
{
  GLubyte *texels [ 20 ] ;   /* One element per level of MIPmap */

  for ( int l = 0 ; l < 20 ; l++ )
    texels [ 0 ] = NULL ;

             ^----> should this be "l"?

You compensate for this later so the code should run ok, but I just
thought I'd point this out.

Regards,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] desperate plea for help (SKYBOX)

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

Dave McClurg writes:
> a worthy goal.  indeed, a clean solution would be of interest to
> everyone.  perhaps you should get it all working using straight
> glut/opengl first and then integrate with ssg so you keep it simple
> until it works.

Actually it is all pretty much working with hand crafted opengl.  My
problem is struggling with ssg and state handling ... or maybe mixing
ssg's state handling with random hard coded state changes sprinkled
throughout the code.  This is what I'm trying to clean up.

> the best tutorial on creating skyboxes can be found at
> http://www.gamasutra.com/features/visual_arts/19981023/skybox_01.htm
>
> also, i saw that crystal space http://crystal.linuxgames.com just added
> some skybox code they claim works

Right now I'm implimenting a sky dome (this is for a flight
simulator.)  But it would be interesting to add a skybox option
sometime as well.

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] desperate plea for help

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

Norman Vine writes:
> Curtis L. Olson writes:
> >
> >Ok, I've been beating my brains on this for the last 48 hours and I'm
> >about ready to give up (except I can't, so I keep bashing my head on
> >it.)  I'm hoping that some kind soul will have pity on me and help me
> >out.
>
> Ouch that has gotta hurt.
> Since the grandmaster is out of ear shot
> I'll do my best :).
>
> >
> >I'm sure I'm doing something stupid someplace, but for the life of me
> >I can find out what that is.
>
> Try moving the current_sun.initialize(); call
> to someplace after ssgInit();
> like the end of

Ahh, yes that helped tons ... thanks!

> BTW
> You should look into using the new ssgContext class.
>
> Hope this helps you get some sleep :)

Ok ... I'll take a look at that.

Regards,

Curt.
--
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

RE: [Plib-devel] desperate plea for help (SKYBOX)

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

Curt wrote:

>My ultimate goal is to build a nice generic sky with sun, moon, stars,
>haze at the horizon, etc. all within the structure of ssg.  I'm doing
>this for the FlightGear project, but I'm hoping that when I'm done
>this could be a quick easy drop in for others who want to add a
>decent/realistic sky quickly to their ssg-based projects. (with the
>possibility of having all the astronomical objects placed correctly
>for time and view position.)  Every one needs this because even indoor
>worlds have windows, right? :-) I'm a good ways along with this
>effort, but I've hit a problem with texturing.

a worthy goal.  indeed, a clean solution would be of interest to everyone.
perhaps you should get it all working using straight glut/opengl first and
then integrate with ssg so you keep it simple until it works.

the best tutorial on creating skyboxes can be found at
http://www.gamasutra.com/features/visual_arts/19981023/skybox_01.htm

also, i saw that crystal space http://crystal.linuxgames.com just added
some skybox code they claim works

--mcdave

RE: [Plib-devel] desperate plea for help

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

Curtis L. Olson writes:
>
>Ok, I've been beating my brains on this for the last 48 hours and I'm
>about ready to give up (except I can't, so I keep bashing my head on
>it.)  I'm hoping that some kind soul will have pity on me and help me
>out.

Ouch that has gotta hurt.
Since the grandmaster is out of ear shot
I'll do my best :).

>
>I'm sure I'm doing something stupid someplace, but for the life of me
>I can find out what that is.

Try moving the current_sun.initialize(); call 
to someplace after ssgInit();
like the end of 

BTW
You should look into using the new ssgContext class.

Hope this helps you get some sleep :)

Norman

[Plib-devel] desperate plea for help

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

Ok, I've been beating my brains on this for the last 48 hours and I'm
about ready to give up (except I can't, so I keep bashing my head on
it.)  I'm hoping that some kind soul will have pity on me and help me
out.

I'm sure I'm doing something stupid someplace, but for the life of me
I can find out what that is.

My ultimate goal is to build a nice generic sky with sun, moon, stars,
haze at the horizon, etc. all within the structure of ssg.  I'm doing
this for the FlightGear project, but I'm hoping that when I'm done
this could be a quick easy drop in for others who want to add a
decent/realistic sky quickly to their ssg-based projects. (with the
possibility of having all the astronomical objects placed correctly
for time and view position.)  Every one needs this because even indoor
worlds have windows, right? :-) I'm a good ways along with this
effort, but I've hit a problem with texturing.

I've tried to boil this problem down to an example that is as simple
as I can get it.  What I've done is try to build a simple object
(square), texture it with the "wood.rgb" texture for now, and add it
into the sky in the plib "tux" example program.

I'm attaching my changes to the "tux" example program (from the
plib_examples-1.1.8 distribution).  It's about 4k compressed (4 small
files) so hopefully I'm not blatantly violating list ettiquete.  This
includes a replacement Makefile.am, a replacement tux_example.cxx and
two new files: skysun.cxx and skysun.hxx.

Just untar this over top the examples/ssg/tux directory and you should
be able to build it.

You should see a wood textured square in the sky, but you don't.  This
is the problem.  Instead, you'll see a solid white square in the sky.
If anyone can tell me why the texture isn't getting applied and what I
can change to make this work, I will owe you a virtual beer ... no
make that a virtual 6 pack.  By tomorrow I may be handing out first
born sons.

I'm guessing this problem is centered around a screwed up opengl state
configuration, but I'm stuck ... I've tried everything I can think of.
The worst part is that I've gotten all kinds of texturing to work in
the FlightGear project ... I just can't get it to work in this simple
example.

Help!

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

[Plib-devel] I'm outta here.

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

Hi!

  I'm off on a much needed vacation for two weeks - so I'll basically
be uncontactable until about 18th March.

  So if there are any plaintive pleas for help from newbies - perhaps
one of you more experienced users would offer a helping hand.

  Thanks.

       Steve

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

[Plib-devel] Patch

[Loring H. <ls...@cs...>]

Hope this is the right place to send patches.  The following is a patch to
the cvs tree for core plib, I also have a patch for plib_examples, but I
didn't see that in the cvs tree - should I just send the patch relative to
the tarball?

This patch allows plib to be compiled when:
* Using a an old version of g++ that does not define FLT_EPSILON
* glut is installed in a non-standard place
* X11 include files and libraries are not in the standard location
* X11 include files/libraries are in a non-standard location and GL include
files and libraries are located in the same place (/usr/X11R6/include/GL, for
example)

With these changes I was able to build plib and the examples under Solaris,
Linux, and AIX (except for the sound library under AIX).

Loring


RCS file: /cvsroot/plib/plib/configure.in,v
retrieving revision 1.2
diff -u -r1.2 configure.in
--- configure.in	2000/02/15 23:28:50	1.2
+++ configure.in	2000/03/02 22:52:38
@@ -27,6 +27,26 @@
 AC_PROG_INSTALL
 AC_PROG_RANLIB
 
+dnl Command line arguments
+AC_ARG_WITH(glut,
+[  --with-glut=DIR         set the prefix directory where GLUT resides],
+GLUT_PREFIX=$withval, GLUT_PREFIX=auto)
+
+AC_ARG_WITH(glut-includes,
+[  --with-glut-includes=DIR
+                          set the directory where GLUT include files reside],
+GLUT_INCLUDES=$withval, GLUT_INCLUDES=auto)
+if test "x$GLUT_INCLUDES" != "xauto"; then
+    CPPFLAGS="$CPPFLAGS -I$GLUT_INCLUDES" 
+else
+    if test "x$GLUT_PREFIX" != "xauto"; then
+        CPPFLAGS="$CPPFLAGS -I$GLUT_PREFIX/include"
+    fi
+fi
+if test "x$GLUT_PREFIX" != "xauto"; then
+    LIBS="$LIBS -L$GLUT_PREFIX/lib"
+fi
+
 dnl Checks for library functions.
 dnl check for OpenGL related libraries
 
@@ -39,6 +59,9 @@
     AC_PATH_XTRA
 
     x_suffix="$X_LIBS $X_PRE_LIBS -lX11 -lXi -lXext -lXmu $X_EXTRA_LIBS -lm"
+    if test "x$x_includes" != "x"; then
+       CPPFLAGS="$CPPFLAGS -I$x_includes"
+    fi
 
     dnl Reasonable stuff non-windoze variants ... :-)
 
Index: src/sg/sgIsect.cxx
===================================================================
RCS file: /cvsroot/plib/plib/src/sg/sgIsect.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 sgIsect.cxx
--- src/sg/sgIsect.cxx	2000/02/01 05:52:26	1.1.1.1
+++ src/sg/sgIsect.cxx	2000/03/02 22:52:38
@@ -7,6 +7,11 @@
 #define FALSE 0
 #endif
 
+/* Defined in float.h in later versions of egcs */
+#ifndef FLT_EPSILON
+#define FLT_EPSILON 1.19209290e-07f
+#endif
+
 /*
   Determine the origin and unit direction vector of a line
   formed by the intersection of two planes.

[Plib-devel] Another Open Source scene graph...

[Gil C. <g.c...@ca...>]

Hi,

I've been on Wes Bethel's mailing list for his RM scene graph product for a 
while now, and he's recently decided to produce a subset open source 
version called OpenRM.  It sounds pretty nice, although it's not clear what 
extras the full RM product available for purchase gives that this version 
doesn't.

Anyhow, have a look at http://openrm.sourceforge.net/ if you're interested 
to see what he's doing.

Regards,

Gil

[Plib-devel] ssg color question

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

Steve,

I have a color question for you.

I seem to get the expected results (correct colors) when I create a
state with:

  enable( GL_COLOR_MATERIAL )
  setColourMaterial( GL_AMBIENT_AND_DIFFUSE )

And then I feed in my desired color array when I create the VtxTable.

Now, I have a multi-VtxTable object (a sphere where each slice is a
separate triangle strip.)  I would like to be able to control the
color of this object by just modifying the associated state.  My first
attempt was to pass in a NULL color array when I create the VtxTables.
My state was set up with:

  disable( GL_COLOR_MATERIAL );
  setMaterial( GL_AMBIENT_AND_DIFFUSE, 1.0, 1.0, 1.0, 1.0 );

However, if I later go and update the Material color in the state, the
rendered object color doesn't change.

I know we already did the rounds on this with David Megginson (but I
wasn't paying attention at the time ... <slap, slap>)

Should my approach work, or am I missing something obvious?  From a
brief look at the code, I wonder if ssg is overriding the state's
color for objects that have no color list defined?

Any thoughts ... or should I just avoid setting global material colors
and stick with enable(GL_COLOR_MATERIAL) and modify the color array?

Thanks,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-devel] ssg states followup

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

"Curtis L. Olson" wrote:

> > It would be a pretty weird application that needed to switch
> > Fog and Depth-test on a per-leaf-node basis.
> 
> The place where I'm running into this is with drawing the skydome,
> stars, sun, moon, etc.  I'm half modelling and half illusioning so I
> need to play some tricks.  But, it's not a big deal.  As long as I
> understand exactly what ssg does / doesn't, I can make things work.

Yep. Bear in mind that you can have SSG call your own callback functions
both before and after drawing a leaf node.
 
> Ok, so the best I can tell from the documentation, here is the
> complete enumeration (internal names) of the states that ssg can
> control:
> 
>   SSG_GL_TEXTURE_EN
>   SSG_GL_CULL_FACE_EN
>   SSG_GL_COLOR_MATERIAL_EN
>   SSG_GL_BLEND_EN
>   SSG_GL_ALPHA_TEST_EN
>   SSG_GL_LIGHTING_EN
> 
> Is this the complete list of modes ssg can control?

That's the complete list of glEnable/glDisable's - yes.  Of course
there are other GL *state* elements - like the current texture - that
SSG controls also.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjb...@ai... (home)  http://www.woodsoup.org/~sbaker
sj...@ht...      (work)

Re: [Plib-devel] ssg states followup

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

"Curtis L. Olson" wrote:
> > Ok, one more question.  Is it legal to use ssgSimpleStates to control
> > *all* the states that you can glEnable and glDisable?  I'm thinking
> > about things like GL_FOG, GL_DEPTH_TEST, GL_CULL_FACE, etc.

Steve Baker writes:
> No - I had great heartache over that.  I decided to stick to those
> states that you are likely to want to set and unset rapidly in a
> 'typical' application.  That keeps to a minimum the amount of state
> *testing* for each leaf node as it's rendered.
> 
> It would be a pretty weird application that needed to switch
> Fog and Depth-test on a per-leaf-node basis.

The place where I'm running into this is with drawing the skydome,
stars, sun, moon, etc.  I'm half modelling and half illusioning so I
need to play some tricks.  But, it's not a big deal.  As long as I
understand exactly what ssg does / doesn't, I can make things work.

> Of course GL_CULL_FACE is set per ssgLeaf node - so you don't want
> to mess with ssgState's for that.

Ok, so the best I can tell from the documentation, here is the
complete enumeration (internal names) of the states that ssg can
control:

  SSG_GL_TEXTURE_EN
  SSG_GL_CULL_FACE_EN
  SSG_GL_COLOR_MATERIAL_EN
  SSG_GL_BLEND_EN
  SSG_GL_ALPHA_TEST_EN
  SSG_GL_LIGHTING_EN

Is this the complete list of modes ssg can control?

Thanks,

Curt.
-- 
Curtis Olson   University of MN, ME Dept.       Flight Gear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org