plib-devel

RE: [Plib-devel] Fixes for ssgVtxArray.cxx

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

No problem Mark.  I don't mind integrating patches into plib for anyone
who doesn't want cvs access.

If you find time to incorporate Eric Espie's mods into the vertex classes,
let me know, and i'll do the commit.

Steve- it sure would be nice to put the plib_examples in cvs so they could
be enhanced, fixed, and added to.  I wouldn't mind seeing a example of
skeletal animation, sun/moon/sky, or water using ssg/plib.  perhaps taking
some nice pieces of code out of flightgear and tux_aqfh.  good
demos/examples go a long way.

--Dave McClurg

RE: [Plib-devel] Fixes for ssgVtxArray.cxx

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

Thankyew.  Thankyew, very much
 

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 

done. 

RE: [Plib-devel] Fixes for ssgVtxArray.cxx

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

done.

> Additional testing has found some bugs in the Vertex Array 
> code in ssg.
> 
> Here is the corrected ssgVtxArray.cxx.  Can some kind soul 
> check it into cvs?
>  <<ssgVtxArray.cxx>> 
> 
> Regards.
> Mark K Vallevand   ma...@rs...

[Plib-devel] Fixes for ssgVtxArray.cxx

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

Additional testing has found some bugs in the Vertex Array code in ssg.

Here is the corrected ssgVtxArray.cxx.  Can some kind soul check it into
cvs?
 <<ssgVtxArray.cxx>> 

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

[Plib-devel] A COLOR_MATERIAL test case.

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

OK - I've spent some time to write a nice, simple test case to
allow us to better discuss the color material problem in a
clear manner.  The program is derived from a logo competition
entry at work - and I've applied nice simple textures and
deliberately screwed with the polygon ordering to make for
LOTS of state switching.  It's also timed to run no faster
than 60Hz with a nasty hack - try to ignore that - I was in
a hurry.

So - Compile 'logo.cxx' using the attached Makefile.
Run it in the same directory as the two texture maps I provide.

You should see a little animation of some origami - with spots
on one side of the paper and stripes on the other.  Admire it
for a while...fun isn't it!

OK - so now you can play around by editing logo.cxx and rebuilding
it.

* Go to line 446 - notice that the vertex colours are alternating
  between white and magenta (see the 'i & 1' part?).
  You don't see that in the animation because glColorMaterial is *not*
  enabled and White is the default glMaterial colour.

* At line 497 you can see where I set up two material properties
  - one for the spotted side of the paper, the other for the
  stripes.  Try changing *one* of the 'disable(GL_COLOR_MATERIAL)'
  calls to an 'enable'.  Running the program again will show
  that one side of the paper is now covered with purple splotches.

  This is good.  It's working just fine.

* Now try enabling GL_COLOR_MATERIAL for *both* sides of the
  paper - and change the 'setMaterial(GL_EMISSION...)' calls to
  make one side of the paper emit (say) Blue light and the other
  side (say) Red.  You might want to change the vertex colours
  to darker values to make this more obvious (because White+Anything
  is still White) - but even without doing that it's obvious in
  the shadowed areas.

  According to Curt's theory, this test should fail because we'd
  be making glMaterial calls while GL_COLOR_MATERIAL is enabled.

  But guess what?  It works OK!

Now, that's on a GeForce card with the nVidia Linux drivers. YMMV.

In fact, I tried a dozen things - and SSG performed flawlessly in
all situations....which suprised me quite a bit because other
programs that I've written HAVE shown problems that appear to be
GL_COLOR_MATERIAL related.

  8-P

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

Re: [Plib-devel] ssgSimpleState Question (bug?)

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

"Curtis L. Olson" wrote:

> Can you tell me the proper way inside of ssgSimpleState to
> enable/disable GL_COLOR_MATERIAL along with which variable should get
> it's bits twiddled on/off?

The SimpleState class contains two bitfields: 'dont_care' and 'enables'.

Each has one bit for each state that SimpleState manages.  If the
dont_care flag is set, simplestate won't bother to manage that state
element - if we *do* care about a state element then 'enables' tells
you if this state object wants that state enabled or not.

There is an SSG_GL_COLOR_MATERIAL that contains the position of
the bit for colour material within that flag word.

There is a special 'magical' ssgSimpleState that SSG uses
internally to hold the current state of OpenGL (we hope!), that's
called _ssgCurrentContext.

When a normal state is 'applied' (by virtue of a leaf node that needs
it being drawn for example), it compares it's enables with that of
_ssgCurrentContext - masks off the differences and dumps the ones
it doesn't care about.  The resulting set of changes are then
scanned and glEnable/glDisable calls made as needed to update
OpenGL.

For things that are not glEnable/glDisable's, there are still
'dont_care' flags - but individual comparisons are made to see
if OpenGL's state needs to be changed.

Now, around about here, some messiness creeps in...and probably where
the problem lies.   The problem is (I think) that there are multiple
ways for the underlying GL material colours to be changed, the glMaterial
call - or the glColor call if glColorMaterial is set that way.  There is
also this nagging doubt about what happens to the material colour when
you disable glColorMaterial (does the colour revert to the last glMaterial
setting?)...all of these drive an ugly wedge into the simple scheme I
had in mind when I wrote this stuff.

The 'switched_modes' flag was added in to try to force (possibly
redundant) additional colour updates when glColorMaterial has
been turned on or off.  I'm still not sure if that's OK or not.

The 'force' method is like 'apply' but it works on the assumption
that our current idea of OpenGL's state has been compromised - eg
by the application program getting in there and switching OpenGL's
state behind SSG's back.  Hence 'force' does all the same things
as 'apply' - but it does them unconditionally without lazy evaluation.

Personally, I don't think that blundering around in ssgSimpleState::apply
(which is where all this stuff happens) will be terribly effective until:

a) We understand the rules for glColorMaterial under seemingly unlikely
   combinations.

b) We confirm that all current OpenGL implementations actually follow
   those rules...(which I very much doubt).

Once we know what the rules should be, and where systems deviate, we
can probably figure out a really robust (and efficient) solution.

> That should be all I need to know to go
> off and experiment with reordering state change calls to see if I can
> eliminate my unwanted material property artifacts.

One common error is that IF YOU DON'T EXPLICITLY SET AN SSG STATE
ELEMENT THEN IT DOES NOT DEFAULT - IT BECOMES A "DONT_CARE" AND
IS
ESSENTIALLY RANDOM WHEN THE STATE IS RENDERED.

That's because you often don't need to set every GL state - some
you may truly not care about (eg how glMaterial is set if lighting
is disabled) - and there are significant savings to be had in not
even testing those states.

> Note: it is my "perception" that calling glMaterial() while
> GL_COLOR_MATERIAL is enabled seems to be generally problematic at
> least for me.

I think you may be partially correct:

You certainly *can* set the colour components that are not being
controlled by glColorMaterial.  If Colormaterial is driving (say)
GL_EMISSION then you can certainly use glMaterial to set the
GL_SPECULAR colour.

However, one of the uncertainties for me is how the system would
react if you set glMaterial for GL_EMISSION while glColorMaterial
is also set up to drive it.

>  The only clue I can find in the Red book (version 1.1)
> > is on page 201 at the bottom:
> >
> >     You should use glColorMaterial() whenever you need to change a
> >     single material parameter for most vertices in your scene.  If you
> >     need to change more than one material parameter ... use
> >     glMaterial().  When you don't need the capabilities of
> >     glColorMaterial() anymore, be sure to disable it so that you don't
> >     get undesired material properties ...
> >
> > Well, I'm certainly getting "undesired material properties" when I mix
> > glMaterial() with glColorMaterial() in the same ssgSimpleState ... !

Indeed.

But what the red, blue and OpenGL spec fail to explain is what
happens if (for example) we say:

    glDisable ( GL_COLOR_MATERIAL ) ;
    glMaterial ( GL_EMISSION, RED )
;
    glColorMaterial ( GL_FRONT_AND_BACK, GL_EMISSION ) ;
    glEnable ( GL_COLOR_MATERIAL ) ;
    glColor ( BLUE ) ;
    glDisable ( GL_COLOR_MATERIAL ) ;

(Let's label this code snippet "CANONICAL CONFUSION No,1"...there are
others)

...does that last glDisable restore the emission colour to RED - or
is it still set to BLUE?   Nobody seems clear on this - and generally,
it doesn't matter to most programs.  However, something like SSG that
does lazy state changes NEEDS to have this stuff spelled out rigerously.

So, the plan (for me) is to UNDERSTAND this stuff by writing a suite
of test programs - and also by capturing what SSG does in practice
when it fails.  I'd run these tests on every system I can find.

Once I truly 'grok' this stuff, I can implement a solid solution.

> The above statement seems to imply that if glColorMaterial is enabled
> and you aren't simply calling glColor() to set the specified material
> property, you are likely to get undesired material properties.

Well, perhaps - I don't read it that way.  The idea of glColorMaterial
is to cut out the expensive glMaterial changes for the most common
changes (basically ambient and diffuse in 'real world' situations) but
still allowing you to change the other parameters using the slower
glMaterial calls if you absolutely must do so.

> The program flow is a little obfuscated by the optimizations,

Yep!   :-)

> but by
> my reading here is what is happening in ssgSimpleState::apply().
>
> 1. glColorMaterial() is called first (if needed) irregardless of
> whether or not GL_COLOR_MATERIAL is enabled or not.
> [shouldn't be a problem]
>
> 2. several glMaterial() calls may be made if needed (while
> GL_COLOR_MATERIAL is enabled.)
> [PROBLEM?]

Potentially - but only if the ssgSimpleState has 'dont_care' zeroed
for both SSG_GL_COLOR_MATERIAL *and* SSG_GL_{whatever colormaterial_is_using}
...and *that* would be the decision of the application.

> 3. finally GL_COLOR_MATERIAL is enabled (if needed).
> [shouldn't be a problem]

Yep.

I think the problem is *much* more subtle - and ends up producing
a really hard to understand OpenGL sequence like the "CANONICAL
CONFUSION No.1" snippet that I gave you a moment ago.

eg:
    State_A - no colormaterial, glMaterial(GL_EMISSION...) is RED.
    State_B - uses colormaterial for emission and sets it to BLUE.

If you apply first A, then B, then A again, I suspect that disabling
B's colormaterial enable doesn't restore the glMaterial back to
RED again - but the lazy evaluation in B sees only that it has to
disable the unwanted colormaterial and imagines that glMaterial for
GL_EMISSION is still set up as required...or something like that.

This shows a case where CANONICAL CONFUSION No.1 could happen in
a simple SSG example.

> So now the trick is to flip things around with out breaking a lot of
> stuff so that if we need to make any calls to glMaterial() we first
> *disable* GL_COLOR_MATERIAL, then make the glMaterial() calls.  Then
> re-enable GL_COLOR_MATERIAL, then call glColorMaterial() if needed.

Give it a whirl - I don't think it'll help.

> Damn the OpenGL standard ... I think this will fix the problem!
>
> Now, I tried my hand at rearranging things myself and am getting
> confused.
>
> QUESTIONS:
>
> What is the difference between:
>
>      _ssgCurrentContext->getState()->enables
>
> and:
>
>     enables
>
> ... in an ssgSimpleState:: method?

...the local member 'enables' is what 'this' wants set up. The
global _ssgCurrentContext->getState()->enables is what SSG
fondly imagines is the current state of OpenGL.

> isEnabled(), enable(), and disable() seem to use the variable
> "enables" while force() and apply() seem to mix
> "_ssgCurrentContext->getState()->enables" and "enables" in ways I
> don't quite understand.

Yep - isEnabled/enable/disable are all operations on the ssgSimpleState's
desired state.  They don't have any effect on OpenGL's state until
or unless the ssgSimpleState is applied or forced.

Apply and force both alter the REAL state of OpenGL.  That means that
they apply has to check the _ssgCurrentContext's state so it doesn't
set things that are already set up correctly.  Both 'apply' and 'force'
have a responsability to update _ssgCurrentContext so that it continues
to agree with OpenGL's true current state.

I thought it was pretty clear...but evidently not  :-(

> And ... the state of SSG_GL_COLOR_MATERIAL_EN almost seems to be
> switching magically on me for reasons also beyond my understanding.
> I've added quite a few fprintf(stderr, "...") and
> SSG_GL_COLOR_MATERIAL_EN seems to change state without anything
> telling it to ... but perhaps I'm getting
> _ssgCurrentContext->getState()->enables and "enables" confused and am
> not updating the bits in the proper variable when I force a disable
> before calling glMaterial()?

Maybe - I havn't looked that closely.

> > Any thoughts Steve?  It may be my sleep deprived stupor, but I've
> > convinced myself that this is the problem ... making calls to
> > glMaterial() while GL_COLOR_MATERIAL is enabled.

Well, I think you need to qualify that by saying:

  "making calls to glMaterial ( XXXXX, .... ) while GL_COLOR_MATERIAL
   is enabled *AND* glColorMaterial ( ..., YYYYY ) is set *AND* 
   XXXXX == YYYYY."

...when XXXXX != YYYYY, I think we should be OK.  If *that* isn't the
case then I'm way more confused than I think.

Now, if I'm right - then toggling GL_COLOR_MATERIAL's enable off
and on again in order to do a glMaterial where XXXXX != YYYYYY will
actually bring about "CANONICAL CONFUSION No.1" where it didn't
exist before!

So, I think the resolution of this problem will come from studying
the dark corners of the OpenGL specification for seemingly unusual
combinations of these OpenGL commands.

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

Re: [Plib-devel] How do I?

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

Brad Colbert wrote:

> Is there an easy way to find out what the "texture-memory-footprint"
> of my frustum is?  Meaning, how much texture am I rendering (in
> memory usage) within my current field of view.

I can't think of a way to do that short of manually transforming
each polygon and doing some pretty heavy math.

>  I want to calculate
> what my next frame texture demands may be so that I can fiddle with
> the LOD's and terrain tiles in order to keep my texture memory footprint
> within the graphics hardwares available memory.

Well, I guess if your maximum turn rate is low enough - and you
have enough spare bandwidth into the graphics card, this could
work out...but in the kinds of things I've dealt with, you'd
have to cut your polygons and fill rate down pretty low to get
enough texture into the card for a 'reasonable' turn rate.
 
> I'm leaning towards creating a class that all of my virtual objects
> inherit from and having those objects throw their names on the name
> stack.  Then I could render into the selection buffer and pull off which
> objects where rendered and then query there LOD and texture size.
> Summed up this could give me something close to what I want, but
> this doesn't allow me to plan ahead, and I blow a frame or two.

So cull to a field of view that's wider than the actual field of view
by twice the maximum turn rate in both directions.  That gives you
your two frames of decision time.
 
> Or, I guess I could add a cull and then do basically the same process as above
> (without the render to the selection buffer).

Perhaps.

> Any ideas or discussions on the above would be great.
> 
> I feel like I'm opening a can of worms here.

Yep - it seems like a pretty desperate measure.

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

[Plib-devel] How do I?

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

Hi folks,

Sorry to ask this question here but...

Is there an easy way to find out what the "texture-memory-footprint"
of my frustum is?  Meaning, how much texture am I rendering (in
memory usage) within my current field of view.  I want to calculate
what my next frame texture demands may be so that I can fiddle with
the LOD's and terrain tiles in order to keep my texture memory footprint
within the graphics hardwares available memory.

I'm leaning towards creating a class that all of my virtual objects
inherit from and having those objects throw their names on the name
stack.  Then I could render into the selection buffer and pull off which
objects where rendered and then query there LOD and texture size.
Summed up this could give me something close to what I want, but
this doesn't allow me to plan ahead, and I blow a frame or two.

Or, I guess I could add a cull and then do basically the same process as above
(without the render to the selection buffer).

It would also be nice perform a projection from screen/pixel space onto a
plane that closely approximates the terrain.  Then tiles could load a texture
which best matches the pixel/texel ratio.  I know this is much like MipMapping
but I want to avoid loading in the whole MipMap image pyramid if possible.

Any ideas or discussions on the above would be great.

I feel like I'm opening a can of worms here.

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

Re: [Plib-devel] ssgSimpleState Question (bug?)

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

Steve,

Let me rephrase my question a bit more simply.

Can you tell me the proper way inside of ssgSimpleState to
enable/disable GL_COLOR_MATERIAL along with which variable should get
it's bits twiddled on/off?  That should be all I need to know to go
off and experiment with reordering state change calls to see if I can
eliminate my unwanted material property artifacts.

Thanks,

Curt.

Curt writes:
> > "Curtis L. Olson" wrote:
> > > 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.
> 
> Steve Baker writes:
> > Seems like this is another variation of the dreaded glColorMaterial
> > problem.
> 
> Steve,
> 
> I've been poking around tonight in ssgSimpleState.cxx:
> ssgSimpleState::apply() and force().
> 
> Note: it is my "perception" that calling glMaterial() while
> GL_COLOR_MATERIAL is enabled seems to be generally problematic at
> least for me.  The only clue I can find in the Red book (version 1.1)
> is on page 201 at the bottom:
> 
>     You should use glColorMaterial() whenever you need to change a
>     single material parameter for most vertices in your scene.  If you
>     need to change more than one material parameter ... use
>     glMaterial().  When you don't need the capabilities of
>     glColorMaterial() anymore, be sure to disable it so that you don't
>     get undesired material properties ...
> 
> Well, I'm certainly getting "undesired material properties" when I mix
> glMaterial() with glColorMaterial() in the same ssgSimpleState ... !
> 
> The above statement seems to imply that if glColorMaterial is enabled
> and you aren't simply calling glColor() to set the specified material
> property, you are likely to get undesired material properties.
> 
> The program flow is a little obfuscated by the optimizations, but by
> my reading here is what is happening in ssgSimpleState::apply().
> 
> 1. glColorMaterial() is called first (if needed) irregardless of
> whether or not GL_COLOR_MATERIAL is enabled or not.
> [shouldn't be a problem]
> 
> 2. several glMaterial() calls may be made if needed (while
> GL_COLOR_MATERIAL is enabled.)
> [PROBLEM?]
> 
> 3. finally GL_COLOR_MATERIAL is enabled (if needed).
> [shouldn't be a problem]
> 
> So now the trick is to flip things around with out breaking a lot of
> stuff so that if we need to make any calls to glMaterial() we first
> *disable* GL_COLOR_MATERIAL, then make the glMaterial() calls.  Then
> re-enable GL_COLOR_MATERIAL, then call glColorMaterial() if needed.
> 
> Damn the OpenGL standard ... I think this will fix the problem!
> 
> Now, I tried my hand at rearranging things myself and am getting
> confused.
> 
> QUESTIONS:
> 
> What is the difference between:
> 
>      _ssgCurrentContext->getState()->enables
> 
> and:
> 
>     enables
> 
> ... in an ssgSimpleState:: method?
> 
> isEnabled(), enable(), and disable() seem to use the variable
> "enables" while force() and apply() seem to mix
> "_ssgCurrentContext->getState()->enables" and "enables" in ways I
> don't quite understand.
> 
> And ... the state of SSG_GL_COLOR_MATERIAL_EN almost seems to be
> switching magically on me for reasons also beyond my understanding.
> I've added quite a few fprintf(stderr, "...") and
> SSG_GL_COLOR_MATERIAL_EN seems to change state without anything
> telling it to ... but perhaps I'm getting
> _ssgCurrentContext->getState()->enables and "enables" confused and am
> not updating the bits in the proper variable when I force a disable
> before calling glMaterial()?
> 
> Any thoughts Steve?  It may be my sleep deprived stupor, but I've
> convinced myself that this is the problem ... making calls to
> glMaterial() while GL_COLOR_MATERIAL is enabled.  Any tips to point me
> in the right direction for correctly disabling GL_COLOR_MATERIAL
> before any glMaterial() calls are made?  If you take a look at it,
> this needs to be done both in apply() and in force() ... I'm guessing
> this won't be too hard to fix for someone who understands how it is
> all wired together.
> 
> 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
> 
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel

-- 
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] Vertex array code

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

Eric: Are you going to make any of these changes and
submit them for including in plib?  Or, should I begin
fixing up ssgVtxArray, etc?  I don't want to collide
with anything you might be doing.  I'm not moving real
fast on any updates, because everything is 'good
enough' right now.  But, I think your optional array
stuff is worth doing.

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: Vallevand, Mark K 
> Sent: Monday, May 15, 2000 2:56 PM
> To: 'pli...@li...'
> Subject: RE: [Plib-devel] Vertex array code
> 
> 
> I like the part about optional arrays.  This is 
> very similar to what I thought about for future 
> improvements.  But, the tunable part is just for
> performance, correct?
> 
> In the fullness of time, I'd create a base class
> (say, ssgVtx) that has almost all the algorithms
> in it, with derived classes (say, ssgVtxTable,
> ssgVtxArray, ssgVtxInterleavedArray, etc) that
> have specific methods for getting at the vertex
> data.  I'd declare pure virtual methods in the
> base class for all the methods required to be
> supported by the derived classes.  Right now, its
> just opportunistic coding that allows ssgVtxArray
> to be derived from ssgVtxTable.  There is far too
> much duplication between the classes.
> 
> 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: Eric Espie [mailto:Eri...@fr...]
> > Sent: Monday, May 15, 2000 2:37 PM
> > To: pli...@li...
> > Subject: Re: [Plib-devel] Vertex array code
> > 
> > 
> > "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 ( ) ;
> >   }
> > 
> > }
> > 
> > _______________________________________________
> > plib-devel mailing list
> > pli...@li...
> > http://lists.sourceforge.net/mailman/listinfo/plib-devel
> > 
> 

RE: [Plib-devel] UL directory.

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

> The problem here was that (for Windoze-related reasons) the directory
> was inadvertantly created with an UPPERCASE filename.
yep. it was lowercase on my machine but when, using wincvs, i did a "cvs add
ul.h" inside the ul folder it changed the folder name to UL.  i reported
this bug via bugzilla at wincvs.org

> I guess that we should make a rule that if someone wants to make
> a new directory, they should either use UNIX/Linux or ask me to
> do it.
yep. i did not understand the irreversible consequences of my action at the
time. did you send a note to sourceforge admin to see if they would help
out?  "mv UL ul" in the unix shell.

--Dave McClurg

Re: [Plib-devel] Ancient history....depth buffer queries

[Stephen J B. <sj...@ht...>]

> I have a question.  Here's what you wrote (I think...as formatting
> has garbled the equation):
> 
> > This comes up about every 6 months....here is the stock reply...
> >
> >   The 'official' SGI solution to this is...
> >
> >     z = value in z buffer after rendering (input)
> >     range = distance to pixel in database units (output)
> >
> >     np = distance to near clipping plane
> >     fp = distance far clipping plane
> >
> >     nz = near-clip z value
> >     fz = far-clip z value
> >                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> >
> >     For each Z-buffer value:
> >
> >                      fp*np(fz-nz)
> >                      ------------
> >                         fp-np
> >     - range = --------------------------
> >                   (fp+np)(fz-nz)   fz+nz
> >               z - -------------- - -----
> >                      2(fp-np)        2
> >
> 
> My questions are:
> 1) has this formatting been restored correctly?
 
Yes. That's correct.

> > 2) Could you explain the nz/fz equations more clearly...
 
Here is what I use in an actual Performer application:

--------------------------- CUT HERE ---------------------------
/*
  This routine calculates the terms:
 
              fp*np(fz-nz)
     z_top =  ------------
                 fp-np

  and
              (fp+np)(fz-nz)   fz+nz
     z_bot =  -------------- + -----
                 2(fp-np)        2
 
  So the actual per-pixel z-to-range math can be boiled down to:  z_top / ( z - z_bot )
*/


void read_z ( pfChannel *chan )
{
  float z_top ;
  float z_bot ;
  float np, fp ;
  float nz, fz ;
  int width  = ...whatever... ;
  int height = ...whatever... ;
  int top, bot, left, right = ...whatever... ;
  unsigned long z_result [ height * width ] ;
  float result [ height * width ] ;
  GLint z_vals[ 2 ] ;
 
  /* Set up the math... */

  pfGetChanNearFar ( chan, & np, & fp );
  glGetIntegerv    ( GL_DEPTH_RANGE, z_vals ) ;

  nz = (float) z_vals [ 0 ] ;
  fz = (float) z_vals [ 1 ] ;

  z_top = -fp*np *(fz-nz) /  (fp-np) ;
  z_bot = (fp+np)*(fz-nz) / ((fp-np) * 2.0 ) + (fz+nz) / 2.0 ;

  /* Read the Z buffer... */

  glReadBuffer ( GL_BACK ) ;
  glReadPixels ( left, bot, right-left+1, top-bot+1,
                 GL_DEPTH_COMPONENT, GL_INT, z_result ) ;

  /* Convert to real-world units... */

  for ( ...each Z value to convert... )
    result[...whatever...] = z_top / ( (float) z_result[...whatever...] - z_bot ) ;
}
---------------------- CUT HERE ------------------------------


Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: sj...@ht...            http://www.hti.com
Home: sjb...@ai...       http://web2.airmail.net/sjbaker1

Re: [Plib-devel] strdup...no!

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

Steve Baker <sjb...@ai...> wrote:

>Well, the idea is that if you use 'new' and 'delete' for everything, then someone
>in the future could overload those operators to use some other memory allocator.

I am doing this already to look for memory leaks.

Bye bye,
Wolfram.

RE: [Plib-devel] UL directory.

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

Steve Baker writes:
>
>The problem here was that (for Windoze-related reasons) the directory
>was inadvertantly created with an UPPERCASE filename.  Whilst I can
>understand that CVS won't delete a directory - it's a pain that
>it won't let me create a new directory with the same name but in
>lowercase...but I guess that must be for Windoze-compatability
>reasons also.

 #%$^#...

This seems to be a known problem with CVS.
Apparently this is being looked into and 'may' be fixed shortly.

for those interested see
http://www.findmail.com/message/info-cvs/22129?&start=17740

Norman

Re: [Plib-devel] UL directory.

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

Norman Vine wrote:
> 
> Curt writes:
> 
> >Steve Baker writes:
> >> Well, I've tried absolutely everything and I can't get CVS to
> >> get rid of that 'UL' directory.
> >
> >As far as I know, CVS provides no commands or options to remove a
> >directory.

OK - thanks for the info guys.

The problem here was that (for Windoze-related reasons) the directory
was inadvertantly created with an UPPERCASE filename.  Whilst I can
understand that CVS won't delete a directory - it's a pain that
it won't let me create a new directory with the same name but in
lowercase...but I guess that must be for Windoze-compatability
reasons also.

I guess that we should make a rule that if someone wants to make
a new directory, they should either use UNIX/Linux or ask me to
do it.

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

Re: [Plib-devel] ssgSimpleState Question (bug?)

[Curt <cu...@in...>]

> "Curtis L. Olson" wrote:
> > 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.

Steve Baker writes:
> Seems like this is another variation of the dreaded glColorMaterial
> problem.

Steve,

I've been poking around tonight in ssgSimpleState.cxx:
ssgSimpleState::apply() and force().

Note: it is my "perception" that calling glMaterial() while
GL_COLOR_MATERIAL is enabled seems to be generally problematic at
least for me.  The only clue I can find in the Red book (version 1.1)
is on page 201 at the bottom:

    You should use glColorMaterial() whenever you need to change a
    single material parameter for most vertices in your scene.  If you
    need to change more than one material parameter ... use
    glMaterial().  When you don't need the capabilities of
    glColorMaterial() anymore, be sure to disable it so that you don't
    get undesired material properties ...

Well, I'm certainly getting "undesired material properties" when I mix
glMaterial() with glColorMaterial() in the same ssgSimpleState ... !

The above statement seems to imply that if glColorMaterial is enabled
and you aren't simply calling glColor() to set the specified material
property, you are likely to get undesired material properties.

The program flow is a little obfuscated by the optimizations, but by
my reading here is what is happening in ssgSimpleState::apply().

1. glColorMaterial() is called first (if needed) irregardless of
whether or not GL_COLOR_MATERIAL is enabled or not.
[shouldn't be a problem]

2. several glMaterial() calls may be made if needed (while
GL_COLOR_MATERIAL is enabled.)
[PROBLEM?]

3. finally GL_COLOR_MATERIAL is enabled (if needed).
[shouldn't be a problem]

So now the trick is to flip things around with out breaking a lot of
stuff so that if we need to make any calls to glMaterial() we first
*disable* GL_COLOR_MATERIAL, then make the glMaterial() calls.  Then
re-enable GL_COLOR_MATERIAL, then call glColorMaterial() if needed.

Damn the OpenGL standard ... I think this will fix the problem!

Now, I tried my hand at rearranging things myself and am getting
confused.

QUESTIONS:

What is the difference between:

     _ssgCurrentContext->getState()->enables

and:

    enables

... in an ssgSimpleState:: method?

isEnabled(), enable(), and disable() seem to use the variable
"enables" while force() and apply() seem to mix
"_ssgCurrentContext->getState()->enables" and "enables" in ways I
don't quite understand.

And ... the state of SSG_GL_COLOR_MATERIAL_EN almost seems to be
switching magically on me for reasons also beyond my understanding.
I've added quite a few fprintf(stderr, "...") and
SSG_GL_COLOR_MATERIAL_EN seems to change state without anything
telling it to ... but perhaps I'm getting
_ssgCurrentContext->getState()->enables and "enables" confused and am
not updating the bits in the proper variable when I force a disable
before calling glMaterial()?

Any thoughts Steve?  It may be my sleep deprived stupor, but I've
convinced myself that this is the problem ... making calls to
glMaterial() while GL_COLOR_MATERIAL is enabled.  Any tips to point me
in the right direction for correctly disabling GL_COLOR_MATERIAL
before any glMaterial() calls are made?  If you take a look at it,
this needs to be done both in apply() and in force() ... I'm guessing
this won't be too hard to fix for someone who understands how it is
all wired together.

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] UL directory.

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

Curt writes:

>Steve Baker writes:
>> Well, I've tried absolutely everything and I can't get CVS to
>> get rid of that 'UL' directory.
>
>As far as I know, CVS provides no commands or options to remove a
>directory.
>

FWIW
< snipped from the CVS book >

Removing Directories
As I said before, CVS doesn't really keep directories under version control.
Instead, as a kind of cheap substitute, it offers certain odd behaviors that
in most cases do the "right thing". One of these odd behaviors is that empty
directories can be treated specially. If you want to remove a directory from
a project, you first remove all the files in it

floss$ cd dir
floss$ rm file1 file2 file3
floss$ cvs remove file1 file2 file3
  (output omitted)
floss$ cvs ci -m "removed all files" file1 file2 file3
  (output omitted)

and then run update in the directory above it with the -P flag:

floss$ cd ..
floss$ cvs update -P
  (output omitted)

The -P option tells update to "prune" any empty directories - that is, to
remove them from the working copy. Once that's done, the directory can be
said to have been removed; all of its files are gone, and the directory
itself is gone (from the working copy, at least, although there is actually
still an empty directory in the repository).

Re: [Plib-devel] UL directory.

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

Sam Stickland writes:
> 
> > Someone correct me if I'm wrong, but it is my understanding that it is
> > impossible to delete a directory from CVS once it has been created.
> > Otherwise, how could you reliably go back and recreate an older
> > version.  If entire directories along with their CVS source files are
> > gone, there would be no way to check out a complete version of the
> > code as of sometime when the directory did exist.
> >
> > As far as I know, CVS provides no commands or options to remove a
> > directory.
> 
> While this is true, it usual to use the -P option when checking out
> - which prunes empty directories.  Ie.  remove all the files 
> from the directory and always checkout with "-P" and you won't see
> it.

That's true, the point being you can remove all the files in a
directory, but not the directory itself ... and using -P from the
client side, you'll ignore all empty directories.

> CVS only manages files - not directories.  Once a directory is
> created it's there for life, unless you delete it from a unix shell
> - if you have that option.

Yup, which is something you don't have direct access to at sourceforge
unfortunately. :-(

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] UL directory.

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

> Someone correct me if I'm wrong, but it is my understanding that it is
> impossible to delete a directory from CVS once it has been created.
> Otherwise, how could you reliably go back and recreate an older
> version.  If entire directories along with their CVS source files are
> gone, there would be no way to check out a complete version of the
> code as of sometime when the directory did exist.
>
> As far as I know, CVS provides no commands or options to remove a
> directory.

While this is true, it usual to use the -P option when checking out - which prunes empty directories.  Ie.  remove all the files
from the directory and always checkout with "-P" and you won't see it.

CVS only manages files - not directories.  Once a directory is created it's there for life, unless you delete it from a unix shell -
it you have that option.

Sam

> Steve: this is the main reason why I have avoided moving my cvs stuff
> to sourceforge.  I often find myself wanting to rename, or remove
> directories.  Having local control of the repository allows me to
> actually go in and use unix commands to physically remove an old
> unwanted directory and its contents.
>
> My guess is that this is going to require sourceforge admin
> intervention.
>
> 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
>
> _______________________________________________
> plib-devel mailing list
> pli...@li...
> http://lists.sourceforge.net/mailman/listinfo/plib-devel
>

Re: [Plib-devel] UL directory.

[Curt <cu...@in...>]

Steve Baker writes:
> Well, I've tried absolutely everything and I can't get CVS to
> get rid of that 'UL' directory.  The problem seems to be
> that whenever I try to touch it, CVS converts case on me
> and refuses to find it.
>
> I think it needs to be removed from a PC running Windoze
> just as it was created.
>
> I'm reading "Lord of the Rings" to my son right now - and
> after an hour struggling with trying to delete this
> damned directory, I'm beginning to think that it needs to
> be 'unmade' by it's creator. Thinking perhaps of asking
> Dave if he wouldn't mind trotting off to Mordor and tossing
> it into the Crack of Doom for me.  :-)
>
> Meanwhile - in the interests of getting on with life,
> I've created a new directory called 'util', moved
> all of UL's files there and adjusted the Makefile's
> accordingly.
>
> Could someone please check all this out and confirm that
> it all still works....thanks.

Someone correct me if I'm wrong, but it is my understanding that it is
impossible to delete a directory from CVS once it has been created.
Otherwise, how could you reliably go back and recreate an older
version.  If entire directories along with their CVS source files are
gone, there would be no way to check out a complete version of the
code as of sometime when the directory did exist.

As far as I know, CVS provides no commands or options to remove a
directory.

Steve: this is the main reason why I have avoided moving my cvs stuff
to sourceforge.  I often find myself wanting to rename, or remove
directories.  Having local control of the repository allows me to
actually go in and use unix commands to physically remove an old
unwanted directory and its contents.

My guess is that this is going to require sourceforge admin
intervention.

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

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

Steve Baker wrote:

> >
> > The internal code, calculating the celestial mechanics is currently still
> > pretty much intermixed in FlightGear. I am currently working on a new
> > approach, which should eventually result in a small library consisting of
> > time and celestial functions, usable as a stand alone lib.
>
> This would truly be a great thing to have.  So many OpenSource 3D
> projects (mine included) simply clear the screen to 0,255,255, and
> having a simple (couple of line) API to put up nice skies would be
> a WONDERFUL addition.
>

Thanks. I'd like to stress, however, that since I'm devoting an extremely limited
amount of time on programming and open source projects this year, it might
actually take another few months before there's something useful. (Even though
the design isn't that complicated).

>
> Perhaps at first, we don't need the fancy time and celestial functions.
> A simple four way MORNING/NOON/SUNSET/NIGHT option hardwired at (say)
> 45 degrees latitude would be plenty for 90% of applications.  You could
> add in the fancy celestial stuff later.

Hmm, yes, but I'm sure that with FlightGear, we wouldn't really like to go back
to a more basic setup, so with the usability for FlightGear in mind, I'd like to
capture the entire funtionality we currrently have. It might be a good idea to
add a few wrapper classes that allow an easy setup of a sky and star dome.

Functionality more complex than what is currently found in FlightGear, such as
needed for spaceflight simulations, is currently beyond my own design goals. At
the moment, I'd lacking both time and knowledge to do this. For the latter, I'm
convinced that a separate set of functions would be the best way to go.

Regards,
Durk

[Plib-devel] UL directory.

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

Well, I've tried absolutely everything and I can't get CVS to
get rid of that 'UL' directory.  The problem seems to be
that whenever I try to touch it, CVS converts case on me
and refuses to find it.

I think it needs to be removed from a PC running Windoze
just as it was created.

I'm reading "Lord of the Rings" to my son right now - and
after an hour struggling with trying to delete this
damned directory, I'm beginning to think that it needs to
be 'unmade' by it's creator. Thinking perhaps of asking
Dave if he wouldn't mind trotting off to Mordor and tossing
it into the Crack of Doom for me.  :-)

Meanwhile - in the interests of getting on with life,
I've created a new directory called 'util', moved
all of UL's files there and adjusted the Makefile's
accordingly.

Could someone please check all this out and confirm that
it all still works....thanks.

   Steve.

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

Re: [Plib-devel] Ancient history....depth buffer queries

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

Scott McMillan wrote:

> I was going through some very old info-performer archives...

*VERY* old!

> ...on depth/range calculations and I came across your formula again...

Actually the formula came from SGI - but it seems to be right for
other systems.

> I have a question.  Here's what you wrote (I think...as formatting
> has garbled the equation):
> 
> > This comes up about every 6 months....here is the stock reply...
> >
> >   The 'official' SGI solution to this is...
> >
> >     z = value in z buffer after rendering (input)
> >     range = distance to pixel in database units (output)
> >
> >     np = distance to near clipping plane
> >     fp = distance far clipping plane
> >
> >     nz = near-clip z value
> >     fz = far-clip z value
> >                 (as read from glGetIntegerv ( GL_DEPTH_RANGE,...) for OpenGL)
> >
> >     For each Z-buffer value:
> >
> >                      fp*np(fz-nz)
> >                      ------------
> >                         fp-np
> >     - range = --------------------------
> >                   (fp+np)(fz-nz)   fz+nz
> >               z - -------------- - -----
> >                      2(fp-np)        2
> >
> 
> My questions are:
> 1) has this formatting been restored correctly?

Hmmm - not sure.  I'd have to be at work to answer that one.
I'll have to let you know sometime tomorrow.

> 2) Could you explain the nz/fz equations more clearly...

Sorry - it's not my equation - I just regurgitated it from
a previous email from Micheal Jones - who no longer works
at SGI.

I'll try to dig out some actual code where I used the
equation and email it to you tomorrow.  Are you actually
using Performer or is this really an OpenGL problem?

If it's OpenGL, then I wrote a FAQ about Z buffer values
here:

  http://web2.airmail.net/sjbaker1/omniv.html

...that has the inverse equation (for OpenGL - not Performer).

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

Re: [Plib-devel] strdup...no!

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

> Dave McClurg wrote:
> 
> > I just downloaded the CVS of PLIB - and I see 'strdup' calls
> > everywhere...
> > one of which is causing a core dump.
> >
> > Please don't use strdup under C++ because it circumvents C++'s memory
> > allocator.
> >
> OT:
> 
> I thought memory allocation in C++ was backwards compatible with C except in regards to casts from void * to/from other pointer types.
> 
> Could you explain this or give me an URL to read?

Well, the idea is that if you use 'new' and 'delete' for everything, then someone
in the future could overload those operators to use some other memory allocator.

I've done this in the past in order to use shared memory - or fancy hardware
gizmo's called 'ScramNet' cards...also to check for memory leaks and
corruptions.  It also allows you to check for running out of memory in
one nice central location.

If you were rigerous about it and always used 'free' to remove everything
that had been 'malloc'ed or 'strdup'ed then it would be OK-ish (still not
great - but OK).  However, if you strdup something and then remove it using
'delete', then great and subtle mahem will happen downstream.

So, it's really NOT a good idea to mix C and C++ style memory allocators.

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

Re: [Plib-devel] A few problems

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

> Dave McClurg wrote:
> 
> Eeek!  Sorry for the mayhem and bloodshed.

No problem - I do that kind of thing all the time!

> Adding the _ssgCreateFunc was a non-trivial code change.

Yep - I could tell.

> But it does eliminate the redudant sharing code in each of the loaders
> for states and textures and allows the application to control sharing
> and creation of leafs (eg VtxArray vs VtxTable) better.

Not any more it doesn't :-)  ...I commented out the sharing code so that it
would at least run with existing applications.  Feel free to un-comment it
when you figure out what went wrong...it'll be a useful change when it works.
 
> I'll download Tux_AQFH and investigate the problem.  In the future,
> I'll try to use that as a reference application to test PLIB changes
> against.

Yep.

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