re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Norman Vine writes: I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib I saw a pretty-nice boost as well, for what it's worth. GeForce2Go 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, because I've been using the patched plib now for over a week, but it was at least 15-20%. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
David Megginson wrote: Norman Vine writes: I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib I saw a pretty-nice boost as well, for what it's worth. GeForce2Go 32MB, Linux drivers, 1600x1200x32 LCD. I don't remember what it was, because I've been using the patched plib now for over a week, but it was at least 15-20%. I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is small or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Andy Ross writes: I tried it too, and likewise saw a similar increase in framerate. Nonetheless, I think this is the Wrong Solution. What this patch does is test at render time whether or not the vertex array is small or not. If it is small, it renders the leaf with glVertex3f() calls instead of using the vertex arrays. Gack. Now, for plib as a library, this is a fine optimization that's probably worth including. I have no objections there. But for FlightGear as an application, the *real* performance bug is that we're generating really tiny ssgLeaf objects. Each tile is a single piece of static geometry. There's no reason that it couldn't live in just one vertex array (or maybe one per texture). Or be stored in a single display list, etc... But clearly the optimal performance solution we're looking for is not iterated glVertex() calls. :) I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson wrote: I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. The majority (I'm guessing 70%) of tiles are either rendered in their entirety or culled in their entirety. The tile would seem, to me, to be just about the right granularity for doing culling. Certainly culling on tiny 10 vertex objects is too fine-grained, no? You can DMA a *lot* of vertices across the AGP bus in the time that it takes to do that cull. If my 70% guess is correct, then doing culling at a tile level will send 15% (the remaining 30% of tiles are on average half-invisible) too many vertices to the card for each frame. Rendering out of large vertex arrays instead of doing glVertex() calls has to be worth at *least* 15%. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Curtis L. Olson writes: I'm not claiming we are currently optimal, but you also need to consider that by grouping your low level structures into larger chunks, you reduce the ability of the scene graph to do an early cull of non-visible stuff. Making larger chunks needs to be balanced against the benefits of scene graph culling that smaller chunks bring. To back Curt up here, culling matters a lot -- some people saw a 70% framerate drop when I tried disabling scene-graph culling for some branches. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Norman Vine wrote: Hi All I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib If you do test this please report back with your results and system type OS, CPU, GFX card OS = IRIX 6.5 CPU = RM5200/300Mhz GFX = O2/CRM graphics Default location went from 6.0 FPS to 7.5 FPS = 20% Default orientation Also, changing LOWER_BOUND to either 15, 25 or 35 showed 25 is probably the best value. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++)\
{ \
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]);\
} \
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
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) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
plib-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/plib-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
OS = Windows ME
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 67 FPS to 74 FPS = 10%
Default orientation
I also did some testing around both Seattle and Denver, mainly for the
complex terrain, and saw the following:
KSEA went from 18 FPS to 27 FPS = 50% improvement
KDEN went from 27 FPS to 35 FPS = 30% improvement
Although I have a sample size of only three, I was surprised to see the
more complex scene with such a significantly greater improvement.
Jonathan Polley
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++) \
{\
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]); \
}\
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
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) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
One more thing, the command line is configured as:
--fdm=ufo --disable-clouds --disable-panel --visibility-miles=50
On Tuesday, July 9, 2002, at 10:00 PM, Jonathan Polley wrote:
OS = Windows ME
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 67 FPS to 74 FPS = 10%
Default orientation
I also did some testing around both Seattle and Denver, mainly for the
complex terrain, and saw the following:
KSEA went from 18 FPS to 27 FPS = 50% improvement
KDEN went from 27 FPS to 35 FPS = 30% improvement
Although I have a sample size of only three, I was surprised to see the
more complex scene with such a significantly greater improvement.
Jonathan Polley
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype);\
for ( int i = 0; i num_vertices; i++) \
{ \
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]);\
if(t) glTexCoord2fv(texcoords[i]);\
glVertex3fv(vertices[i]); \
} \
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
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) ) ;
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
OS = Linux 2.4.18 CPU = P3-500 GFX = GF2 GTS 32MB VER = CVS from yesterday Default startup went from 13 fps to 16 fps = +23% I should note that I compiled everything with no optimizations and no in-lines since I've been using valgrind a lot lately. * [EMAIL PROTECTED] (Norman Vine) [2002.07.09 20:34]: Hi All I got a considerable boost in the frame rate from the following patch to PLib. ~25% at default startup location I am trying to determine if this also true for 'most' systems before advocating it's inclusion into PLib If you do test this please report back with your results and system type OS, CPU, GFX card Thanks Norman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Darrell Walisser Sent: Sunday, June 30, 2002 10:27 PM To: [EMAIL PROTECTED] Subject: [Plib-devel] ssg vertex tables tuning Hi all, While running FlightGear, I noticed a problem with PLIB's vertex tables. The implementation is fine, but performance was hideous on Mac OS X (like 5fps), even on a fast G4. I'm really curious if this is also a problem on other OS's. After some examination, it seems the majority of FlightGear's geometry is rendered in small triangle fans, of 5-10 vertices each, with the occasional big lump of vertices in a detailed area. Why is this a problem? Well, it turns out that the setup time for vertex arrays is actually slower than glVertex3fv() etc because there are so few vertices per table. So, I coded a solution that only kicks into the vertex array code if the number of vertices is beyond a certain threshold, otherwise it uses glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this value is probably highly system-dependent and we might want to make it configurable either at build-time or run-time. Here's the code (for ssgVtxTable.cxx). Having different versions of the inner loop is probably overkill, but you get the idea: snip/ -- Cameron Moore / I put tape on the mirrors in my house so I don't \ \ accidentally walk through into another dimension. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: [Plib-devel] ssg vertex tables tuning
I also rebuilt for my other two platforms, and here are the results:
OS = Red Hat 7.3
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 32 FPS to 38 FPS = 19%
Default orientation
OS = Mac OS X 10.1.5
CPU = G4 867 MHz
GFX = GeForce 3
Default location went from 12 FPS to 34 FPS = 183% (I double checked this)
!
Default orientation
On Tuesday, July 9, 2002, at 08:37 PM, Norman Vine wrote:
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. ~25% at default startup location
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system type OS, CPU, GFX card
Thanks
Norman
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Darrell
Walisser
Sent: Sunday, June 30, 2002 10:27 PM
To: [EMAIL PROTECTED]
Subject: [Plib-devel] ssg vertex tables tuning
Hi all,
While running FlightGear, I noticed a problem with PLIB's vertex
tables. The implementation is fine, but performance was hideous on Mac
OS X (like 5fps), even on a fast G4. I'm really curious if this is also
a problem on other OS's.
After some examination, it seems the majority of FlightGear's geometry
is rendered in small triangle fans, of 5-10 vertices each, with the
occasional big lump of vertices in a detailed area. Why is this a
problem? Well, it turns out that the setup time for vertex arrays is
actually slower than glVertex3fv() etc because there are so few vertices
per table.
So, I coded a solution that only kicks into the vertex array code if the
number of vertices is beyond a certain threshold, otherwise it uses
glVerte3fv(). I picked 25 as the lower bound for vertex arrays, but this
value is probably highly system-dependent and we might want to make it
configurable either at build-time or run-time.
Here's the code (for ssgVtxTable.cxx). Having different versions of the
inner loop is probably overkill, but you get the idea:
void ssgVtxTable::draw_geometry ()
{
const int LOWER_BOUND = 25;
int num_vertices = getNumVertices () ;
int num_colours = getNumColours () ;
int num_normals = getNumNormals () ;
int num_texcoords = getNumTexCoords () ;
if ( num_colours == 0 ) glColor4f ( 1.0f, 1.0f, 1.0f, 1.0f ) ;
if ( num_colours == 1 ) glColor4fv ( colours - get(0) ) ;
if ( num_normals == 1 ) glNormal3fv ( normals - get(0) ) ;
#define LOOP(c,n,t) do { \
glBegin(gltype); \
for ( int i = 0; i num_vertices; i++) \
{\
if(c) glColor3fv(colors[i]); \
if(n) glNormal3fv(normals[i]); \
if(t) glTexCoord2fv(texcoords[i]); \
glVertex3fv(vertices[i]); \
}\
glEnd();\
} while(0)
// write out the branches
// to keep branches out of the inner loop
if (num_vertices LOWER_BOUND) {
float *tmp;
tmp = colours-get(0); sgVec4 *colors= (sgVec4*) tmp;
tmp = normals-get(0); sgVec3 *normals = (sgVec3*) tmp;
tmp = texcoords-get(0); sgVec2 *texcoords = (sgVec2*) tmp;
tmp = vertices-get(0); sgVec3 *vertices = (sgVec3*) tmp;
if ( num_colours 1 ) {
if ( num_normals 1 ) {
if ( num_texcoords 1 )
LOOP(1,1,1);
else
LOOP(1,1,0);
}
else if ( num_texcoords 1 ) {
LOOP(1,0,1);
}
else {
LOOP(1,0,0);
}
}
else if ( num_normals 1 ) {
if ( num_texcoords 1 ) {
LOOP(0,1,1);
}
else {
LOOP(0,1,0);
}
}
else if ( num_texcoords 1 ) {
LOOP(0,0,1);
}
else {
LOOP(0,0,0);
}
}
else {
glPushClientAttrib ( GL_CLIENT_VERTEX_ARRAY_BIT ) ;
if ( num_colours 1 )
{
glEnableClientState ( GL_COLOR_ARRAY ) ;
glColorPointer ( 4, GL_FLOAT, 0, colours-get(0) ) ;
}
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) ) ;
glDrawArrays ( gltype, 0, num_vertices ) ;
glPopClientAttrib () ;
}
}
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
plib-devel mailing list
[EMAIL PROTECTED]
