plib-devel

Re: [Plib-devel] A few problems

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

Steve Baker wrote:

> > src/UL should be renamed to src/ul
> 
> Done.

are you sure?
I just did a fresh checkout, and got the UL dir, not ul.

  Bram

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

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

[Scott M. <mcm...@ca...>]

I apologize profusely...my previous email should have gone
to Steve directly.  However, I will take input from anyone
on this list, especially if they know whether or not the
equations in question are specific to SGIs only or if they
apply to all OpenGL implementations.

Thanks and sorry again,
scott

--
Scott McMillan
mailto:mcm...@ca...

SGL Home Page:       http://sgl.sourceforge.net
DynaMechs Home Page: http://dynamechs.sourceforge.net

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

[Scott M. <mcm...@ca...>]

Steve:

I was going through some very old info-performer archives on
depth/range calculations and I came across your formula again, and
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?
2) Could you explain the nz/fz equations more clearly...
   Did you really mean glGetIntegerv, or do I do something
   like the following?:

   float depth_range[2];
   glGetFloatv(GL_DEPTH_RANGE, depth_range);
   nz = near_clip - depth_range[0];   // indices
   fz =  far_clip - depth_range[1];

   With integers I get 0,2147482496 (not MAX_INT)
   With floats   I get 0,1

3) What format should I read the depth buffer in in the first place?

Note that I am querying the depth buffer as floats with the following:

GLfloat *depthData3 = (GLfloat *) malloc(sizeX*sizeY*sizeof(GLfloat));
glReadPixels(0, 0, sizeX, sizeY,
             GL_DEPTH_COMPONENT, GL_FLOAT, depthData3);

Any help is greatly appreciated,
scott

-- 
Scott McMillan
mailto:mcm...@ca...

SGL Home Page:       http://sgl.sourceforge.net
DynaMechs Home Page: http://dynamechs.sourceforge.net

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

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

Vallevand, Mark K writes:
> A brush-with-greatness!  What store?  Maybe she (Kristin Johnson)
> was in town for the fishing opener.  :-)

That's a good point ... it was a convenience store on the north end of
town ... about the only thing of interest in my neck of the woods is
that we are on the way out of town if you are heading up to the lakes.

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

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

Vallevand, Mark K writes:
> Yes, something like this would be really nice.
> 
> 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

Well, I've got the basic ssg sky stuff implimented ... if someone
wants to pick up on this and generalize it a bit for public use, I'd
be happy to cooperate.

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] strdup...no!

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

> 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?

Thanks

RE: [Plib-devel] A few problems

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

Eeek!  Sorry for the mayhem and bloodshed.

Adding the _ssgCreateFunc was a non-trivial code change.
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.

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.

Okie Dokie,
--Dave McClurg

> > After fixing these things it compiles, but none of my programs will
> > work with it. I tried Tux AQFH too, but it dies in 
> getMaterial because
> > ssgLeaf::getState always returns NULL.
> 
> That's not the problem I'm seeing - the problem with ssgLoadAC kills
> me first.
> 
> ...<time passes>...OK - I fixed all the strdup problems in ssgLoadAC
> (presumably some remain in the other loaders) and now I die in the
> same place that you do.
> 
> ...<MUCH more time passes>...
> 
> I think _ssgCreateFunc is broken. If the application returns NULL
> for
> the state, then the loader is supposed to generate one of it's own.
> That seems to have happened OK in an older ssgLoadAC I had on my
> machine - but the new one doesn't do that.
> 
> I fixed that one - but still it dumps in the same place.
> 
> ...<Remainder of evening passes>...
> 
> In the end, I commented out the call to '_ssgShareState' - and that
> fixed everything so it runs.  I didn't have time to figure out why
> so I just left it commented out and committed the changes...it's 2am.
> 
>    :-)
> 

RE: [Plib-devel] Vertex array code

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

> The next issue will be what to do in the loaders.  We'll
> probably need to add either a hinting mechanism or a callback
> function.
> 
The ssgCreateFunc callback could easily handle this.

--Dave McClurg

RE: [Plib-devel] TerraPage

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

Yes, something like this would be really nice.

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

> 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.
> 
> -- 
> Steve Baker 

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

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

A brush-with-greatness!  What store?  Maybe she (Kristin Johnson)
was in town for the fishing opener.  :-)

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

> This evening on her way home from work, my wife stopped in the
> convenience store up at the corner to pick up some milk.  The person
> ahead of her in line was "Sally" from 3rd rock from the sun ... one of
> my favorite TV shows.  My wife said something like "Hey, you're the
> one from that ... that ... that ... that TV show ..." and couldn't
> remember the name of the show on the spot of course.  She didn't
> really look back and replied "Yeah, I get that a lot" and slipped out.
> We couldn't figure out what she would have been doing in MN, let alone
> way the heck up in the northern suburbs ... must have been lost or
> something.  That was our closest brush with fame since my cousin was
> married to the New York Yankees 2nd baseman.
> 
> Curt.

RE: [Plib-devel] A few problems

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

Steve Baker writes:
>
>That's not the problem I'm seeing - the problem with ssgLoadAC kills
>me first.

>...<Remainder of evening passes>...

>In the end, I commented out the call to '_ssgShareState' - and that
>fixed everything so it runs.  I didn't have time to figure out why
>so I just left it commented out and committed the changes...it's 2am.

Hi Steve,

Haven't looked at all your changes yet but ..

ssgLoadAC is working <again> in FlightGear.

Thanks for looking into this 
Hopefully we can all get some sleep tonight 

:^)

Norman

Re: [Plib-devel] A few problems

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

* Steve Baker <sjb...@ai...> wrote:
> (You mean current_tfname - right? ...don't forget to 'delete' it
> first)...good catch!  I've been suffering from that one for
> quite a while.

I see current_texture doesn't exist in CVS. I guess you could do the
same thing with current_tfname though.

> I think there is also a problem that someone replaced:
> 
>   yada_yada_yada -> tfname = current_tfname ;
> 
> ...with
> 
>   yada_yada_yada -> tfname = strdup ( current_tfname ) ;
> 
> ...which fails in the (now common) case where the current texture file
> name is NULL because there is no current texture.

Yeah, I noticed that too, but I forgot about it.

> The --add-missing option of automake does that.  You need to run this
> after a new download from CVS:

Ok. I should learn how to use those tools some day..

> ...<time passes>...OK - I fixed all the strdup problems in ssgLoadAC
> (presumably some remain in the other loaders) and now I die in the
> same place that you do.
> 
> ...<MUCH more time passes>...
> 
> I think _ssgCreateFunc is broken. If the application returns NULL
> for
> the state, then the loader is supposed to generate one of it's own.
> That seems to have happened OK in an older ssgLoadAC I had on my
> machine - but the new one doesn't do that.
> 
> I fixed that one - but still it dumps in the same place.
> 
> ...<Remainder of evening passes>...
> 
> In the end, I commented out the call to '_ssgShareState' - and that
> fixed everything so it runs.  I didn't have time to figure out why
> so I just left it commented out and committed the changes...it's 2am.

It's 6am here, so I won't attempt to process this until another time
:)

Re: [Plib-devel] A few problems

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

Trent Gamblin wrote:
> 
> In ssgLoadAC, if a surface is textured, every surface after it that
> doesn't have a texture gets textured with the previous texture
> (gasp!). I solved it by setting current_texture to NULL at the
> beginning of do_object in ssgLoadAC.cxx.

(You mean current_tfname - right? ...don't forget to 'delete' it
first)...good catch!  I've been suffering from that one for
quite a while.

I think there is also a problem that someone replaced:

  yada_yada_yada -> tfname = current_tfname ;

...with

  yada_yada_yada -> tfname = strdup ( current_tfname ) ;

...which fails in the (now common) case where the current texture file
name is NULL because there is no current texture.

> I tried to get the latest sources from CVS working, but had some
> problems. Some stuff I haven't figured out, but here is the easy
> stuff:
> 
> src/UL should be renamed to src/ul

Done.
 
> You need to run autoconf/automake. I guess if someone is using CVS
> they should have those tools anyway?

Yes.
 
> Some scripts that autoconf uses aren't there: missing, install-sh
> and mkinstalldirs.

The --add-missing option of automake does that.  You need to run this
after a new download from CVS:

rm -f config.*
aclocal
automake --add-missing
autoconf
./configure
make
make install
 
> After fixing these things it compiles, but none of my programs will
> work with it. I tried Tux AQFH too, but it dies in getMaterial because
> ssgLeaf::getState always returns NULL.

That's not the problem I'm seeing - the problem with ssgLoadAC kills
me first.

...<time passes>...OK - I fixed all the strdup problems in ssgLoadAC
(presumably some remain in the other loaders) and now I die in the
same place that you do.

...<MUCH more time passes>...

I think _ssgCreateFunc is broken. If the application returns NULL
for
the state, then the loader is supposed to generate one of it's own.
That seems to have happened OK in an older ssgLoadAC I had on my
machine - but the new one doesn't do that.

I fixed that one - but still it dumps in the same place.

...<Remainder of evening passes>...

In the end, I commented out the call to '_ssgShareState' - and that
fixed everything so it runs.  I didn't have time to figure out why
so I just left it commented out and committed the changes...it's 2am.

   :-)

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

[Plib-devel] strdup...no!

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

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.

If you must:

inline char *cpp_strdup ( char *source )
{
  char *p = new char [ strlen ( source ) + 1 ] ;
  strcpy ( p, source ) ;
  return p ;
}


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

[Plib-devel] BUG IN DYNAMIC LINKER

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

Some time ago, someone reported this message:

  BUG IN DYNAMIC LINKER ld.so: dl-version.c: 210: _dl_check_map_versions:
Assertion `needed != ((void *)0)' failed!

...subsequently, I was hit by the exact same thing.

Finally, I gave in and blew a couple of hours of heavy search engine
thrashing which yielded this:

http://x40.deja.com/getdoc.xp?AN=545891503&CONTEXT=958448712.1788280849&hitnum=29

...in short, it says that there is a problem with dynamically linking
to libraries that in turn dynamically link to the PThreads library.

Since the latest Mesa uses Pthreads but the nVidia OpenGL for Linux
does not, this is a spot-on diagnosis for my peculiar symptoms.

A viable work-around appears to be to add '-lpthread' into the linker
options for any program that links to Mesa...or might link to Mesa
in the future.

We have to presume that a bug such as this (which features in one
of the Linux fortune cookies!) is going to be around for a while...
so I advise everyone to add -lpthread into their Makefile's.


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

Curt wrote:
> 
> Steve Baker writes:
>
> > Seems like this is another variation of the dreaded glColorMaterial
> > problem.
> >
>
> Any suggestions of things/places I could start looking?  Any ideas for
> work arounds?

Well, I think we need to boil this down to a simple (non-PLIB, non-FGFS)
test case.  My plan (long delayed) has been to write GL call interception
code (kind of like the 'xgl' stuff that FGFS uses - but not requiring
me to hack the SSG code too much to insert it). This would allow me
to capture a frame of broken rendering (preferably a very simple
one) as a long string of GL calls.  Then taking that output and hacking
it into a simple GLUT framework, we can progressively reduce the
number of calls to the bare minimum that exhibits the problem.

At that point, we should have a 50-ish line program. I hope that
it'll either show up my error as some glaringly obvious missing
(or extra) OpenGL state call - or it'll *look* like a completely
reasonably OpenGL program whose failure we can't understand.  In
the former case, we can fix my bug - in the latter case, we are
in good shape to run that test on a gazillion different OpenGL
ports to see if (say) it's unique to Mesa or something (it isn't)
- and/or submit it to the Guru's at OpenGL-Gamedev and elsewhere
for discussion and (hopefully) explanation.

I almost have my OpenGL logger working.

This is a fine and cunning plan - lacking only one critical
component...the time needed to implement 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...>]

Steve Baker 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.
>
> Seems like this is another variation of the dreaded glColorMaterial
> problem.
>
> The problem is that I have so little time to work on this stuff
> right now that I simply can't get to fix this.

Fair enough ... 

Any suggestions of things/places I could start looking?  Any ideas for
work arounds?

This evening on her way home from work, my wife stopped in the
convenience store up at the corner to pick up some milk.  The person
ahead of her in line was "Sally" from 3rd rock from the sun ... one of
my favorite TV shows.  My wife said something like "Hey, you're the
one from that ... that ... that ... that TV show ..." and couldn't
remember the name of the show on the spot of course.  She didn't
really look back and replied "Yeah, I get that a lot" and slipped out.
We couldn't figure out what she would have been doing in MN, let alone
way the heck up in the northern suburbs ... must have been lost or
something.  That was our closest brush with fame since my cousin was
married to the New York Yankees 2nd baseman.

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] ssgSimpleState Question (bug?)

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

"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.

Seems like this is another variation of the dreaded glColorMaterial
problem.
 
The problem is that I have so little time to work on this stuff
right now that I simply can't get to fix this.

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

Re: [Plib-devel] TerraPage

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

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

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.

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

Re: [Plib-devel] TerraPage

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

Brad Colbert wrote:
> 
> Hey folks,
> 
> Is anyone looking into "porting" TerreX's Terrapage terrain paging code
> over to PLIB?

Not that I'm aware of.  Curt has been looking at this issue
from the reverse direction which is to extract the existing
(working) large area pager from within FlightGear and to turn
that into a separate stand-alone library.  That project is called
'TerraGear' (no relation to TerraPage) - and is (IIRC) currently
on SourceForge.

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

Really?   It's been done several times before...those people must have
easily blown minds.   :-)
 
> Their source is free (within bounds) and all it needs is the layer between
> the paging/memory management to the SSG.

I'll read up all about it.
Thanks for the info.

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

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

Re: [Plib-devel] Vertex array code

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

Eric Espie wrote:
> 
> "Vallevand, Mark K" wrote:
> >
> > 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?
> 
> Yes, I think that for a small amount of vertices, the
> array code will be slower than glBegin - glEnd,
> but this should be tested and tuned, may be one of the
> two paths is always better than the other.

And of course the precise choice of where any split should
lie will depend on which graphics card you have, which
driver, how fast your CPU is and so on.

If it makes a lot of difference then the choice of where
the split comes probably needs to be made by the application -
or perhaps read from some kind of config file.

> > 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.

Yep - that all makes a lot of sense.

The next issue will be what to do in the loaders.  We'll
probably need to add either a hinting mechanism or a callback
function.

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

[Plib-devel] A few problems

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

In ssgLoadAC, if a surface is textured, every surface after it that
doesn't have a texture gets textured with the previous texture
(gasp!). I solved it by setting current_texture to NULL at the
beginning of do_object in ssgLoadAC.cxx.

I tried to get the latest sources from CVS working, but had some
problems. Some stuff I haven't figured out, but here is the easy
stuff:

src/UL should be renamed to src/ul

You need to run autoconf/automake. I guess if someone is using CVS
they should have those tools anyway?

Some scripts that autoconf uses aren't there: missing, install-sh
and mkinstalldirs.

After fixing these things it compiles, but none of my programs will
work with it. I tried Tux AQFH too, but it dies in getMaterial because
ssgLeaf::getState always returns NULL.

Re: [Plib-devel] TerraPage

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

"Curtis L. Olson" wrote:

> 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.
>

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.

Regards,
Durk

Re: [Plib-devel] Vertex array code

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

"Vallevand, Mark K" wrote:
> 
> 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?

Yes, I think that for a small amount of vertices, the
array code will be slower than glBegin - glEnd,
but this should be tested and tuned, may be one of the
two paths is always better than the other.

> 
> 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
> 

Eric.

RE: [Plib-devel] Vertex array code

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

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
>