Frame rate varying with VBO

Hi,
I’m doing some frame rate tests on a human’s mesh model. The mesh consists of 300 triangles that use one texture (256x256).
To reduce the number of computations, I precalculate the deformation of the mesh or “pose” for 10 keyframes of
a walk animation and store each pose in a vertex buffer object (i’ll call them VBO_0 to VBO_9 for clarity) using GL_STATIC_DRAW_ARB.
When rendering the virtual human, every 0.1seconds (1 second animation/10 keyframes), I render the corresponding
vbo pose.

When I tried rendering 1000 humans, i was getting frame rates varying from 65 to 125 fps.
If I only create 1 VBO, and render the same VBO each time, then I get a consistent 125fps. If i disabled texture mapping,
i got a consistent 150fps. On further analysis I noticed that if I still created the 10s VBOs but rendered the same VBO each time(instead of changing which VBO
I render every 0.1sec), I got the following fps:
125fps for VBO_0 and VBO1,
85fps for VBO_2 and VBO_3,
65fps for VBO_4,
85fps for VBO_5,
65fps for VBO_6,
85fps for VBO_7,
125fps for VBO_8 and VBO_9

Can anyone explain to me why each VBO doesnt take the amount of time to render even though each VBO contains the same amount of data. Why does the framerate vary depending on how many VBOs I create? And why is the framerate consistent if I disable texture mapping. I really would appreciate any comments, as its really staring to bug me!

I’m using an Radeon X850 PE with a Pentium IV 3.0GHz with 2GB RAM.

Thanks,
Simon

Perhaps you’re fillrate bound? The different poses might cover a different number of pixels on average, leading to varying framerate.

When you turn of texture mapping rasterization becomes cheaper and you become transform bound.

/A.B.

Thanks brinck for getting back so quickly. I dont think thats the case as I did the same tests with 10 and 100 humans and the frame rate still varies.

Originally posted by Simon Dobbyn:
Thanks brinck for getting back so quickly. I dont think thats the case as I did the same tests with 10 and 100 humans and the frame rate still varies.
I don’t think this contradicts my theory. Since an application can’t go inifinetly fast you’re always limited by either:

1. Fillrate
2. Transform rate
3. CPU

In your case I think we can safely rule out the CPU and with fewer models it’s actually more probable that you’re fillrate bound.

I stick to my original theory, try and move the models outside the view frustum so that they aren’t rasterized. If you get a higher, non varying, frame rate you’re fillrate bound.

/A.B.