Using Vertex Buffers
by Stephane Conde · in Torque Game Engine · 06/22/2006 (11:42 am) · 10 replies
Hello,
I am curious about using Vertex Buffers to render TSShapeInstances. I have searched the forums and have come up empty.
I found the function 'fillVB' in the tsShapeInstance.cc file which looks like it fills vertex buffers. The function however is never used. Can this function actually be used for performance gains in TGE... or am I barking up the wrong tree?
If 'fillVB' is the right path to be following, does anyone have any experience in getting TSShapeInstances to use Vertex Buffers for rendering? And if so, would they be willing to share any information that might be helpful in getting me started?
With my very limited knowledge of the OpenGL rendering pipeline, it looks like I would need to include a call to 'fillVB' perhaps in the TSShapeInstance::render if dglDoesSupportVertexBuffer() returns true. Then, in the TSMesh::render function use the mVertexBuffer that was created earlier? I don't know... As you can see... I am probably way off the mark and very lost... any help that anyone could provide would be greatly appreciated!
Thanks in advance,
Stephane
Edited because I'm an idiot who cannot spell... :(
I am curious about using Vertex Buffers to render TSShapeInstances. I have searched the forums and have come up empty.
I found the function 'fillVB' in the tsShapeInstance.cc file which looks like it fills vertex buffers. The function however is never used. Can this function actually be used for performance gains in TGE... or am I barking up the wrong tree?
If 'fillVB' is the right path to be following, does anyone have any experience in getting TSShapeInstances to use Vertex Buffers for rendering? And if so, would they be willing to share any information that might be helpful in getting me started?
With my very limited knowledge of the OpenGL rendering pipeline, it looks like I would need to include a call to 'fillVB' perhaps in the TSShapeInstance::render if dglDoesSupportVertexBuffer() returns true. Then, in the TSMesh::render function use the mVertexBuffer that was created earlier? I don't know... As you can see... I am probably way off the mark and very lost... any help that anyone could provide would be greatly appreciated!
Thanks in advance,
Stephane
Edited because I'm an idiot who cannot spell... :(
About the author
Recent Threads
#2
The reason is that Torque was written before real vertex buffers existed in OpenGL. It took a while for there to be an ARB extention that all vendors supported. Now that this exists, it is possible to use the 'ARB_vertex_buffer_object' extention and get real support for vertex buffers in Torque. However, in doing this, it significantly decreases the "works out of the box" aspect of Torque, as this was only introduced in OpenGL 1.4 (If I remember right). It will be somewhat of an undertaking to do this. There will be benifits, which will include, most likely, a significant speedup in rendering of TS objects, because video hardware can only take advantage of the vertex cache, hardware T&L and such if you are using indexed vertex buffers to draw objects. Again, though, making these changes could take a lot of work and head-scratching.
I don't mean to discourage you from doing this, I just wanted to provide you with the information that I have. Also, TSE is designed, from the ground up, with everything rendering using vertex buffers, as well classes that make using these structures easy. Raw API calls are, quite frequently, not at all as easy or maintainable as you would expect them to be.
I hope that answers your question.
06/22/2006 (12:16 pm)
DglDoesSupportVertexBuffer returns false because the "OpenGL" extention that Torque uses for vertex buffers is not actually a real extention. It is an entry in the opengl2d3d.dll and if you are using Torque in D3D mode, it will return true, and use it.The reason is that Torque was written before real vertex buffers existed in OpenGL. It took a while for there to be an ARB extention that all vendors supported. Now that this exists, it is possible to use the 'ARB_vertex_buffer_object' extention and get real support for vertex buffers in Torque. However, in doing this, it significantly decreases the "works out of the box" aspect of Torque, as this was only introduced in OpenGL 1.4 (If I remember right). It will be somewhat of an undertaking to do this. There will be benifits, which will include, most likely, a significant speedup in rendering of TS objects, because video hardware can only take advantage of the vertex cache, hardware T&L and such if you are using indexed vertex buffers to draw objects. Again, though, making these changes could take a lot of work and head-scratching.
I don't mean to discourage you from doing this, I just wanted to provide you with the information that I have. Also, TSE is designed, from the ground up, with everything rendering using vertex buffers, as well classes that make using these structures easy. Raw API calls are, quite frequently, not at all as easy or maintainable as you would expect them to be.
I hope that answers your question.
#3
Not entirely true. Everything after (and including) the TNT/Radeon 7200 and Intel 845 chipset have support for the ARB_vertex_buffer_object extension. Besides, it's relatively easy to provide fallbacks to cards that do not support VBOs. Side note, ARB_vertex_buffer_object was moved to core in OpenGL 1.5.
Also not entirely true. Indexed vertex arrays can use the vertex cache and hardware T&L just fine (Torque uses indexed vertex arrays for almost all rendering).
What VBOs do is provide better geometry memory management. At the very least, using a VBO will eliminate the data copy from the application to the driver, and on newer cards also eliminate copying the data into an internal VBO for rendering. VBOs are extremely useful for static objects (such as interiors) because they allow you to upload vertex data to the driver once and use it for the duration of the game. Currently, Torque must resend all vertex data to the driver every frame for every object, regardless of whether or not its static.
Again though, TSE is designed around using VBOs, and the OpenGL port will presumably exclusively use VBOs. Unless you have a very good understanding of the Torque rendering pipeline and know all the ins and outs of using VBOs, rewriting Torque to use VBOs will be a long and painful process filled with many explosions of randomly drawn triangles.
06/22/2006 (1:04 pm)
Quote:However, in doing this, it significantly decreases the "works out of the box" aspect of Torque
Not entirely true. Everything after (and including) the TNT/Radeon 7200 and Intel 845 chipset have support for the ARB_vertex_buffer_object extension. Besides, it's relatively easy to provide fallbacks to cards that do not support VBOs. Side note, ARB_vertex_buffer_object was moved to core in OpenGL 1.5.
Quote:video hardware can only take advantage of the vertex cache, hardware T&L and such if you are using indexed vertex buffers to draw objects
Also not entirely true. Indexed vertex arrays can use the vertex cache and hardware T&L just fine (Torque uses indexed vertex arrays for almost all rendering).
What VBOs do is provide better geometry memory management. At the very least, using a VBO will eliminate the data copy from the application to the driver, and on newer cards also eliminate copying the data into an internal VBO for rendering. VBOs are extremely useful for static objects (such as interiors) because they allow you to upload vertex data to the driver once and use it for the duration of the game. Currently, Torque must resend all vertex data to the driver every frame for every object, regardless of whether or not its static.
Again though, TSE is designed around using VBOs, and the OpenGL port will presumably exclusively use VBOs. Unless you have a very good understanding of the Torque rendering pipeline and know all the ins and outs of using VBOs, rewriting Torque to use VBOs will be a long and painful process filled with many explosions of randomly drawn triangles.
#4
It's not that we as a company disagree with the concept of vertex buffers--TSE rendering changes and optimizations utilize them extensively. It's that to force a move within the TGE product line that changes our core target platform generation spectrum is a hefty decision, and not made lightly.
06/22/2006 (1:06 pm)
OpenGL 1.5 isn't implemented on, for example, Windows98 computers with Voodoo3 cards--which Torque supports out of the box (theoretically!).It's not that we as a company disagree with the concept of vertex buffers--TSE rendering changes and optimizations utilize them extensively. It's that to force a move within the TGE product line that changes our core target platform generation spectrum is a hefty decision, and not made lightly.
#5
However, something I want to stress: It does not matter if OpenGL 1.5 is implemented. At all. Non issue. Completely irrelevant. What is important is that the ARB_vertex_buffer_object extension is supported. This is a very important distinction. OpenGL 1.5 isn't supported on ATi cards until the Radeon 9500, however the Radeon 7200 can use VBOs.
Using VBOs isn't a good move for Torque in general, but it might be a good move for your specific project. For example, TTR is pushing too much data to run on a Radeon. In fact, if it weren't for liberal use of static VBOs and batching, it wouldn't run on a GeForce 7800. Therefore, VBOs were a very good move for us. On the other hand, your project might be running well within the limits of what a VooDoo 3 can handle, in which case VBOs would be more or less pointless.
06/22/2006 (1:19 pm)
Hmm, forgot to mention that the VooDoo series of cards is out. Among others. Just download this and you can tell what cards support which extensions so you can determine the best approach for your target market.However, something I want to stress: It does not matter if OpenGL 1.5 is implemented. At all. Non issue. Completely irrelevant. What is important is that the ARB_vertex_buffer_object extension is supported. This is a very important distinction. OpenGL 1.5 isn't supported on ATi cards until the Radeon 9500, however the Radeon 7200 can use VBOs.
Using VBOs isn't a good move for Torque in general, but it might be a good move for your specific project. For example, TTR is pushing too much data to run on a Radeon. In fact, if it weren't for liberal use of static VBOs and batching, it wouldn't run on a GeForce 7800. Therefore, VBOs were a very good move for us. On the other hand, your project might be running well within the limits of what a VooDoo 3 can handle, in which case VBOs would be more or less pointless.
#6
What I meant by the compatibility issue wasn't so much that they *couldn't* do it, but that they needed driver updates. When I think of TGE, I think of things that you want to keep at maximum compatibility without users needing to update anything or download anything since the casual games market kind of caters to that demographic.
So very true. I love the randomly drawn triangles. The only thing they are second to is, "The object is there...why doesn't it render!?" and then you do some crazy camera movement and realize that there's a moving dot somewhere, and that's probably the object rendering way the hell out near infinity or something.
06/22/2006 (2:04 pm)
Indexed arrays can still use the vertex cache even though they have to be re-uploaded each frame? Wild. I assumed they didn't.What I meant by the compatibility issue wasn't so much that they *couldn't* do it, but that they needed driver updates. When I think of TGE, I think of things that you want to keep at maximum compatibility without users needing to update anything or download anything since the casual games market kind of caters to that demographic.
Quote::)
rewriting Torque to use VBOs will be a long and painful process filled with many explosions of randomly drawn triangles.
So very true. I love the randomly drawn triangles. The only thing they are second to is, "The object is there...why doesn't it render!?" and then you do some crazy camera movement and realize that there's a moving dot somewhere, and that's probably the object rendering way the hell out near infinity or something.
#7
@Alex: I was never particularily considering implementing VBOs from scratch (a long, messy and drawn-out rewrite of the TGE rendering engine is the last thing our project needs). I was more just curious about what existed in TGE 'out-of-the-box'. You have definitely answered that question though.
@Pat & Stephen: Thank you for the information. As always, Garagegames comes through... :)
The main reason that this issue came up is that we've done a whole bunch of profiling and optimizing and now TSShapeInstance rendering is taking up a huge chunk of our rendering time. We have virtually no interiors in our game... which means we've got a whole whack of static meshes. Anything that I can do to get the rendering time of static meshes down will directly impact frame-rate.
If anyone perhaps has any ideas on any easier methods of trying to get static meshes to render faster please let me know!
Thanks again guys!
Stephane
06/23/2006 (12:29 pm)
Thank you all very much for your very informative replys.@Alex: I was never particularily considering implementing VBOs from scratch (a long, messy and drawn-out rewrite of the TGE rendering engine is the last thing our project needs). I was more just curious about what existed in TGE 'out-of-the-box'. You have definitely answered that question though.
@Pat & Stephen: Thank you for the information. As always, Garagegames comes through... :)
The main reason that this issue came up is that we've done a whole bunch of profiling and optimizing and now TSShapeInstance rendering is taking up a huge chunk of our rendering time. We have virtually no interiors in our game... which means we've got a whole whack of static meshes. Anything that I can do to get the rendering time of static meshes down will directly impact frame-rate.
If anyone perhaps has any ideas on any easier methods of trying to get static meshes to render faster please let me know!
Thanks again guys!
Stephane
#8
06/23/2006 (12:50 pm)
www.garagegames.com/mg/forums/result.thread.php?qt=46023 - bit of discussion about rendering static meshes
#9
Before you get knee deep in what could some lengthy coding and optimizing, consider how much the static shape rendering is taking up in the total processing time : e.g. if it's taking 90% of your rendering time, but only 15% of your total processing time, you might just be able to live with that, and might be better off looking at other parts of the code first to churn out cycles where you need them...
06/23/2006 (1:07 pm)
Stephane, how much of your total processing time is rendering as a whole taking ?Before you get knee deep in what could some lengthy coding and optimizing, consider how much the static shape rendering is taking up in the total processing time : e.g. if it's taking 90% of your rendering time, but only 15% of your total processing time, you might just be able to live with that, and might be better off looking at other parts of the code first to churn out cycles where you need them...
#10
@Alex: Our models are actually quite good. Any objects that are in our scene more than 3 or 4 times have LODs and the meshes themselves are quite low-poly to begin with... its just that we have quite a few of them...
Setting TSMesh::smUseOneStrip to true doesn't really affect much... I had tried that one earlier. I haven't tried messing with properties of our lights but we don't have all that many lights in the level (no more than 20 and no more than 5 or 6 visible at any one time) so I can't imagine that is causing much of a slowdown
Adding a visibility slider is not really an option as visibility is integral to gameplay... We've also already got a ton of fog.
@Nicolas: The static shape rendering is taking up approximately 50% of the total rendering time and is taking up approximately 35% of total processing time (total rendering time is about 67% of total processing time). I assume those numbers are on-par with other Torque projects, but if there's any way to improve them, I'd like to find it... :)
Again, thanks a bunch for the help. It looks like implementing static VBOs might be my only option at this point and I just don't think we can afford the time it would take to implement that. Sadly, this might have to be a case of 'living with it'... :(
06/23/2006 (2:47 pm)
Thanks again for the tips!@Alex: Our models are actually quite good. Any objects that are in our scene more than 3 or 4 times have LODs and the meshes themselves are quite low-poly to begin with... its just that we have quite a few of them...
Setting TSMesh::smUseOneStrip to true doesn't really affect much... I had tried that one earlier. I haven't tried messing with properties of our lights but we don't have all that many lights in the level (no more than 20 and no more than 5 or 6 visible at any one time) so I can't imagine that is causing much of a slowdown
Adding a visibility slider is not really an option as visibility is integral to gameplay... We've also already got a ton of fog.
@Nicolas: The static shape rendering is taking up approximately 50% of the total rendering time and is taking up approximately 35% of total processing time (total rendering time is about 67% of total processing time). I assume those numbers are on-par with other Torque projects, but if there's any way to improve them, I'd like to find it... :)
Again, thanks a bunch for the help. It looks like implementing static VBOs might be my only option at this point and I just don't think we can afford the time it would take to implement that. Sadly, this might have to be a case of 'living with it'... :(
Torque 3D Owner Stephane Conde
Hmm... upon further inspection it looks like some of this existing Vertex Buffer stuff might be used by the renderMeshesX function. But this function never gets called because dglDoesSupportVertexBuffer() seems to always return false.
Thanks again for any help you might be able to provide!
Stephane