plib-devel

Re: [Plib-devel] Vertex array code

[Eric E. <Eri...@fr...>]

"Vallevand, Mark K" wrote:
> 
> Here is the vertex array code for ssg.
>  <<plib.tar.gz>>
> I've included a diff file of changes to existing files, the original
> files, the changed files, and the new files.  There isn't any
> documentation except this email message.  I based the changes
> on plib 1.1.9.-
> 
[...]

Well done, I was planning to do it myself for Torcs.
In order to allow optionnal arrays, I merged the codes
from VtxTable and VtxArray (see the result below)... 

I have also a proposal for VtxTable, I don't know if it is
interesting to do it that way (the number of vertices used to 
switch between the array and the other method should be tuned).

Just an idea for the compiled vertex arrays: it would be interesting to
manage the client states and arrays pointers externally (as textures)
in order to share bigger arrays between leaves and to use index arrays
to select small parts in each leaf.
But this will be more complex to do and need a changes in the structure,
like loading the arrays in a specific parent ssgEntity for example,
and have the client states managed also by the parent ssgEntity.

Eric.


Here is my proposal for the draw_geometry functions (not yet tested).


void ssgVtxArray::draw_geometry ()
{
  int num_colours   = getNumColours   () ;
  int num_normals   = getNumNormals   () ;
  int num_texcoords = getNumTexCoords () ;

  glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;

  if ( num_colours == 0 )
    glColor4f   ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
  else if ( num_colours == 1 ) 
    glColor4fv  ( ( (sgVec4 *) colours->get(0) ) [ 0 ] ) ;
  else if ( num_colours > 1 )
  {
      glEnableClientState ( GL_COLOR_ARRAY ) ;
      glColorPointer ( 4, GL_FLOAT, 0, colours->get(0) ) ;
  }

  if ( num_normals == 1 )
    glNormal3fv ( ( (sgVec3 *) normals->get(0) ) [ 0 ] ) ;
  else if ( num_normals > 1 )
  {
      glEnableClientState ( GL_NORMAL_ARRAY ) ;
      glNormalPointer ( GL_FLOAT, 0, normals->get(0) ) ;
  }
  
  if ( num_texcoords > 1 )
  {
      glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
      glTexCoordPointer ( 2, GL_FLOAT, 0, texcoords->get(0) ) ;
  }
  
  glEnableClientState ( GL_VERTEX_ARRAY ) ;
  glVertexPointer ( 3, GL_FLOAT, 0, vertices->get(0) ) ;

  int i = getNumIndices ();
  int *ii = indices->get(0);
  glDrawElements ( gltype, i, GL_UNSIGNED_INT, ii ) ;

  glPopClientAttrib ( ) ;
}





void ssgVtxTable::draw_geometry ()
{
  int num_colours   = getNumColours   () ;
  int num_normals   = getNumNormals   () ;
  int num_vertices  = getNumVertices  () ;
  int num_texcoords = getNumTexCoords () ;

  sgVec3 *vx = (sgVec3 *) vertices  -> get(0) ;
  sgVec3 *nm = (sgVec3 *) normals   -> get(0) ;
  sgVec2 *tx = (sgVec2 *) texcoords -> get(0) ;
  sgVec4 *cl = (sgVec4 *) colours   -> get(0) ;

  if ( num_vertices < 9 /* To Be Tuned */ )
  {
    glBegin ( gltype ) ;

    if ( num_colours == 0 ) glColor4f   ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
    if ( num_colours == 1 ) glColor4fv  ( cl [ 0 ] ) ;
    if ( num_normals == 1 ) glNormal3fv ( nm [ 0 ] ) ;
  
    for ( int i = 0 ; i < num_vertices ; i++ )
    {
      if ( num_colours   > 1 ) glColor4fv    ( cl [ i ] ) ;
      if ( num_normals   > 1 ) glNormal3fv   ( nm [ i ] ) ;
      if ( num_texcoords > 1 ) glTexCoord2fv ( tx [ i ] ) ;

      glVertex3fv ( vx [ i ] ) ;
    }
 
    glEnd () ;    
  }
  else
  {
    glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;

    if ( num_colours == 0 )
      glColor4f   ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
    else if ( num_colours == 1 ) 
      glColor4fv  ( cl [ 0 ] ) ;
    else if ( num_colours > 1 )
    {
      glEnableClientState ( GL_COLOR_ARRAY ) ;
      glColorPointer ( 4, GL_FLOAT, 0, cl ) ;
    }

    if ( num_normals == 1 )
      glNormal3fv ( nm [ 0 ] ) ;
    else if ( num_normals > 1 )
    {
      glEnableClientState ( GL_NORMAL_ARRAY ) ;
      glNormalPointer ( GL_FLOAT, 0, nm ) ;
    }
  
    if ( num_texcoords > 1 )
    {
      glEnableClientState ( GL_TEXTURE_COORD_ARRAY ) ;
      glTexCoordPointer ( 2, GL_FLOAT, 0, tx ) ;
    }
  
    glEnableClientState ( GL_VERTEX_ARRAY ) ;
    glVertexPointer ( 3, GL_FLOAT, 0, vx ) ;
    
    glDrawArrays ( gltype, 0, num_vertices ) ;
    
    glPopClientAttrib ( ) ;
  }

}

Re: [Plib-devel] TerraPage

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

Brad Colbert writes:
> The link seems to work for me.  It does end in .htm vs. .html.  That
> does tend to cause a transcription error.

Maybe they are suffering from the dreaded "plib-dot effect". :-)

> I've poked around in FlightGear early on but have not kept tabs on
> it's current state.  (I was poking around with the celestial code trying
> to see how hard it was to port to other systems)
> 
> There are some interesting demos that come with the 
> source.  Let me know if you still have problems.

Brad,

The flightgear sun/moon/star/planet code has been all ssg-ified and
separated out.  The goal was to create something that could be easily
dropped into other ssg-based projects.  (I still have one issue with
the moon rendering as I just recently posted, but hopefully Steve or
someone else can provide some insight on that front.)  This
independence of the celestial code is somewhat theoretical and has
never really been put to the test so if you have any questions, or
give it a try and run into any issues please don't hesitate to contact
me.

Regards,

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

Re: [Plib-devel] TerraPage

[Brad C. <bco...@ac...>]

Hi Norman,

The link seems to work for me.  It does end in .htm vs. .html.  That
does tend to cause a transcription error.

I've poked around in FlightGear early on but have not kept tabs on
it's current state.  (I was poking around with the celestial code trying
to see how hard it was to port to other systems)

There are some interesting demos that come with the 
source.  Let me know if you still have problems.

-Brad


>From: "Norman Vine" <nh...@ca...>
> Brad Colbert writes:
> >
> >Is anyone looking into "porting" TerreX's Terrapage terrain paging code
> >over to PLIB?
> >
> >Their source is free (within bounds) and all it needs is the 
> >layer between the paging/memory management to the SSG.
> >
> >http://www.terrex.com/terrapage.htm
> 
> Hi Brad
> 
> Any more info on this.  The above link seems dead
> and I could not find any other info about 'code' on their site.
> 
> BTW
> Have you checked out FlightGear
> http://www.flightgear.org
> It has a fairly simplistic paging mechanism
> but you can fly around the Earth using its
> SSG loading mechanism :^)
> 
> Norman Vine
> 
> 
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
> 

[Plib-devel] ssgSimpleState Question (bug?)

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

Steve,

For my flight gear application I had been noticing some strange
lighting effects where the entire scene would jump to a noticably (and
erroneously) brighter state depending on view direction, pitching the
nose of the plane up, pitching down, etc.  Strange.

Today I was looking a bit closer at what was going on, and it turns
out that this effect happens whenever my moon is visible in the view
frustum.  (i.e. not being culled.)  In otherwords, whenever the moon
gets drawn, my scene gets erroneously brighter.

Looking a bit closer, it appears to be related to how I've set up the
ssgSimpleState for my moon.  Here is the code:

    orb_state = new ssgSimpleState();
    orb_state->setTexture( (char *)path.c_str() );
    orb_state->setShadeModel( GL_SMOOTH );
    orb_state->enable( GL_LIGHTING );
    orb_state->enable( GL_CULL_FACE );
    orb_state->enable( GL_TEXTURE_2D );
    orb_state->enable( GL_COLOR_MATERIAL );
    orb_state->setColourMaterial( GL_DIFFUSE );
    orb_state->setMaterial( GL_AMBIENT, 0.0, 0.0, 0.0, 1.0 );
    orb_state->setMaterial( GL_SPECULAR, 0.0, 0.0, 0.0, 1.0 );
    orb_state->enable( GL_BLEND );
    orb_state->enable( GL_ALPHA_TEST );
    orb_state->setAlphaClamp( 0.01 );

Now if I have the following setMaterial() line commented out, this
weird/erroneous effect goes away (but then my moon isn't drawn
correctly)

    // orb_state->setMaterial( GL_AMBIENT, 0.0, 0.0, 0.0, 1.0 );

Notice that I enable(GL_COLOR_MATERIAL), and then
setColourMaterial(GL_DIFFUSE).  I want the ambient component locked to
black so I can make my dark side of the moon blending work correctly.

Am I making sense?  I realize there is undefined weirdness in the
opengl spec when you mix setColorMaterial() and setMaterial()
... we've been through that enough times.

plib doesn't seem to like it when some of my simple states use
enable(GL_COLOR_MATERIAL) and some don't so I had been standardizing
on using GL_COLOR_MATERIAL.  But, in plib I can't seem to correctly
enable(GL_COLOR_MATERIAL) just for the DIFFUSE component, and set the
ambient component to something else.

Am I missing something here as to proper usage of plib simple states?
Is there some standard way to accomplish what I want to do in plib?

Thanks,

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

RE: [Plib-devel] TerraPage

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

Brad Colbert writes:
>
>Is anyone looking into "porting" TerreX's Terrapage terrain paging code
>over to PLIB?
>
>Their source is free (within bounds) and all it needs is the 
>layer between the paging/memory management to the SSG.
>
>http://www.terrex.com/terrapage.htm

Hi Brad

Any more info on this.  The above link seems dead
and I could not find any other info about 'code' on their site.

BTW
Have you checked out FlightGear
http://www.flightgear.org
It has a fairly simplistic paging mechanism
but you can fly around the Earth using its
SSG loading mechanism :^)

Norman Vine

RE: [Plib-devel] Vertex array code

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

Mark K Vallevand's ssgVtxArray class is in the latest PLIB cvs
if anyone would like to use it or has time to test it.

Thanks Mark!

Mark wrote:
> I've tested the main part of the code, and it works very nicely.  I
> haven't tested things like the highlight or save/load code.  I have
> doubts about the save/load code for any ssg object existing at
> more that one point in the tree, anyway.
> 
> The new class, ssgVtxArray is similar to ssgVtxTable, but it takes
> an additional parameter to its constructor: an index array. The
> index array is a new type, ssgIndexArray, which stores an
> array of integers to use as vertex indices.  The vertex, colour,
> texture coord, and normal arrays used in the ssgVtxArray
> constructor are global, shared arrays.  The index array is the
> list of indices to use for the object.
>

RE: [Plib-devel] Vertex array code

[Vallevand, M. K <Mar...@UN...>]

Thank you.  I'm happy to help.  Especially if I benefit from it
directly. :-) This has really simplified the code in my program
when it manipulates terrain.

Regards. 
Mark K Vallevand   ma...@rs... 
Outside of a dog, a book is man's best friend. 
 Inside of a dog, its too dark to read.  - Groucho 

 

-----Original Message-----
From: Dave McClurg [mailto:Dav...@dy...]
Sent: Monday, May 15, 2000 10:54 AM
To: 'pli...@li...'
Subject: RE: [Plib-devel] Vertex array code



Mark wrote: 
> Here is the vertex array code for ssg. 
>  <<plib.tar.gz>> 
> 
thanks! looks nice. i'll integrate this into the latest CVS 

--Dave McClurg 

[Plib-devel] TerraPage

[Brad C. <bco...@ac...>]

Hey folks,

Is anyone looking into "porting" TerreX's Terrapage terrain paging code
over to PLIB?

I was thinking that it would blow some peoples minds to see large area
terrain paging on a free scene-graph.

Their source is free (within bounds) and all it needs is the layer between
the paging/memory management to the SSG.

http://www.terrex.com/terrapage.htm

Brad Colbert
GreyStone Technology, Inc.
bco...@ac...
(858) 874-7000

RE: [Plib-devel] Vertex array code

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

Mark wrote:
> Here is the vertex array code for ssg.
>  <<plib.tar.gz>> 
>
thanks! looks nice. i'll integrate this into the latest CVS

--Dave McClurg

[Plib-devel] Vertex array code

[Vallevand, M. K <Mar...@UN...>]

Here is the vertex array code for ssg.
 <<plib.tar.gz>> 
I've included a diff file of changes to existing files, the original 
files, the changed files, and the new files.  There isn't any
documentation except this email message.  I based the changes
on plib 1.1.9.-

I've tested the main part of the code, and it works very nicely.  I
haven't tested things like the highlight or save/load code.  I have
doubts about the save/load code for any ssg object existing at
more that one point in the tree, anyway.

The new class, ssgVtxArray is similar to ssgVtxTable, but it takes
an additional parameter to its constructor: an index array. The
index array is a new type, ssgIndexArray, which stores an
array of integers to use as vertex indices.  The vertex, colour,
texture coord, and normal arrays used in the ssgVtxArray
constructor are global, shared arrays.  The index array is the
list of indices to use for the object.  There are also placeholders
for interleaved vertex array support, but that code is a future
project.

There is also too much duplicated code between ssgVtxArray and
ssgVtxTable, from which it is derived.  The code need to be work
over to get more shared code into the base class.  I would
probably need to do that when interleaved vertex support is added.
If interleaved support is never added, I'd be inclined to just leave
it alone.

I don't have cvs access, and probably don't want it.  My network
connection a home is very unreliable unless I am behind the
corporate firewall, and behind the firewall cvs doesn't work.  So,
I'm just passing the code this way.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

Re: [Plib-devel] Q2: Water

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

Chris Purnell wrote:
> 
> On Mon, May 08, 2000 at 06:30:58PM -0500, Steve Baker wrote:
> 
> > Yep - that's more or less what I've done in Tux_AQFH - except that since
> > I had plenty of pixel fill to spare, I just made the water one *HUGE*
> > quadrilateral that runs under all of the terrain and only shows
> > through where the terrain drops below zero altitude.
> 
> > It's not great for a couple of reasons:
> 
> > 1) You can look down into the water and see the bottom just as clearly
> >    as the sides. But once you are in the water, you can't see as far
> >    as you could from above.  It's hard to fix that - but fortunately,
> >    nobody seems to notice!
> 
> People notice, they just don't say anything because commercial games
> are still doing this very badly.  They are used to water that appears
> crystal clear from above then turns murky when entered.  And the other
> extreme where it is hard to see what's below the surface but when you
> enter the water everything lights up a funny colour.
> 
> They way I'd do it is by calcutaing how much water there is between
> the camera and the object on a per vertex basis.  This would be easy
> for the configuation in tux_aqfh.  I'd have a colourless surface
> texture and no changes in the way the scene is lit, coloured or
> fogged when the camera enters or leaves the water.

There is a problem with that though.  Even if you know how much
fog is between the eye and the camera, it's hard to do anything
about that unless your OpenGL supports the vertex-fog-range
extension.  Failing that, you need a multi-pass technique.

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

Re: [Plib-devel] Q2: Water

[Chris P. <cj...@lo...>]

On Mon, May 08, 2000 at 06:30:58PM -0500, Steve Baker wrote:

> Yep - that's more or less what I've done in Tux_AQFH - except that since
> I had plenty of pixel fill to spare, I just made the water one *HUGE*
> quadrilateral that runs under all of the terrain and only shows
> through where the terrain drops below zero altitude.

> It's not great for a couple of reasons:

> 1) You can look down into the water and see the bottom just as clearly
>    as the sides. But once you are in the water, you can't see as far
>    as you could from above.  It's hard to fix that - but fortunately,
>    nobody seems to notice!

People notice, they just don't say anything because commercial games
are still doing this very badly.  They are used to water that appears
crystal clear from above then turns murky when entered.  And the other
extreme where it is hard to see what's below the surface but when you
enter the water everything lights up a funny colour.

They way I'd do it is by calcutaing how much water there is between
the camera and the object on a per vertex basis.  This would be easy
for the configuation in tux_aqfh.  I'd have a colourless surface
texture and no changes in the way the scene is lit, coloured or
fogged when the camera enters or leaves the water.

-- 
Christopher John Purnell  | I thought I'd found a reason to live
http://www.lost.org.uk/   | Just like before when I was a child
--------------------------| Only to find that dreams made of sand
What gods do you pray to? | Would just fall apart and slip through my hands

[Plib-devel] Vertex arrays

[Vallevand, M. K <Mar...@UN...>]

The vertex array code is mostly complete and compiling.  As I type this
note,
I can think of some errors that I need to fix.  I'll test the code in my
program,
and it should be ready sometime next week.

This code should be 'good enough', but when I add more vertex array
features (like interleaved arrays or different storage formats) the code
will
need some rework.  However, I just want to get it working first.

Regards.
Mark K Vallevand   ma...@rs...
Outside of a dog, a book is man's best friend.
 Inside of a dog, its too dark to read.  - Groucho

Re: [Plib-devel] User defined texture formats

[Trent G. <tm...@cy...>]

* Steve Baker <sjb...@ai...> wrote:
> Well, my TUx game (http://tuxaqfh.sourceforge.net) uses the ssgGetAppState
> callback - but not to load different image formats.  Check out 'material.cxx'.

Looks like I missed that. I actually am using your code as a base
for my game, so I should have seen it before :)

I'm using the table like you do in material.cxx but I'm only
putting in textures with special properties and icons for now.
I might put in the most used textures later or something,
but there are a lot of them so I don't think I'll be able to
preload them all.

Thanks for the help, it makes sense to me now.

Re: [Plib-devel] User defined texture formats

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

Trent Gamblin wrote:
> 
> * Steve Baker <sjb...@ai...> wrote:
> > OK - but I don't think this is the place to load textures.
> >
> > Shouldn't this just be the (existing) ssgGetAppState callback?
> 
> I'm really confused. Is there any code or examples that use
> ssgGetAppState to load a different image format? An example would be
> really helpful.

Well, my TUx game (http://tuxaqfh.sourceforge.net) uses the ssgGetAppState
callback - but not to load different image formats.  Check out 'material.cxx'.

However, it goes like this:

  * You set up a function as the callback.

  * Whenever the loader needs to create an ssgState, it
    calls your function with the name of the texture.

  * In your function, you allocate (or choose a pre-allocated)
    ssgState and populate it (which could include loading the
    texture for it).

  * If you return a valid ssgState, the loader will use it for
    that leaf.

  * If you return NULL, the loader will create one for you.

The deal is (IMHO) that loading textures whenever an input
file tells you to is pretty inefficient.  Most games are
likely to load MANY models - and this can easily result
in multiple copies of the texture being loaded - which is
VERY wasteful.

Also, there is frequently a need to attach user data to
an ssgState because your game needs to know other things
about the polygon than just the more obvious visual
properties.

My Tux game stores the coefficient of friction for example,
so that our Penguin Pal can slide down icy slopes.  Since
the needed information isn't in the model file anywhere,
it's necessary for the game code to somehow maintain a
table of what properties belong to what materials.

I pre-load all the textures I think I'm going to need,
create a bunch of ssgSimpleState objects - one for each
pre-designed material.

Then when a model is loaded, if the texture map in the file
agrees with the name of the map on one of my pre-defined
materials, it gets that - otherwise I let the loader
set it up.

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

[Plib-devel] a few more changes

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

changes commited to plib cvs...
 
ssgLoadASE.cxx now uses _ssgCreateLeaf
_ssgMakePath converts '\' to '/'
 
--Dave
 

RE: [Plib-devel] two compiler errors

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

these are now fixed in cvs
--Dave McClurg

> I am having compiler errors on current cvs plib.
> 
> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.1.11\" -DHAVE_LIBGL=1 
> -DHAVE_LIBGLU=1
> -DHAVE_LIBGLUT=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1
> -DLINUX_JOYSTICK_IS_PRESENT=1 -DGLUT_IS_PRESENT=1  -I. -I.  
> -I../../src/sg
> -I../../src/ul    -g -O2 -O6 -Wall -c ssgLoadOBJ.cxx
> ssgLoadOBJ.cxx: In function `void add_mesh(int)':
> ssgLoadOBJ.cxx:325: name lookup of `i' changed for new ANSI 
> `for' scoping
> ssgLoadOBJ.cxx:310:   using obsolete binding at `i'
> make[2]: *** [ssgLoadOBJ.o] Error 1
> 
> to fix it, simply move decl of int i out of for-construct.
> 
> and this one is a bit weird I think, somehow, gcc version 2.95.2
> on PPC want a cast on this line:
> 
> c++ -DPACKAGE=\"plib\" -DVERSION=\"1.1.11\" -DHAVE_LIBGL=1 
> -DHAVE_LIBGLU=1
> -DHAVE_LIBGLUT=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1
> -DLINUX_JOYSTICK_IS_PRESENT=1 -DGLUT_IS_PRESENT=1  -I. -I.  
> -I../../src/sg
> -I../../src/ul    -g -O2 -O6 -Wall -c ssgLoadAC.cxx
> ssgLoadAC.cxx: In function `int do_refs(char *)':
> ssgLoadAC.cxx:518: conversion from `int' to `enum GLenum'
> make[2]: *** [ssgLoadAC.o] Error 1
> 
> 
>    Bram 

[Plib-devel] two compiler errors

[Bram S. <br...@ch...>]

Hello,


I am having compiler errors on current cvs plib.

c++ -DPACKAGE=\"plib\" -DVERSION=\"1.1.11\" -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1
-DHAVE_LIBGLUT=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1
-DLINUX_JOYSTICK_IS_PRESENT=1 -DGLUT_IS_PRESENT=1  -I. -I.  -I../../src/sg
-I../../src/ul    -g -O2 -O6 -Wall -c ssgLoadOBJ.cxx
ssgLoadOBJ.cxx: In function `void add_mesh(int)':
ssgLoadOBJ.cxx:325: name lookup of `i' changed for new ANSI `for' scoping
ssgLoadOBJ.cxx:310:   using obsolete binding at `i'
make[2]: *** [ssgLoadOBJ.o] Error 1

to fix it, simply move decl of int i out of for-construct.

and this one is a bit weird I think, somehow, gcc version 2.95.2
on PPC want a cast on this line:

c++ -DPACKAGE=\"plib\" -DVERSION=\"1.1.11\" -DHAVE_LIBGL=1 -DHAVE_LIBGLU=1
-DHAVE_LIBGLUT=1 -DHAVE_GL_GL_H=1 -DHAVE_GL_GLU_H=1
-DLINUX_JOYSTICK_IS_PRESENT=1 -DGLUT_IS_PRESENT=1  -I. -I.  -I../../src/sg
-I../../src/ul    -g -O2 -O6 -Wall -c ssgLoadAC.cxx
ssgLoadAC.cxx: In function `int do_refs(char *)':
ssgLoadAC.cxx:518: conversion from `int' to `enum GLenum'
make[2]: *** [ssgLoadAC.o] Error 1


   Bram


-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  Bram Stolk               "Linux - Why use windows, if there is a door?"
  work: br...@sa...
  priv: br...@ch...

Re: [Plib-devel] User defined texture formats

[Trent G. <tm...@cy...>]

* Steve Baker <sjb...@ai...> wrote:
> OK - but I don't think this is the place to load textures.
> 
> Shouldn't this just be the (existing) ssgGetAppState callback?

I'm really confused. Is there any code or examples that use
ssgGetAppState to load a different image format? An example would be
really helpful.

RE: [Plib-devel] User defined texture formats

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

> > I did a cvs commit which adds a leaf creation hook to ssgLoadAC.cxx
> 
> OK - but I don't think this is the place to load textures.
> Shouldn't this just be the (existing) ssgGetAppState callback?
> 
> Whenever the loader allocates a new ssgState, it calls that callback
> with the name of the texture map - you can then either share an
> existing ssgState or allocate a new one - complete with correctly
> loaded texture map.
> 
Here is the source from ssgIO.cxx:

ssgLeaf* _ssgCreateFunc ( ssgCreateData* data )
{
  ssgVtxTable *vtab = 0 ;
  if ( data )
  {
    vtab = new ssgVtxTable ( data->gltype,
      data->vl, data->nl, data->tl, data->cl ) ;
    vtab -> setCullFace ( data -> cull_face ) ;

    //an old hack
    if ( _ssgGetAppState != NULL &&
      data -> tfname && data -> tfname[0] != 0 )
    {
      delete data -> st ;
      data -> st = 0 ;

      ssgState* st = _ssgGetAppState ( data -> tfname ) ;
      vtab -> setState ( st ) ;
    }
    else if ( data -> st != NULL )
    {
      ssgSimpleState *st = data -> st ;

      char filename [ 1024 ] ;
      _ssgMakePath ( filename, _ssgTexturePath, data->tfname ) ;

      GLuint texture_handle = _ssgShareTexture ( filename ) ;
      if ( texture_handle )
      {
        /* Don't change the order of these two statements! */
        st -> setTexture         ( texture_handle ) ;
        st -> setTextureFilename ( filename ) ;
 
        st -> enable ( GL_TEXTURE_2D ) ;
      }
      else
        st -> disable ( GL_TEXTURE_2D ) ;
 
      st = _ssgShareState ( st ) ;
      vtab -> setState ( st ) ;
    }
  }
  else
  {
     _ssgShareReset () ;
  }
  return vtab ;
}

I agree that using ssgGetAppState will allow you to load
other texture formats.  But I think it should be phased out
because:

- ssgGetAppState has no access to the original ssgSimpleState
- the leaf creation function is a more general solution
- the redundancy will confuse new users of PLIB
- removing ssgGetAppState will simplify the default _ssgCreateFunc

--Dave McClurg

Re: [Plib-devel] Q2: Water

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

Owen Cliffe wrote:

> you could a series of planes perpendicular to the surface of the water
> with a constant transparency set to somthing low. it would probably ook a
> bit wierd around the edges, but you would get a similar effect to the
> ground fog in Q3.

I figured out a better way to do ground fog than multiple layers of
polygons, but it requires two passes - with two maps applied via
multitexture on the second path....and it's *insanely* complex.

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

Re: [Plib-devel] Q2: Water

[Owen C. <oc...@ec...>]

> Sam Stickland wrote:
> > 
> > > 1) You can look down into the water and see the bottom just as clearly
> > >    as the sides. But once you are in the water, you can't see as far
> > >    as you could from above.  It's hard to fix that - but fortunately,
> > >    nobody seems to notice!
> > 
> > Couldn't you apply another "grey" texture on top on the water, with some
> > half decent alpha values?
> 
> Yes - but there is nothing you can do to the surface of the water that
> allows you the effect of being able to see through (say) 5 feet of
> water - but not through 50 feet.

you could a series of planes perpendicular to the surface of the water
with a constant transparency set to somthing low. it would probably ook a
bit wierd around the edges, but you would get a similar effect to the
ground fog in Q3. 

probably not really worth it tho. 

owen 

Re: [Plib-devel] User defined texture formats

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

> Dave McClurg wrote:
> 
> Trent Gamblin wrote:
> > I think SSG needs to have some hooks to allow user defined image
> > formats...
> 
> I did a cvs commit which adds a leaf creation hook to ssgLoadAC.cxx

OK - but I don't think this is the place to load textures.

Shouldn't this just be the (existing) ssgGetAppState callback?

Whenever the loader allocates a new ssgState, it calls that callback
with the name of the texture map - you can then either share an
existing ssgState or allocate a new one - complete with correctly
loaded texture map.

> This should allow you to load the image formats you need.  This hook
> should allow you to do other things like:
> 
> - load compressed or volumized textures
> - strip off full paths from texture filenames
>     i use that for ASE files because the modeler stores full paths
>     whereas Steve likes a path that starts with '/' to be left alone.

Both are more appropriate for ssgGetAppState.

> - cull unwanted geometry or texture info
> - recompute normals

Yep - these are good reasons for a leaf callback.

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

Re: [Plib-devel] Q2: Water

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

> Dave McClurg wrote:
> 
> in ssg.h i found
> 
> > virtual int getCareAbout ( int mode ) { return dont_care & (1<<mode) ; }
> 
> doesn't that seem negated?

Yes - it does doesn't it.

It's suprising that things would work as well as they do with that error!
Let me spend some more time reading the code to see what's going on here.

> also, there are a couple old hacks/hooks in the model loaders:
> 
> 1) hookfunc
> typedef ssgBranch *(*ssgHookFunc)(char *) ;
> ssgEntity *ssgLoadXXX ( char *fname, ssgHookFunc hookfunc = NULL,
>         ssgCreateFunc createfunc = NULL ) ;
> 
> 2) _ssgGetAppState
> ssgState *( *_ssgGetAppState)( char *) = NULL ;
> void  ssgSetAppStateCallback ( ssgState *(*cb)(char *) ) ;
> 
> Are these hooks still used?  #1 is only implemented in ssgLoadAC::do_data
> so it seems odd to have it passed to all loaders.  #2 could be easily
> replaced with a leaf creation function.  Perhaps they could go away in
> Plib 1.3 ??

Perhaps - LOTS of apps use ssgGetAppState - and several of my programs
use both...that they are missing in the other loaders is an omission
in those loaders - not an indication of redundancy in LoadAC.

For 1.3, it's possible that we should re-organize these into a more
coherent set of things.  I implemented 'hookfunc' first (as a parameter
to the loader) and later realised that I needed getAppState too - but I
didn't want to destroy compatibility by adding another parameter - so
I used the registration function instead.

There are plainly good reasons to add other callbacks too - so we should
think this out a bit better in 1.3 and later.

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

Re: [Plib-devel] Q2: Water

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

Sam Stickland wrote:
> 
> > 1) You can look down into the water and see the bottom just as clearly
> >    as the sides. But once you are in the water, you can't see as far
> >    as you could from above.  It's hard to fix that - but fortunately,
> >    nobody seems to notice!
> 
> Couldn't you apply another "grey" texture on top on the water, with some
> half decent alpha values?

Yes - but there is nothing you can do to the surface of the water that
allows you the effect of being able to see through (say) 5 feet of
water - but not through 50 feet.

Once underwater, we can turn on murky blue/green/brown fog and get something
like that effect.

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