VBO Q

Ok I’m working on a new demo that does a few different cool effects using quake 3 bsp files as the way the world geometry is rendered. Well that part is fine and runs pretty fast, but I just added VBO (which I havn’t even thought about in quite a while) and for some reason I did not get any speedup. I have another demo that renders a highly tesselated sphere and I get a 2x framerate jump as I expected when it was written. But with my latest demo the framerate is exactly the same. What exactly does this mean? I’m not using any shaders just yet either. Everything is being rendered with a single texture only right now.

Each time my “emit” function gets called (this is where glDrawRangeElements gets called) is where I setup the pointers to the vertex and tex coord data as it changes many times each frame. I thought by calling glVertexPointer right before I render liks this would be causing the problem but I don’t think so because there are many 3d apps that render this way.

Just for reference here is my main render function if anyone is interested.

void CRender::Emit( void ) 
{
glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_vboObjectID );
glBufferDataARB( GL_ARRAY_BUFFER_ARB, sizeof( float ) * 4 * m_input.num_verts, m_input.pos, GL_STREAM_DRAW_ARB );

glBindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, m_vboIndexObjectID );
glBufferDataARB( GL_ELEMENT_ARRAY_BUFFER_ARB, sizeof( unsigned int ) * m_input.num_elems, m_input.elems, GL_STREAM_DRAW_ARB );

glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_vboTexID );
glBufferDataARB( GL_ARRAY_BUFFER_ARB, sizeof( float ) * 2 * m_input.num_verts, m_input.st, GL_STREAM_DRAW_ARB );

glBindTexture( GL_TEXTURE_2D, m_pTextureArray[m_iCurrTexture] );
glEnable( GL_TEXTURE_2D );

glEnableClientState( GL_INDEX_ARRAY );

glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_vboTexID );
glTexCoordPointer( 2, GL_FLOAT, 0, BUFFER_OFFSET( 0 ) );

glBindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, m_vboIndexObjectID );
glIndexPointer( GL_UNSIGNED_INT, 0, BUFFER_OFFSET( 0 ) );

glBindBufferARB( GL_ARRAY_BUFFER_ARB, m_vboObjectID );
glVertexPointer( 3, GL_FLOAT, sizeof( float ) * 4, BUFFER_OFFSET( 0 ) );

glDrawRangeElements( GL_TRIANGLES, 0, m_input.num_elems - 1, m_input.num_elems, GL_UNSIGNED_INT, BUFFER_OFFSET( 0 ) );
		
glBindBufferARB( GL_ARRAY_BUFFER_ARB, NULL );
glBindBufferARB( GL_ELEMENT_ARRAY_BUFFER_ARB, NULL );


glDisableClientState( GL_INDEX_ARRAY );
glDisable( GL_TEXTURE_2D );

m_input.num_elems = 0;
m_input.num_verts = 0;
}

It’s either not going to give me a speed up in this particular case or I’m just doing something dumb. Which the latter is the most likely. :smiley:

BTW, my map I’m using has less than 5000 polys and every poly is always visible. I’m using PVS but my map isnt complex enough to really benefit from it. :slight_smile:

Thanks.
-SirKnight

Each time my “emit” function gets called (this is where glDrawRangeElements gets called) is where I setup the pointers to the vertex and tex coord data as it changes many times each frame.
Hmmm, making changes many times each frame maybe the problem. AFAIK, Quake3 map data are stored in large global arrays. If you’re rendering the map itself, as opposed to characters, you should be able to arrange things such that only a single bind to the data is necessary to render the entiure map. IIRC, all the map primitives are pre-striped/fanned with indices, so this should be fairly staightforward.

I have another demo that renders a highly tesselated sphere and I get a 2x framerate jump as I expected when it was written. But with my latest demo the framerate is exactly the same. What exactly does this mean?

Not sure what you expect with 5000 tris. Your program goes at the framerate defined by your slowest bottleneck. If your bottleneck is the fillrate but you help the bandwidth’s one (by using VBO), you will still be limited by your fillrate, and see exactly 0% performance improvement.

Y.

Use unsigned short indices if you can!
Move your gl…Pointer calls up, saves three glBindBuffer calls. But keep the the glBindBufferARB(GL_ARRAY_BUFFER_ARB, 0);, it’s good for asynchronous rendering.
Try if using the array element buffer is necessary.
Reduce the window size to see if you were geometry bound.

Not sure what you expect with 5000 tris. Your program goes at the framerate defined by your slowest bottleneck. If your bottleneck is the fillrate but you help the bandwidth’s one (by using VBO), you will still be limited by your fillrate, and see exactly 0% performance improvement.

Yeah I know it’s not much geometry, but what I was expecting was at least a little improvement in speed. Of course it’s already fast as it is now. :smiley: I don’t see how it can be fillrate problems because I’m rendering at 800x600 and only applying one texture per face. I’m not using any shaders or anything like that. And there’s only 6 textures in my scene. Perhaps with this low of a geometry count VBO won’t make much if any of a difference? I’ve only done VBO stuff with very high poly counts before and it did work good there.

BTW, I’m running a GeForce FX 5600U.

Ok so I guess I will have to arrange my data so I don’t have to call those gl…Pointer calls that many times. I kind of figured I would. :wink: This means a rewrite of my renderer. O well, all in good fun.

-SirKnight

I don’t see how it can be fillrate problems because I’m rendering at 800x600 and only applying one texture per face. I’m not using any shaders or anything like that. And there’s only 6 textures in my scene.
You can very easily be fill rate limited at any resolution (eg : 4 * 3), with any number of active textures (eg : 0).

Let’s do some math bench marks. We will render n quad fullscreen in different resolutions, with different settings yielding to different fragment operations. Our formula is :
Workload = ResoX * ResoY * FragOps * n

  1. 1024768, 1 texture + 1 color = 2 ops, n = 1
    WL = 1024
    76821 = 1 572 864

  2. 320240, 1 color = 1 op, n = 20
    WL = 320
    2401*20 = 1 536 000

If your geometry has 20 overlapping triangles, you’ll get the same workload on this part of the screen with 2) and 1).

Note that with ZBuffer activated, sorting front to back helps a lot with this. The problem described here is the main bottleneck in shadow volumes that yields to a huge amount of overlapping fragments.

In your particular case, rendering 5000 triangles in a single VBO calls is extremely fast. So you are obviously fill rate limited. You are comparing “before”, and “after with VBOs”, but you didn’t specify what kind of method you used. Note that display lists implementation is extremly efficient nowadays, and that vertex array makes good use of TnL caches, that are common on nowaday hardware.

SeskaPeel.

Ok yeah that was pretty obvious but I didn’t see it for some reason. I now realize that it IS a fillrate problem so thanks for all the input. I think I was so bent on thinking it was a VBO problem that I assumed it couldn’t be anything else. And that’s where I went wrong. :smiley:

Alright so now I MUST do something about this because the point of my demo will use some shaders and things that are going to eat fill like crazy. Namely shadow volumes, dot3 bumpmapping w/ parallax and high dynamic range. It should come out to be a pretty cool demo that I think many will like. Plus the source will be available so I’m bound to make someones day I hope. :slight_smile: Luckily though all these things I mentioned that will be in the demo I’ve done many times before (excluding the HDR but it’s easy) so that will be good.

-SirKnight

You’re not convincing anyone, y’know knight.
You’ve just grasped what fill rate is…today. Yet you expect us to believe you’re capable of producing a demo that people will actually be grateful for.
Dream on son.
Feel free to delete this post dorbie…as usual.

Ok dude, what is your problem with me? This is getting real old. I don’t want to be enemies with anyone so how can we resolve this?

I did not just grasp what fillrate is. I was just assuming that was not the problem and VBO was the culprit. It was a mistake of assuming like that yes, but now that I realize that the VBO stuff is ok I can perfectly see it’s fillrate and I know exactly what to do to fix it. It was one of those things that was staring me in the face but I did not see it. Don’t tell me that you never make that mistake. It may not seem like it from my post but I know a hell of a lot more than you think buddy.

So please, lets stop this and act civilized here ok?

-SirKnight

My problem is that I don’t like bullshtters. There’s way too many of them around these days, and they get far more success than they deserve.
You have proved time and time again that you are a bullsh
tter.
The only way we can ‘resolve’ this is for you to stop bullsh*tting in public.

Sorry, pals, but Direct3D much more powerful than OpenGL (especially v 9.0). All what you doing with OpenGL is useless. You`re just pure wasting your time.