I am attempting a very simple animation of traveling down a road.  That is 
it.  No texture, no shading models, nothing fancy.  Here is (what I think) 
is the relevant part of the program (Win32 API and OpenGL):

/***********************************************************************************/

     // The painting function. This message is sent by Windows
    // whenever the screen needs updating.
    case WM_PAINT:
   {

   /////////////////////////////
   // Begin drawing section:
   /////////////////////////////

            // Get a DC, then make the RC current and
            // associated with this DC
            hDC = GetDC(hWnd);
            wglMakeCurrent( hDC, hRC );

   // Setup the scene:
   SetupRC();

   // Compute the camera position and aiming point (line-of-sight)
   Locate(&Cam_x, &CamHt, &Cam_z, &xlos, &ylos, &zlos, &lFootNumber);

   // Initialize camera position
   glLoadIdentity();                                 // Clear the matrix
   gluLookAt(Cam_x, CamHt, Cam_z, xlos, ylos, zlos, 0.0, Up, 0.0); // Aim 
camera

   // Draw the scene:
   RenderScene();

   // Bring image to front
   SwapBuffers(hDC);

   // Update number of feet traveled (aka frame number) to advance along 
track
   lFootNumber++;

   ///////////////////////////
   // End drawing section
   ///////////////////////////

   // Do NOT validate, forcing a continuous repaint

   }
            break;

/*************************************************************************/


The function "Locate" simply does some simple calculations to figure out 
where it should be as if a driver on the road were filming while driving 
(not recommended in real life).

"RenderScene" merely consists of :


/***************************/

// Called to draw the entire scene.
// Units are feet.
void RenderScene(void)
{
 glCallList(SCENE_LIST);

 // Flush drawing commands
 glFlush();

/**************************/


and the scene list is made up in another file (which I don't think is the 
problem).  Basically I want to advance a "foot" a frame where the 
perspective is one of an actual driver (i.e. scaled as such).

Here is how I made up the road:

1) I made a big array containing the road centerline coordinates every foot 
of arc length (closed course).  Every foot was an increment of one in the 
array index.  In other words, i = 100 represents 100 feet along the course

2) I called the function to compute the array precisely *once* and used the 
C keyword "extern" to let other functions access it without having to 
recompute it.

3) I used the centerline array to make the sides of the road (also only done 
once and used "extern").

4) I stitch together the road using GL_TRIANGLE_STRIP (again points about 
every foot either side of the road)

5) I give it a broken yellow line using GL_QUADS.

While the course is a few "miles" around (~6) only a few thousand feet show 
at a time (just like looking at a highway while driving.  Not counting the 
clear background color, I use 3 colors.  That is it--a very, very simple 
picture.

The picture looks (reasonably) good and it *does run* and follow the course 
but the animation is INSANELY SLOW.  It takes about 1/2 second per frame.  I 
previously had a function using:



/**********/
 ulStartT = GetTickCount();

 do
 {

 }while( (GetTickCount() - ulStartT) < 10);

/**********/

to try to set the time/frame rate to "real" time but I take this out and the 
thing runs "flat out" at ~ 1/2 frame per sec.

I must be doing something horribly wrong as my machine isn't that old (1 GB, 
1.54 GHz), commercial video games run fine and the blasted program isn't 
noticably faster on a better machine with a better video card.  The picture 
is very, very simple.

Anybody got any ideas?  I don't know if the problem is OGL or Win32.  (I am 
not a professional programmer and only used Win32 API w/ the OpenGL because 
"plain" OGL seemed too limiting; therefore please don't reply with too much 
jargon or tell me to read an 800 page book)

Kent 

kent.christianson wrote:
> 
> I must be doing something horribly wrong as my machine isn't that old (1 GB, 
> 1.54 GHz), commercial video games run fine and the blasted program isn't 
> noticably faster on a better machine with a better video card.  The picture 
> is very, very simple.
> 

I think you're probably getting software rendering.

What does "glGetString(GL_VENDOR)" return?
If it says "Microsoft..." then you need to look
at your setup and find out what went wrong.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:6M2vh.15877$8f.12976@news.ono.com...
> kent.christianson wrote:
>>
>> I must be doing something horribly wrong as my machine isn't that old (1 
>> GB, 1.54 GHz), commercial video games run fine and the blasted program 
>> isn't noticably faster on a better machine with a better video card.  The 
>> picture is very, very simple.
>>
>
> I think you're probably getting software rendering.
>
> What does "glGetString(GL_VENDOR)" return?
> If it says "Microsoft..." then you need to look
> at your setup and find out what went wrong.
>
>
> -- 
> <\___/>
> / O O \
> \_____/  FTB.    For email, remove my socks.
>
>
> We�re judging how a candidate will handle a nuclear
> crisis by how well his staff creates campaign ads.
> It�s a completely nonsensical process.

The command "glGetString(GL_VENDOR)" gives me: NVIDIA Corportation and 
GL_RENDERER ==> GeForce4 MX 440/AGP/SSE/3DNOW! and GL_VERSION ==> 1.5.7

That seems (unfortunately) like I am using the hardware.  Even if nothing 
else is running (well of course a few normal background processes for the 
OS) I still only get about 2 frames per second on a very simple picture.  I 
must be doing something fundamentally wrong but I have no clue as to what it 
is.

Could using (time) changing arguments in "gluLookAt()" instead of using 
"glRotatef()" and "glTranslatef()" be causing the problem?  I know I could 
change it and see but I don't want to take time recoding if someone already 
is sure the answer is no.

What kind of programming mistake in people's experience might cause (really) 
slow animation? 

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:6M2vh.15877$8f.12976@news.ono.com...
> kent.christianson wrote:
>>
>> I must be doing something horribly wrong as my machine isn't that old (1 
>> GB, 1.54 GHz), commercial video games run fine and the blasted program 
>> isn't noticably faster on a better machine with a better video card.  The 
>> picture is very, very simple.
>>
>
> I think you're probably getting software rendering.
>
> What does "glGetString(GL_VENDOR)" return?
> If it says "Microsoft..." then you need to look
> at your setup and find out what went wrong.
>
>
> -- 
> <\___/>
> / O O \
> \_____/  FTB.    For email, remove my socks.
>
>
> We�re judging how a candidate will handle a nuclear
> crisis by how well his staff creates campaign ads.
> It�s a completely nonsensical process.


(Sorry in advance if this message posts twice but I got an error on the 1st 
try)
The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 MX 
440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.

Thus it seems (to me) that, unfortunately, it is rendering w/ the hardware.

I think I must be doing something fundamentally wrong in the programming but 
I have no clue what it is.  Could there be a difference in updating 
"gluLookAt" rather than "glRotatef" and "glTranslatef"?  I realize I could 
recode and see but if someone is already sure that the answer is no, I won't 
take the time.

What in people's experience is a typical novice error in programming OpenGL 
w/ the Win32 API if a) the scene looks right, b) is very simple, c) the 
machine is not new but not ancient either and d) the picture animates but 
just super slow (2 frames a second)?

Kent

kent.christianson wrote:

> "fungus" <umailMY@SOCKSartlum.com> wrote in message
> news:6M2vh.15877$8f.12976@news.ono.com...
>> kent.christianson wrote:
>>>
>>> I must be doing something horribly wrong as my machine isn't that old (1
>>> GB, 1.54 GHz), commercial video games run fine and the blasted program
>>> isn't noticably faster on a better machine with a better video card. 
>>> The picture is very, very simple.
>>>
>>
>> I think you're probably getting software rendering.
>>
>> What does "glGetString(GL_VENDOR)" return?
>> If it says "Microsoft..." then you need to look
>> at your setup and find out what went wrong.
>>
>>
>> --
>> <\___/>
>> / O O \
>> \_____/  FTB.    For email, remove my socks.
>>
>>
>> We�re judging how a candidate will handle a nuclear
>> crisis by how well his staff creates campaign ads.
>> It�s a completely nonsensical process.
> 
> 
> (Sorry in advance if this message posts twice but I got an error on the
> 1st try)
> The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 MX
> 440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.
> 
> Thus it seems (to me) that, unfortunately, it is rendering w/ the
> hardware.

Well, you're using a hadware accelerated OpenGL driver. However, if you are
using some feature that your graphics card doesn't support, the driver
might fall back to software rendering.
Btw: How many polygones does your scene have in total?

> I think I must be doing something fundamentally wrong in the programming
> but I have no clue what it is.  Could there be a difference in updating
> "gluLookAt" rather than "glRotatef" and "glTranslatef"? 

No.

"Rolf Magnus" <ramagnus@t-online.de> wrote in message 
news:epkj5c$iog$03$1@news.t-online.com...

>> (Sorry in advance if this message posts twice but I got an error on the
>> 1st try)
>> The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 MX
>> 440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.
>>
>> Thus it seems (to me) that, unfortunately, it is rendering w/ the
>> hardware.
>
> Well, you're using a hadware accelerated OpenGL driver. However, if you 
> are
> using some feature that your graphics card doesn't support, the driver
> might fall back to software rendering.
> Btw: How many polygones does your scene have in total?
>
>> I think I must be doing something fundamentally wrong in the programming
>> but I have no clue what it is.  Could there be a difference in updating
>> "gluLookAt" rather than "glRotatef" and "glTranslatef"?
>
> No.
>

I have about 90,000 polygons.  But most of these aren't needed at any given 
time.  I compute all the vertex coordinates once right off the bat and store 
them in a global array using "extern" (in C not C++).

Since my picture is simply a road (closed course track) you only see a few 
thousand "feet" out of a course that is ~ 6 "miles" around.  The rest of the 
road tails off to the vanishing point on the horizon (e.g. a pixel or two). 
I should also add that this road is entirely on a single colored plane.  The 
3D aspect of OpenGL is only used for the perspective (and maybe I'll add 
telephone poles if I ever get this running right).

Thus nothing changes in the height coordinate.  The track is confined to a 
flat plane; it is like driving in Kansas.  The plane on which the road sits 
is a single color, no texture and was made from two giant triangles.

Thus 3 colors (not counting the background), no textures, and only a portion 
of the road is seen at a time due to the vanishing point.  It looks fine. 
It does animate but it is slow as molasses in winter!  I have no clue how to 
proceed.

kent.christianson wrote:
> 
>>> The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 MX
>>> 440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.
>>>
>>
> I have about 90,000 polygons.

On an old GeForce4 that's an awful lot of polygons.


> Thus 3 colors (not counting the background), no textures, and only a portion 
> of the road is seen at a time due to the vanishing point.  It looks fine. 
> It does animate but it is slow as molasses in winter!  I have no clue how to 
> proceed.
> 

You need to chop it into pieces and discard all but
the most visible sections when you render it.



-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.

"fungus" <umailMY@SOCKSartlum.com> wrote in message 
news:Xylvh.6401$%e5.4315@news.ono.com...
> kent.christianson wrote:
>>
>>>> The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 
>>>> MX
>>>> 440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.
>>>>
>>>
>> I have about 90,000 polygons.
>
> On an old GeForce4 that's an awful lot of polygons.
>
>
>> Thus 3 colors (not counting the background), no textures, and only a 
>> portion of the road is seen at a time due to the vanishing point.  It 
>> looks fine. It does animate but it is slow as molasses in winter!  I have 
>> no clue how to proceed.
>>
>
> You need to chop it into pieces and discard all but
> the most visible sections when you render it.
>
>
>
> -- 
> <\___/>
> / O O \
> \_____/  FTB.    For email, remove my socks.
>
>
> We�re judging how a candidate will handle a nuclear
> crisis by how well his staff creates campaign ads.
> It�s a completely nonsensical process.


I'm not so sure.  I just used gluPerspective to chop things off at 15 feet 
instead of 26000.  That is on the order of 30 polygons and the thing runs 
*just as slow*.  Yes, I still compute all the thousands of vertices, but 
only once right out of the gate.  Thus it has the vertices in memory 
("extern" on the array) and now it only has to draw about 30 triangles per 
frame.  I also rewrote the program to be a "pure" OpenGL program (console 
application) without using any Win32 API, although it still needs 
<windows.h> for the OpenGL.

It is still as slow as ever!

Kent 

"kent.christianson" <kent.christianson@comcast.net> wrote in message 
news:88-dnWLfCZHVcCDYnZ2dnUVZ_uejnZ2d@comcast.com...
>
> "fungus" <umailMY@SOCKSartlum.com> wrote in message 
> news:Xylvh.6401$%e5.4315@news.ono.com...
>> kent.christianson wrote:
>>>
>>>>> The command GL_VENDOR ==> NVIDIA Corporation, GL_RENDERER ==> GeForce4 
>>>>> MX
>>>>> 440/AGP/SSE/3DNOW! while GL_VERSION ==> 1.5.7.
>>>>>
>>>>
>>> I have about 90,000 polygons.
>>
>> On an old GeForce4 that's an awful lot of polygons.
>>
>>
>>> Thus 3 colors (not counting the background), no textures, and only a 
>>> portion of the road is seen at a time due to the vanishing point.  It 
>>> looks fine. It does animate but it is slow as molasses in winter!  I 
>>> have no clue how to proceed.
>>>
>>
>> You need to chop it into pieces and discard all but
>> the most visible sections when you render it.
>>
>>
>>
>> -- 
>> <\___/>
>> / O O \
>> \_____/  FTB.    For email, remove my socks.
>>
>>
>> We�re judging how a candidate will handle a nuclear
>> crisis by how well his staff creates campaign ads.
>> It�s a completely nonsensical process.
>
>
> I'm not so sure.  I just used gluPerspective to chop things off at 15 feet 
> instead of 26000.  That is on the order of 30 polygons and the thing runs 
> *just as slow*.  Yes, I still compute all the thousands of vertices, but 
> only once right out of the gate.  Thus it has the vertices in memory 
> ("extern" on the array) and now it only has to draw about 30 triangles per 
> frame.  I also rewrote the program to be a "pure" OpenGL program (console 
> application) without using any Win32 API, although it still needs 
> <windows.h> for the OpenGL.
>
> It is still as slow as ever!
>
> Kent
>
Ah, we are getting somewhere...

How exactly are you  "chopping off" the polygons? Clipping planes on 
consumer cards is done in *software*.The question is, how many polygons (not 
just visible) are you sending to opengl for every frame? All 90,000 of them, 
even if only 30 are visible ? And, by what means? (Immediate mode, display 
lists, vertex arrays, or vertex buffer objects)?

jbw

kent.christianson wrote:

> I have about 90,000 polygons.  But most of these aren't needed at any given 
> time.  I compute all the vertex coordinates once right off the bat and store 
> them in a global array using "extern" (in C not C++).

Well, what you need to do is make sure you're not drawing every one of them
every frame. Ideally you'd use some form of region query to limit the polygons
you're drawing, and cull those whose level of detail adds nothing to the scene.
Without knowing what kind of data structures you're using its hard to say.

- Keith

"Keith S." <I'm_pink_therefore_I'm_spam@ntlworld.com> wrote in message 
news:44pvh.61703$v4.30357@newsfe3-win.ntli.net...
> kent.christianson wrote:
>
>> I have about 90,000 polygons.  But most of these aren't needed at any 
>> given time.  I compute all the vertex coordinates once right off the bat 
>> and store them in a global array using "extern" (in C not C++).
>
> Well, what you need to do is make sure you're not drawing every one of 
> them
> every frame. Ideally you'd use some form of region query to limit the 
> polygons
> you're drawing, and cull those whose level of detail adds nothing to the 
> scene.
> Without knowing what kind of data structures you're using its hard to say.
>
> - Keith

I am using display lists.  I thought that would speed things up, but as I 
said in my original post, I am just learning this stuff.  I thought that 
gluPerspective would not bother with the stuff beyond its arguments whether 
it is done in software or hardware.  Thus when I made it 15 feet (from 
26000) and the road in front of me is just chopped off after a very short 
stretch, I was very surprised that it still ran every bit as slow.

The whole program is a bit much to show here but this is the relevant road 
building section:

/***************************************************/

void RenderRoad(void)
{
 long j;  // Counter

 // Dark gray for road surface
 glColor3f(0.15f, 0.15f, 0.15f);

 // Lay down the pavement
 glBegin(GL_TRIANGLE_STRIP);

   // The normal for the plane points straight up the y axis
   glNormal3f(0.0f, 1.0f, 0.0f);

   for(j = 0; j < 32380; j++)  // OpenGL coordinates [pt #][0=left, 
1=right][x,y,z]
   {
    // Left side of road
    glVertex3f(road[j][0][0], road[j][0][1], road[j][0][2]);

    // Right side of road
    glVertex3f(road[j][1][0], road[j][1][1], road[j][1][2]);
   }

 glEnd();

 // Road almost closes. Patch inner road & make white starting line

 glBegin(GL_QUADS);    // Patch
   glNormal3f(0.0f, 1.0f, 0.0f);
   glVertex3f(-15.0f,0.25f,1.0f);
   glVertex3f(0.0f,0.25f,1.0f);
   glVertex3f(0.0f,0.25f,0.0f);
   glVertex3f(-15.0f,0.25f,0.0f);
 glEnd();

 glColor3f(1.0f, 1.0f, 1.0f); // White

 glBegin(GL_QUADS);    // Start line
   glNormal3f(0.0f, 1.0f, 0.0f);
   glVertex3f(0.0f,0.25f,1.0f);
   glVertex3f(15.0f,0.25f,1.0f);
   glVertex3f(15.0f,0.25f,0.0f);
   glVertex3f(0.0f,0.25f,0.0f);
 glEnd();

}
/*****************************************/

The float array "road[32380][2][3]" is computed/filled once near the start 
of "WinMain" (or "main" if I drop the Win32 API & just write a console app); 
its creation is too long to show here.  This is a global array.

Here is the display list creation:

/***************************************/
void SetupRC(void)
{

 // Sky blue background
 glClearColor(0.3f, 0.3f, 1.0f, 1.0f);

 // Create display list for the plane
 glNewList(PLANE_LIST, GL_COMPILE);
   RenderPlane();
 glEndList();

 // Create display list for the road
 glNewList(ROAD_LIST, GL_COMPILE);
   RenderRoad();
 glEndList();

 // Create display list for the centerline
 glNewList(CENTER_LIST, GL_COMPILE);
   RenderCenterLine();
 glEndList();

 // Create nested display list for the *entire* environment
 glNewList(SCENE_LIST, GL_COMPILE);

   // Clear the window with the current clearing color
   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

   // Make sure that we have the correct matrix mode.
   glMatrixMode(GL_MODELVIEW);

   // Render the plane
   glCallList(PLANE_LIST);


   // Render the road and centerline together
   glCallList(ROAD_LIST);
   glCallList(CENTER_LIST);

 // End environment list
 glEndList();
}


// Called to draw the entire scene.
// Units are feet.
void RenderScene(void)
{
 glCallList(SCENE_LIST);

 // Flush drawing commands
 glFlush();
}

/**********************************************************/

How can I be sure that the rendering is my problem?  Is there some good way 
to measure/query the system how long the drawing *itself* is taking?  Or 
display list creation?  In other words, how do I zero in on the part that is 
slowing everything down?  As I've said before, I'm not a professional 
programmer so please no "super inside baseball" type answers if you know.  I 
know C but not C++ and I debug with print statements ;-)

Kent 

"kent.christianson" <kent.christianson@comcast.net> wrote in message 
news:YLadnbNghJL67iPYnZ2dnUVZ_q2pnZ2d@comcast.com...
>
> "Keith S." <I'm_pink_therefore_I'm_spam@ntlworld.com> wrote in message 
> news:44pvh.61703$v4.30357@newsfe3-win.ntli.net...
>> kent.christianson wrote:
>>
>>> I have about 90,000 polygons.  But most of these aren't needed at any 
>>> given time.  I compute all the vertex coordinates once right off the bat 
>>> and store them in a global array using "extern" (in C not C++).
>>
>> Well, what you need to do is make sure you're not drawing every one of 
>> them
>> every frame. Ideally you'd use some form of region query to limit the 
>> polygons
>> you're drawing, and cull those whose level of detail adds nothing to the 
>> scene.
>> Without knowing what kind of data structures you're using its hard to 
>> say.
>>
>> - Keith
>
> I am using display lists.  I thought that would speed things up, but as I 
> said in my original post, I am just learning this stuff.  I thought that 
> gluPerspective would not bother with the stuff beyond its arguments 
> whether it is done in software or hardware.  Thus when I made it 15 feet 
> (from 26000) and the road in front of me is just chopped off after a very 
> short stretch, I was very surprised that it still ran every bit as slow.
>
> The whole program is a bit much to show here but this is the relevant road 
> building section:
>
> /***************************************************/
>
> void RenderRoad(void)
> {
> long j;  // Counter
>
> // Dark gray for road surface
> glColor3f(0.15f, 0.15f, 0.15f);
>
> // Lay down the pavement
> glBegin(GL_TRIANGLE_STRIP);
>
>   // The normal for the plane points straight up the y axis
>   glNormal3f(0.0f, 1.0f, 0.0f);
>
>   for(j = 0; j < 32380; j++)  // OpenGL coordinates [pt #][0=left, 
> 1=right][x,y,z]
>   {
>    // Left side of road
>    glVertex3f(road[j][0][0], road[j][0][1], road[j][0][2]);
>
>    // Right side of road
>    glVertex3f(road[j][1][0], road[j][1][1], road[j][1][2]);
>   }
>
> glEnd();
>
> // Road almost closes. Patch inner road & make white starting line
>
> glBegin(GL_QUADS);    // Patch
>   glNormal3f(0.0f, 1.0f, 0.0f);
>   glVertex3f(-15.0f,0.25f,1.0f);
>   glVertex3f(0.0f,0.25f,1.0f);
>   glVertex3f(0.0f,0.25f,0.0f);
>   glVertex3f(-15.0f,0.25f,0.0f);
> glEnd();
>
> glColor3f(1.0f, 1.0f, 1.0f); // White
>
> glBegin(GL_QUADS);    // Start line
>   glNormal3f(0.0f, 1.0f, 0.0f);
>   glVertex3f(0.0f,0.25f,1.0f);
>   glVertex3f(15.0f,0.25f,1.0f);
>   glVertex3f(15.0f,0.25f,0.0f);
>   glVertex3f(0.0f,0.25f,0.0f);
> glEnd();
>
> }
> /*****************************************/
>
> The float array "road[32380][2][3]" is computed/filled once near the start 
> of "WinMain" (or "main" if I drop the Win32 API & just write a console 
> app); its creation is too long to show here.  This is a global array.
>
> Here is the display list creation:
>
> /***************************************/
> void SetupRC(void)
> {
>
> // Sky blue background
> glClearColor(0.3f, 0.3f, 1.0f, 1.0f);
>
> // Create display list for the plane
> glNewList(PLANE_LIST, GL_COMPILE);
>   RenderPlane();
> glEndList();
>
> // Create display list for the road
> glNewList(ROAD_LIST, GL_COMPILE);
>   RenderRoad();
> glEndList();
>
> // Create display list for the centerline
> glNewList(CENTER_LIST, GL_COMPILE);
>   RenderCenterLine();
> glEndList();
>
> // Create nested display list for the *entire* environment
> glNewList(SCENE_LIST, GL_COMPILE);
>
>   // Clear the window with the current clearing color
>   glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
>   // Make sure that we have the correct matrix mode.
>   glMatrixMode(GL_MODELVIEW);
>
>   // Render the plane
>   glCallList(PLANE_LIST);
>
>
>   // Render the road and centerline together
>   glCallList(ROAD_LIST);
>   glCallList(CENTER_LIST);
>
> // End environment list
> glEndList();
> }
>
>
> // Called to draw the entire scene.
> // Units are feet.
> void RenderScene(void)
> {
> glCallList(SCENE_LIST);
>
> // Flush drawing commands
> glFlush();
> }
>
> /**********************************************************/
>
> How can I be sure that the rendering is my problem?  Is there some good 
> way to measure/query the system how long the drawing *itself* is taking? 
> Or display list creation?  In other words, how do I zero in on the part 
> that is slowing everything down?  As I've said before, I'm not a 
> professional programmer so please no "super inside baseball" type answers 
> if you know.  I know C but not C++ and I debug with print statements ;-)
>
> Kent
>

OK, so you ARE drawing everything (and in just about the least efficient way 
possible).
Yes, OpenGL will throw away stiff that's clipped, but it has to get to the 
driver first, so that's a lots of vertex data to get sent to the graphics 
card. NVIDIA drivers can be fiercely fast about clipping geometry but in 
this case evidently not.

Look at as some quick suggestions:
0) You aren't calling SetupRC more than once, are you ?
1) Vertex Buffer Objects to speed up the loading of the data
2) are you using single-buffering? You should use double buffering, draw to 
the back buffer and swapbuffers() at the end rather than glFlush.
3) Splitting up your data structures to be able to throw away big chunks at 
a time (yourself) with a bounding-box clip test (look up view frustum 
culling algorithms). 

"jbwest" <jbwest@comcast.net> wrote in message 
news:3_GdnfEGN5TjMCPYnZ2dnUVZ_v2nnZ2d@comcast.com...
>
> OK, so you ARE drawing everything (and in just about the least efficient 
> way possible).
> Yes, OpenGL will throw away stiff that's clipped, but it has to get to the 
> driver first, so that's a lots of vertex data to get sent to the graphics 
> card. NVIDIA drivers can be fiercely fast about clipping geometry but in 
> this case evidently not.
>
> Look at as some quick suggestions:
> 0) You aren't calling SetupRC more than once, are you ?
> 1) Vertex Buffer Objects to speed up the loading of the data
> 2) are you using single-buffering? You should use double buffering, draw 
> to the back buffer and swapbuffers() at the end rather than glFlush.
> 3) Splitting up your data structures to be able to throw away big chunks 
> at a time (yourself) with a bounding-box clip test (look up view frustum 
> culling algorithms).
>

Ok I think I (mostly) solved my problem.

While the number of polygons is closer to 60,000 than the 90,000 I stated
earlier, trying to "draw" this many (with most of them offscreen!) was the
difficulty.  If I only lay down the 1st 3000 feet of road (6,000
triangles--10 fold reduction) leaving everything else the same then I go 20x
faster.

So now I have a different question.  I have (all along) computed all the
vertices and put them in a big, global array ("road[ ][ ][ ]") so that they
never have to be recomputed.  What is the best way to use these to get
efficient computation?  Is there a better way than this:


/*********** k represents the current position along the road in feet from
the start*******/

 // Lay down the pavement
 glBegin(GL_TRIANGLE_STRIP);

   // The normal for the plane points straight up the y axis
   glNormal3f(0.0f, 1.0f, 0.0f);

   for(j = k; j < k+3000; j++)  // OpenGL coordinates [pt #][0=left,
1=right][x,y,z]
   {
    // Left side of road
    glVertex3f(road[j][0][0], road[j][0][1], road[j][0][2]);

    // Right side of road
    glVertex3f(road[j][1][0], road[j][1][1], road[j][1][2]);
   }

 glEnd();

/*********************end of code fragment********************/

Kent

kent.christianson wrote:

> So now I have a different question.  I have (all along) computed all the
> vertices and put them in a big, global array ("road[ ][ ][ ]") so that they
> never have to be recomputed.  What is the best way to use these to get
> efficient computation?  Is there a better way than this:

Well, a very simple modification that may help would be to use glDrawArrays
and pass a pointer to your array position. Look at the Vertex Arrays section
in the red book.

- Keith

Keith S. wrote:

> kent.christianson wrote:
> 
>> So now I have a different question.  I have (all along) computed all the
>> vertices and put them in a big, global array ("road[ ][ ][ ]") so that
>> they
>> never have to be recomputed.  What is the best way to use these to get
>> efficient computation?  Is there a better way than this:
> 
> Well, a very simple modification that may help would be to use
> glDrawArrays and pass a pointer to your array position. Look at the Vertex
> Arrays section in the red book.

The OP is storing it all in a display list, so this should improve initial
loading time a bit, but not the frame rate.

Rolf Magnus wrote:

> The OP is storing it all in a display list, so this should improve initial
> loading time a bit, but not the frame rate.

I'm not sure why bother putting it in a display list. If the DL is
recomputed every frame what's the advantage?

- Keith

Keith S. wrote:

> Rolf Magnus wrote:
> 
>> The OP is storing it all in a display list, so this should improve
>> initial loading time a bit, but not the frame rate.
> 
> I'm not sure why bother putting it in a display list. If the DL is
> recomputed every frame what's the advantage?

That's the point. It isn't. As far as I understand the OP, the display list
is filled only once at start-up.

"Rolf Magnus" <ramagnus@t-online.de> wrote in message 
news:epnqj7$65r$00$2@news.t-online.com...
> Keith S. wrote:
>
>> Rolf Magnus wrote:
>>
>>> The OP is storing it all in a display list, so this should improve
>>> initial loading time a bit, but not the frame rate.
>>
>> I'm not sure why bother putting it in a display list. If the DL is
>> recomputed every frame what's the advantage?
>
> That's the point. It isn't. As far as I understand the OP, the display 
> list
> is filled only once at start-up.
>

As I posted earlier, I cut the number of triangles from 60,000 to about 
6,000 by just showing the "road ahead" as opposed to "rendering" (w/ most of 
it offscreen!) the whole roadway.  This was the big problem.  This gave me a 
factor of 20 in speed; it was like running 40 mph instead of 2 mph.  (Those 
are the actual "speeds" the driver appeared to be traveling.)

Thus I kept the centerline array in the display list (810 quads representing 
the broken yellow stripes on the highway) along with the two big triangles 
representing the plane on which the roadway sits, but I took the road itself 
out of the display list and just display the next 3,000 feet (6,000 
triangles) as the driver advances (1 foot per frame).

To keep the lighting and roadway vertex computations from being done more 
than once I did this:

/*************************/

static int succeed = FALSE;  // Used to make sure SetupRC() is only done 
once
..
..
..
// Setup the scene (but only once):
   if(!succeed)
   {
    SetupRC();
    succeed = TRUE;
   }

/***********************/

and similarly for Track() (roadway vertices).


Still, I must be doing something else wrong as the animation starts off 
great for about 4,000 frames (1 foot per frame) then suddenly the road 
flashes in and out, the window becomes nonresponsive to moving (I can quit 
though) and the motion becomes jerky.  Something in memory must be getting 
filled up but I'm not sure what.

Kent

"kent.christianson" <kent.christianson@comcast.net> wrote in message 
news:EtmdnaG729iPIyLYnZ2dnUVZ_h6vnZ2d@comcast.com...
>
> "Rolf Magnus" <ramagnus@t-online.de> wrote in message 
> news:epnqj7$65r$00$2@news.t-online.com...
>> Keith S. wrote:
>>
>>> Rolf Magnus wrote:
>>>
>>>> The OP is storing it all in a display list, so this should improve
>>>> initial loading time a bit, but not the frame rate.
>>>
>>> I'm not sure why bother putting it in a display list. If the DL is
>>> recomputed every frame what's the advantage?
>>
>> That's the point. It isn't. As far as I understand the OP, the display 
>> list
>> is filled only once at start-up.
>>
>
> As I posted earlier, I cut the number of triangles from 60,000 to about 
> 6,000 by just showing the "road ahead" as opposed to "rendering" (w/ most 
> of it offscreen!) the whole roadway.  This was the big problem.  This gave 
> me a factor of 20 in speed; it was like running 40 mph instead of 2 mph. 
> (Those are the actual "speeds" the driver appeared to be traveling.)
>
> Thus I kept the centerline array in the display list (810 quads 
> representing the broken yellow stripes on the highway) along with the two 
> big triangles representing the plane on which the roadway sits, but I took 
> the road itself out of the display list and just display the next 3,000 
> feet (6,000 triangles) as the driver advances (1 foot per frame).
>
> To keep the lighting and roadway vertex computations from being done more 
> than once I did this:
>
> /*************************/
>
> static int succeed = FALSE;  // Used to make sure SetupRC() is only done 
> once
> .
> .
> .
> // Setup the scene (but only once):
>   if(!succeed)
>   {
>    SetupRC();
>    succeed = TRUE;
>   }
>
> /***********************/
>
> and similarly for Track() (roadway vertices).
>
>
> Still, I must be doing something else wrong as the animation starts off 
> great for about 4,000 frames (1 foot per frame) then suddenly the road 
> flashes in and out, the window becomes nonresponsive to moving (I can quit 
> though) and the motion becomes jerky.  Something in memory must be getting 
> filled up but I'm not sure what.
>
> Kent
>
>

That might be a precision problem with clipping and viewing parameters. 
Single precision math & all.

Far/near ratio should not increase or your animation will get progressively 
worse.

jbw

Rolf Magnus schrieb:
> Keith S. wrote:
> 
>> Rolf Magnus wrote:
>>
>>> The OP is storing it all in a display list, so this should improve
>>> initial loading time a bit, but not the frame rate.
>> I'm not sure why bother putting it in a display list. If the DL is
>> recomputed every frame what's the advantage?
> 
> That's the point. It isn't. As far as I understand the OP, the display list
> is filled only once at start-up.
> 

according to his source code, the display list rebuilt *every* frame in
the SetupRC() routine, which is truly the worst thing one can make.

Change your code to built the display lists only once on your first
frame, then your frame rate should be boosted!

regards Ralph

kent.christianson wrote:
> to try to set the time/frame rate to "real" time but I take this out and
> the thing runs "flat out" at ~ 1/2 frame per sec.

There are lots of problems here.

Firstly, you are using very old hardware and most people on this list will
not be aware of the limitations of your hardware. Specifically, the nVidia
drivers can slow down by orders of magnitude for display lists containing
over about 2^15 (=32,768) vertices on old graphics cards. The next
generation have a 2^20 internal limit. I haven't hit this at all with my
current card (GF7900GT).

Make sure you use COMPILE to compile the display list and only do this once,
the first time it is used.

There is no advantage in using a global array because the vertex data are
copied by the OpenGL driver as you create the display list. If you choose
to drop the display list (e.g. to use dynamic geometry) then you'll want a
vertex buffer object (VBO) and not your global array.

GL errors can be a major cause of slow down. Check the GL to make sure no
errors are outstanding and, if they are, fix them. For example, you may
have forgotten a glEnd().

I wrote a similarly naive demo recently and it handles 70k triangles with no
problems:

  http://www.ffconsultancy.com/free/bunny/

albeit on a much faster machine.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

kent.christianson wrote:
> 
> So now I have a different question.  I have (all along) computed all the
> vertices and put them in a big, global array ("road[ ][ ][ ]") so that they
> never have to be recomputed.  What is the best way to use these to get
> efficient computation?  Is there a better way than this:
> 

glDrawArrays()

-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.