Jump to content
  • Advertisement
Sign in to follow this  
Alkhimey

OpenGL VBO Questions

This topic is 2782 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently I have learned about VBO. I decided to change an a application I have (simple model viewer with some features) to support this.

After reading some material I have still some questions that I do not understand.

1.1. Will VBO code work with all graphic cards? Will it work with onboard graphics?
1.2. If my graphics memory is not sufficient, I know that I will get a opengl error, but what should I do next? What is the best practice for such situation?

2. After I do glBufferData can I delete the original array?
Vertex* array = (Vertex*)malloc(sizeof(Vertex)*24)
glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex) * 24, array, GL_STATIC_DRAW);
delete[] array;

3. A model consists of several objects. Is it possible to have a separate VBO for each object, or all data should be stored in a single VBO?

4. Is it possible to define color for whole object instead for each vertex?
I though about mixing with immediate mode (calling glColor* before drawing the buffer) but I am not sure this is supported.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Alkhimey
1.1. Will VBO code work with all graphic cards? Will it work with onboard graphics?


VBO is supposed to be the replacement of IM, so any new GPU from the last few years should support it. But you can always fall back to VA or IM...(check if VBO is supported, else try VA; VA = VertexArray).

Quote:
Original post by Alkhimey
1.2. If my graphics memory is not sufficient, I know that I will get a opengl error, but what should I do next? What is the best practice for such situation?


Have less textures or a smaller buffer. If the memory is full, you simply use too much...

Quote:
Original post by Alkhimey
2. After I do glBufferData can I delete the original array?
Vertex* array = (Vertex*)malloc(sizeof(Vertex)*24)
glBufferData(GL_ARRAY_BUFFER, sizeof(Vertex) * 24, array, GL_STATIC_DRAW);
delete[] array;


The buffer is sent to the GPU, and used multiple times. So yes, build the array, send it to the GPU, and then discard the array on RAM. But for later modifications, a RAM array might be handy to keep.

Original post by Alkhimey
3. A model consists of several objects. Is it possible to have a separate VBO for each object, or all data should be stored in a single VBO?

As less as possible VBO's. But per texture you need an VBO. So stack as much as you can in one texture.

Quote:
Original post by Alkhimey
4. Is it possible to define color for whole object instead for each vertex?
I though about mixing with immediate mode (calling glColor* before drawing the buffer) but I am not sure this is supported.


No, do everything through the VBO, that's how IM does it itself too. That's the most efficient (not memory wise surely).

Share this post


Link to post
Share on other sites
1.1a No. Some graphics cards are too old. I'd suggest not supporting them...
1.1b Should do, if the onboard is new enough.

1.2 Use less memory. Erm. I dunno. Depends on your application really.

2. Yes.

3. I dunno. It depends what you're planning on doing with them I guess. I'd probably put them all in the same buffer. In fact, if you have a bunch of objects I'd put all of ALL of them in the same buffer. Why? Because you can then use instancing and batching and stuff rather than having to keep binding new buffers.

4. Yes. Just do that. Yes. It does work. Or you could pass it in as a uniform to your shader code.

Share this post


Link to post
Share on other sites
"But per texture you need an VBO"

You can stack up textures in the multitexture system and have a vertex attribute to pick which one is used in the lookup. Works a treat.

Share this post


Link to post
Share on other sites
2) You could even go further and never store anything in your RAM, only driver selected storage, by calling glBufferData(...) and using NULL on buffer data pointer. This way you ask your driver to reserve enough memory for your VBO, and then you can petition it through a DMA call by using glMap(...).

Share this post


Link to post
Share on other sites
Quote:
Original post by Katie
"But per texture you need an VBO"

You can stack up textures in the multitexture system and have a vertex attribute to pick which one is used in the lookup. Works a treat.


Have you got an example / article about this?

EDIT: Oh, that is only for 8 textures...I cannot use such a limitation unfortunately...

Share this post


Link to post
Share on other sites
You need GL 1.5 at least. That's when VBO became core. That was 9 years ago.
Some old drivers have GL 1.3 (really old ATI cards) or GL 1.4 (really old Intel) but they advertise GL_ARB_vertex_buffer_object

It's up to you what you support.

Share this post


Link to post
Share on other sites
Quote:
Original post by Katie
Why? Because you can then use instancing and batching and stuff rather than having to keep binding new buffers.

Can you explain this? What is instancing and batching?


Thnak you.


Share this post


Link to post
Share on other sites
Graphics memory is not that important. Textures nowadays take up so little space if you use compression. Even without compression, you should be just fine if your getting started.

Share this post


Link to post
Share on other sites
The Intel 910/915 is the only part you'll find in reasonably common usage these days that may not support VBOs. It's up to you whether or not you want to support it.

Client-side vertex arrays are probably the most sensible fallback in cases where VBOs are not available, and can be coded with a minimum of changes or upset to your VBO code.

You can use the glColor functions in conjection with VBOs just fine, and it works well. Just be certain that you don't also set a glColorPointer if you do.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!