VBO Compabilty

Hey,

I’m currently developing a small 3D engine for use in a game targed at all ages and all machine specs.

I’m considering using VBO (Vertex Buffer Objects) to render my vertice data because of the incresed performance but I’m worried about the support of VBO with old graphic cards…

My question is simply in what generation of cards can i consider support of VBO as standard?

Out current goal of minimum graphic card is a Nvidia TNT - generation card…

VBO is a driver-side feature, it should be available with any recent Nvidia or Ati drivers.

Okay great thanks, I wasen’t untirely sure about it being driver side feature purly…

you should write a render path that doesnt use VBOs anyways.

Oh, why is that? Any benefits?

Some of the functionality in the game the ability to selectAPI, so I do have support for D3D as well, and therefor it’s quite a logical solution to use buffers(since I use a Vertex Buffer in DX)…

But you got a better idea?

Originally posted by JoCCo:
Oh, why is that? Any benefits?

correct me if im wrong but any card without T&L wont benefit from VBO’s ( i wouldnt think DX VB’s would benefit either ) since VRAM resident vertex data would have to travel to the CPU for transformation and then back again, doubling the AGP traffic.

the only gain I can think of for non T&L cards is the driver can preformat the data if its not already in a hardware native format.

mtm

From what I can remember TNT2 was the first gfx card with a primtive version of T&L support, and GeForce 1 was the first to really go by the standards…

But I’m not sure how much the gain will be, I figured I’d try it out…

Go for VBO. On the TNT-Series, VBOs are implemented as vertex arrays. But remember that the fastest way to draw static geometry are still (at least on “good” drivers like ATI’s or Nvidia’s) display lists. If you do dynamic gemotry, then go for VBOs.

Support for VBOs isn’t necessarily hardware support. It may be that the data is stored in local memory, but manipulated with VBO functions. As such, a lack of Hardware T&L support is not a problem.

Still, while NVidia supports VBO in drivers for the TNT2, ATI cards only from the Radeon 7200 and on support it. Older cards must use standard OpenGL vertex arrays.

My own implementation of VBOs as well as the rest of OpenGL is wrapped up in a class. Within this I have an automatic fallback that uses standard vertex arrays. Using my wrapper class, only a single path will have to be written for VBO-capable cards and cards that don’t support the extension.

It sounds like a good idea to use a wraper and fallback on VertexArrays, but right now I have more importent things to fix, if my designers force me to support the old ATI cards (that arn’t as common today as old Nvidia cards) I’ll use your idea…

You should have a non-VBO path not because it has any technical benefits (it doesn’t), but because there’s a very large installed base of cards out there that doesn’t support VBO (e.g. Intel’s integrated chipsets). The people that own these cards are also unlikely to update their drivers very often, by the way. If you want to target “all machine specs” as you said, you simply have no choice.

– Tom

Okay okay, you got me, I’ll put it down on my TODO list…

And to be really honest a non VBO path isn’t that much work…

Thanks Everyone you’ve helped alot, and I’m grateful for all the fast replies…

Well, for initial programming it’s fine to just have a single render path or very few fallbacks. Once everything’s working, however, it’s generally a good idea to ensure more backward compatability.

My own implementation of a fallback was simply so I could work on my engine during some long breaks (three hours on Thursdays) I had between classes in the fall semester. The computers here are decent, in terms of CPU power, but integrated Intel video just isn’t all that hot. . .

Originally posted by tweakoz:
correct me if im wrong but any card without T&L wont benefit from VBO’s ( i wouldnt think DX VB’s would benefit either ) since VRAM resident vertex data would have to travel to the CPU for transformation and then back again, doubling the AGP traffic.

forgot to mention, you dont want to combine VBO’s and software Vertex Programs.

mtm