Jump to content
  • Advertisement
Sign in to follow this  
BladeWise

VertexArray and VBOs: beginner questions

This topic is 4741 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

I'm looking at VertexArrays and VBOs since a week, so my experience with this kind of structers is quite poor... I have some question about them... About vertexArrays: 1. Using VertexArrays, every frame should I use gl**Pointer for each object in my scene, with both dynamic and static geometry? (I suppose yes... like using glBegin/glEnd) 2. If I'm rendering static geometry, is it possible to avoid gl**Pointer call, using instead a sort of binding (like VBOs), or this makes no sense, since data should be sent anyway to the graphic card? About VBOs: 1. Using them for dynamic data, what's the *best* (if exist!) way to change data? Reconstructing the VBO? Mapping the VBO? As an example, if I suppose to render a man running, every frame I should change vertices and normals (colors and texture coords should be the same, am I right?), what should I do every frame? 2. Using them for a game engine, when should be the right moment to build VBOs? And what about destroying them? Since every VBO is stored on server side (in graphic card memory), I suppose there is a limit on howmay (and how big) these data should be... I suppose that I should create the VBO only when an object becomes visible in the frustum... but... is it a good idea to destroy it if it's not visible anymore? 3. Is it possible to use glInterleavedArrays with VBOs? Where could I find an example about it? Thnx for reading this post... and sorry if some questions are too *newbie* ^^

Share this post


Link to post
Share on other sites
Advertisement
I'll see if I have time to ansewr your questions in-depth later, but for now you may want to read through This Thread, as we've been dicussing several things that you ask about.

Share this post


Link to post
Share on other sites
Thnx Toji, I read the post, before posting mine, but since it's more than "VertexArrays and VBOs for dummies" I decided to make this one, with my "maybe-too-dummy" questions! :D
Anyway I found many informations very interesting and useful... without that post my question could be doubled! :D

Share this post


Link to post
Share on other sites
concerning Vertex Arrays:

1) You need to use gl*Pointer each frame as your vertex data isn't stored anywhere...it gets sent to the card, the data is rendered and the card forgets about the data entirely.
2) Yes, for static geometry use VBOs whenever possible. It avoids the overhead of sending data to the card over the bus.

concerning VBOs:

1) You should map the VBO. Creating and destroying VBOs is an expensive process.
2) This is not really an OpenGL question. Because of the reasons given above, you should try and maximize the lifetime of a given VBO. This falls more into the realm of 'portals' which break up your world into discrete chunks for rendering. You should not use the view frustum as an indicator of when to destroy a VBO. Consider for example a FPS game where the player is looking around like mad, you would be constantly creating/destroying VBOs - bad news.
3) Yes. Interleaved arrays work the same with VBOs as they do with Vertex Arrays.

Share this post


Link to post
Share on other sites
Disclaimer: As Casper the Friendly Moderator can tell you, I am no expert on VA/VBO use. In fact I know little more than the basics and how to get them up and running. That being said, take the following with a big ol' grain of salt. It is very much possible that I have something wrong, though I have answered to the best of my knowledge (corrections are very welcome, guys).

Quote:
Original post by BladeWise
1. Using VertexArrays, every frame should I use gl**Pointer for each object in my scene, with both dynamic and static geometry? (I suppose yes... like using glBegin/glEnd)


The way I understand it, and someone can back me up on this, is you're essentially binding the a pointer to the data the VA/VBO will use to draw the object using gl*pointer. If you're only using a single VA/VBO, you should just be able to bind the pointer once and re-draw as many times as you'd like. However chances are you will want to draw multiple meshes, so you'll want to set the gl*pointers each time you draw. And even if you're only going to draw a single model, you should probably make the call to gl*pointer anyway, just to be safe. I doubt it costs much to do so, and it'll save you headaches later.

If your question is if you have to rebind the pointers if the data changes, the answer is no, as you're working with pointers to the objects anyway. However you will need to rebind before each draw anyway, so it's a moot point.

Quote:

2. If I'm rendering static geometry, is it possible to avoid gl**Pointer call, using instead a sort of binding (like VBOs), or this makes no sense, since data should be sent anyway to the graphic card?


Whether or not the data changes, you'll still want to bind the data pointers before you draw anyway. If you're using VBOs, you'll be making calls to both your VBO binding function and the gl*pointer functions. I don't think there's a way to circumvent the gl*pointer call.

Quote:

About VBOs:
1. Using them for dynamic data, what's the *best* (if exist!) way to change data? Reconstructing the VBO? Mapping the VBO? As an example, if I suppose to render a man running, every frame I should change vertices and normals (colors and texture coords should be the same, am I right?), what should I do every frame?


If you actually morph the geometry, the texture coordinates will not stay the same. If you do keep them the same, the texture will bind to the old shape of the mesh, which will look weird.

I'm not sure if you have to recreate the VBO or not. If you're modifying the data, it would stand to reason that it would either have to be resent to the graphics card or that the card drivers will modify the data stored in VRAM, but I just don't know.

Quote:

2. Using them for a game engine, when should be the right moment to build VBOs?
And what about destroying them? Since every VBO is stored on server side (in graphic card memory), I suppose there is a limit on howmay (and how big) these data should be... I suppose that I should create the VBO only when an object becomes visible in the frustum... but... is it a good idea to destroy it if it's not visible anymore?


Well, with VBOs you're working with video memory, which is (or at least used to be) limited compared to main system RAM. You should employ some criteria for whether or not a VBO persists, but I'd say it depends on the application. For example, if you're building a space sim and you have hundreds of ships flying around, you probably just want to create one VBO for each type of ship and just draw from that each time. That way, your maximum number of VBOs in VRAM is governed by how many different types of ships there are (which can't be that many).

Quote:

Thnx for reading this post... and sorry if some questions are too *newbie* ^^


Bah, save your appologies. These are exactly the types of questions that should be asked here, in exactly the way they should be asked. It looks like you've done your homework, read up on VAs and VBOs, and now you're just looking for clarification. Keep it up, that's a great way to learn. The only thing anyone could fault you for, was not perusing the first page or two of the OpenGL forum and not seeing the thread Toji pointed out, but that is quite forgivable (maybe you just missed it, maybe you read it and it didn't quite answer your questions, whatever). These forums have their share of problems, and this thread is certainly not one of them. You asked your question in an intelligent manner, and anyone reading it and the responses will have gained or reinforced their own personal knowledge. Keep it up!

Share this post


Link to post
Share on other sites
Quote:
Original post by Aeluned
concerning VBOs:

1) You should map the VBO. Creating and destroying VBOs is an expensive process.


Not strickly true [smile]

Mapping isnt a great option, it does have uses for example taking source data, adjusting it in someway and writing it directly to the VBO, this allows you to remove an extra buffer when compared to glSubBufferData() style updating, however mapping is by no means the quickest way todo things.

To perform a map on an VBO with data in the driver would have todo something like the following;
- postentially check the VBO isnt in use, if it is wait until its free
- potentially copy back into system ram
- provide you with a pointer to the new system ram
and on unmap;
- copy that new buffer back into faster ram (AGP or VRAM)

Instead if might be quicker to replace the whole buffer and this can be performed async with drawing commands with no stalls. The method is to call glBufferData() on the VBO specifying 'NULL' or 0 as the address to read from, this tells the driver "I'm done with the data in this VBO, discard it when you've finished with it", you can then call glBufferData() or I belive glSubBufferData also works to upload your new data to the driver, which will sort everything out behind the scenes.

This is the prefered and recommended method for updating VBOs from both NV and ATI.

Share this post


Link to post
Share on other sites
Many thanks, these answers were all that I was looking for, moreover I just realized something important: the space ship game example made me think about the way I was developing my engine... I was going to do a bad mistake, since I was confusing meshes, with game objects... in this way, 200 ships with the same model required 200 meshes... so 200 VertexArrays... it's quite awful indeed! :D Time to code now! :P

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!