EXT_vertex_buffer
by Alberto Ganesh Barbati · in Torque Game Engine · 06/14/2006 (5:17 pm) · 7 replies
Hi Everybody,
this is odd. TGE goes a long way to support an extension called EXT_vertex_buffer. All the interior and terrain rendering code have specific code paths to leverage such extension. However... Google could not find any reference about EXT_vertex_buffer! None of my two Radeons support it and neither does my collegue's GeForce Fx. I'm puzzled... looks like some legacy from the past... Just wondering, is there at least one video card supporting that extension in 2006?
Maybe it's not too difficult to rewrite EXT_vertex_buffer code to use ARB_vertex_buffer_object, which is much more widely implemented. That may give a tremendous performance boost and looks like it's worth the effort. I'll put in my TODO list ;)
Alberto
this is odd. TGE goes a long way to support an extension called EXT_vertex_buffer. All the interior and terrain rendering code have specific code paths to leverage such extension. However... Google could not find any reference about EXT_vertex_buffer! None of my two Radeons support it and neither does my collegue's GeForce Fx. I'm puzzled... looks like some legacy from the past... Just wondering, is there at least one video card supporting that extension in 2006?
Maybe it's not too difficult to rewrite EXT_vertex_buffer code to use ARB_vertex_buffer_object, which is much more widely implemented. That may give a tremendous performance boost and looks like it's worth the effort. I'll put in my TODO list ;)
Alberto
#2
Thanks Alex.
06/15/2006 (12:52 am)
Quote:Ah! The D3D renderer. I was forgetting about it. That makes sense, actually.
EXT_vertex_buffer is a crazy Torque specific extension that I think is mainly used to make the D3D renderer faster.
Quote:I see. I haven't seen the details of how EXT_vertex_buffer is used in the engine, but according to what you say I can lower the priority of this task. But it stays on the list ;)
Implementing ARB_vertex_buffer_object in the way that EXT_vertex_buffer is implemented wouldn't net much of an FPS boost. EXT_vertex_buffer is set up as a GL_STREAM_DRAW_ARB, when the fastest method that actually gets major FPS boosts is GL_STATIC_DRAW_ARB, or at the very least GL_DYNAMIC_DRAW_ARB where the data is reused for a couple of frames. It does make a handy project though, and does give a nice performance boost.
Thanks Alex.
#3
Re-writing the places that use EXT_vertex_buffer to use a real vertex buffer would gain you some performance, however because the engine is not set up to do any kind of state-switch reduction or batching, it's kind of a losing battle. Torque is the way it is so that the maximum number of people can meet the system requirements for an indy game. You are kind of cutting out that benifit to do this optimization, and TSE would probably serve better.
In any case: I would not recomend undertaking any rendering optimizations until you are at the appropriate place in your games development. It's always good to think about it, but optimization like this really is something you should start worrying about 70 or 80% of the way through the game.
06/15/2006 (10:11 am)
Don't give EXT_vertex_buffer any thought. I have mucked around in that DLL more than any mortal ever should, and it is a scary place.Re-writing the places that use EXT_vertex_buffer to use a real vertex buffer would gain you some performance, however because the engine is not set up to do any kind of state-switch reduction or batching, it's kind of a losing battle. Torque is the way it is so that the maximum number of people can meet the system requirements for an indy game. You are kind of cutting out that benifit to do this optimization, and TSE would probably serve better.
In any case: I would not recomend undertaking any rendering optimizations until you are at the appropriate place in your games development. It's always good to think about it, but optimization like this really is something you should start worrying about 70 or 80% of the way through the game.
#4
The hardest thing is in figuring out how to change things without having to break TGE around. I got a lot of experience while working in a few prototypes recently, so I think the time has came for my to try optimizing the goddamned TSStatics.
06/18/2006 (8:27 am)
I'm slowly building up a scheme for adding render state batching to TS-based classes. I have most of it planned, I just need to sit down and implement it someday.The hardest thing is in figuring out how to change things without having to break TGE around. I got a lot of experience while working in a few prototypes recently, so I think the time has came for my to try optimizing the goddamned TSStatics.
#5
I'm targeting OGL 1.4, for broad compatibility, but if it isn't too complicated to build in support for VBO's (at least for TSStatics) I would support that as well.
It's not crucial yet, though, so I'll just take Pat's advice and shelf it for now.
-David
06/18/2006 (10:17 am)
Good information. I had been pondering the same thing lately (OGL vertex buffers in TGE).I'm targeting OGL 1.4, for broad compatibility, but if it isn't too complicated to build in support for VBO's (at least for TSStatics) I would support that as well.
It's not crucial yet, though, so I'll just take Pat's advice and shelf it for now.
-David
#6
06/18/2006 (10:42 pm)
I completely ripped the EXT_vertex_buffer path out of my code base to help reduce code size and fewer if statements to evaluate. Another part of my reasoning was that I have integrated GLSL support, so there is no chance of D3D emulation without specific D3D shader ports. :)
#7
I had started another thread in the public area to gather info about what version of OpenGL to target. You might find it interesting and I will appreciate hearing your comments. For the time being, I decided to require at least 1.3, allowing me to remove all single-texturing code paths and a few others. Moreover, I could finally remove the ugly const_cast in dglLoadMatrix/dglMultMatrix, because 1.3 supports glLoadTransposeMatrixARB and glMultTransposeMatrixARB. It won't be a big performance boost, but I like clean code ;)
06/19/2006 (10:14 am)
@Jeff: Yep, that's exacty what I just did ;)I had started another thread in the public area to gather info about what version of OpenGL to target. You might find it interesting and I will appreciate hearing your comments. For the time being, I decided to require at least 1.3, allowing me to remove all single-texturing code paths and a few others. Moreover, I could finally remove the ugly const_cast in dglLoadMatrix/dglMultMatrix, because 1.3 supports glLoadTransposeMatrixARB and glMultTransposeMatrixARB. It won't be a big performance boost, but I like clean code ;)
Associate Alex Scarborough
Implementing ARB_vertex_buffer_object in the way that EXT_vertex_buffer is implemented wouldn't net much of an FPS boost. EXT_vertex_buffer is set up as a GL_STREAM_DRAW_ARB, when the fastest method that actually gets major FPS boosts is GL_STATIC_DRAW_ARB, or at the very least GL_DYNAMIC_DRAW_ARB where the data is reused for a couple of frames. It does make a handy project though, and does give a nice performance boost.