Jump to content

  • Log In with Google      Sign In   
  • Create Account

Adding/Removing from VBO at runtime


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
10 replies to this topic

#1 Spck   Members   -  Reputation: 105

Like
0Likes
Like

Posted 29 December 2012 - 04:23 AM

I'm new to Modern OpenGL and have been following a handful of tutorials online. I'd appreciate some clarification on a few things so my head doesn't explode. None of the tutorials speak of adding/removing data from VBOs once the buffer has already been filled. I could really use some assistance.

 

 

So let's say I have 2 objects, each with vertex data loaded into a single VBO as

 

[x, y, z, w,

 r, g, b, a,

 x, y, z, w,

 etc]

 

What's the best practice to adding another object to the VBO? Copy the original VBO into a larger array, add the new vertex data, then bind the larger array as the VBO?

 

Also, how would I go about removing objects (all of their vertex data)? Destroy the VBO and create a new one? (Removing particular parts of the VBO is beyond me.)

 

As you can tell, I don't quite have a grasp on the concept. If someone could point me in the right direction I'd very much appreciate it.



Sponsor:

#2 Brother Bob   Moderators   -  Reputation: 8631

Like
0Likes
Like

Posted 29 December 2012 - 04:40 AM

It seems like you're talking about whole objects, so why not keep the objects in their own buffer objects instead of all of them sharing one big buffer object? Then you don't have to manage one big buffer, but just manage many smaller ones so the other objects aren't affected when you add or remove other objects.



#3 Spck   Members   -  Reputation: 105

Like
0Likes
Like

Posted 29 December 2012 - 04:46 AM

I was originally thinking just that, but I'm making a simple 2D game and only using textured quads. Everything I've been reading has basically stated it's considerably more efficient to stick them into one VBO instead of many.

 

Also, I feel like I'm missing something important here. If I have 2 objects, both exact copies except for position, is there a simpler way to render them besides passing the data twice?



#4 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 29 December 2012 - 04:51 AM

If I have 2 objects, both exact copies except for position, is there a simpler way to render them besides passing the data twice?

You can pass a translation matrix as a uniform variable to a shader and render one object twice with different matrices.



#5 Spck   Members   -  Reputation: 105

Like
0Likes
Like

Posted 29 December 2012 - 04:59 AM

If I have 2 objects, both exact copies except for position, is there a simpler way to render them besides passing the data twice?

 

You can pass a translation matrix as a uniform variable to a shader and render one object twice with different matrices.

 

Just to clarify, since I'm horribly new to graphics programming. Hypothetically, if I wanted 10,000 2D right triangles all with the same texture coordinates, I would only need 1 set of data in the VBO? (edit)

 

Could you explain how this would differ if I had multiple different shapes/textures? 

2 2D shapes + same texture = 2 sets of data?

2 2D shapes + 2 textures = 4 sets of data?

3 2D shapes + 2 textures = 6 sets of data?

 

Really having a tough time wrapping my head around, thanks for the help.


Edited by Spck, 29 December 2012 - 05:02 AM.


#6 Brother Bob   Moderators   -  Reputation: 8631

Like
1Likes
Like

Posted 29 December 2012 - 05:27 AM

If by "object" you mean just a single quad, then you may prefer a single buffer object. I would definitely not create and recreate the buffer object, but try to manage the memory within it instead.

 

For example, make a buffer object large enough to hold all objects, or at least quite a few of them, and then fill it with as many objects as you need to begin with. After that, just add more objects to the end, or remove objects either by shifting the buffer or by swapping in the last object to the deleted position. if you add more objects than can be stored in the buffer object, then create a new, larger buffer, copy everything to it, and continue using the larger one instead. By memory mapping the buffer object, you get "direct access" to it as if it was a regular pointer and memory buffer and you can manipulate your buffer's memory as you like.

 

You could also use different buffer objects for sprites with different usage patterns. For example, a buffer object for static sprites that doesn't change, a buffer object for sprites that change but are always there, and a buffer object for dynamic sprites that are created and deleted in the fly.



#7 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 29 December 2012 - 10:46 AM

Just to clarify, since I'm horribly new to graphics programming. Hypothetically, if I wanted 10,000 2D right triangles all with the same texture coordinates, I would only need 1 set of data in the VBO? (edit)

 

Until you don't need to update the geometry of one single triangle, you don't need 10.000 VBOs to store them (JFI: you can take advantage of glDrawElementsInstanced()).

 

Could you explain how this would differ if I had multiple different shapes/textures? 

2 2D shapes + same texture = 2 sets of data?

2 2D shapes + 2 textures = 4 sets of data?

3 2D shapes + 2 textures = 6 sets of data?

 

not sure what you mean under the `data set' here:

in the first (1) variant you can bind texture once for use with both shapes

in the second variant I think you want to have two shapes with their own textures? in this case you would bind texture object 1 + render vbo 1, than bind texture object 2 + render vbo 2

in the third variant I am not sure what you want to achieve, but you certainly can do as in (1)



#8 Spck   Members   -  Reputation: 105

Like
0Likes
Like

Posted 29 December 2012 - 02:06 PM

Thanks, everything's more clear now. I've been looking around and haven't been able to find any examples of managing the memory inside the VBO. Does anyone know any source I could look at to get a better understanding of the subject?

 

EDIT - I feel like I should explain what I'm trying to do. I'm making a simple 2D game. There might be maybe 100 quads on screen at one time, and there will only be one large texture made of mutliple .pngs. If I wanted to add a game object at run time, I'd need to add a rendering component containing the vertex data (position and texture coords).

 

Would it be best to just add/delete each game object as a new VBO? Or should I used the memory managament method Bob described with a single VBO?

 

 

I'm attempting to write code that code be the basis for further development, so I'm trying not to use any bad practices. This is purely for education purposes as I find programming, and specifically graphics programming to be incredibly fascinating.


Edited by Spck, 29 December 2012 - 02:19 PM.


#9 santa01   Members   -  Reputation: 307

Like
0Likes
Like

Posted 29 December 2012 - 04:55 PM

I've been looking around and haven't been able to find any examples of managing the memory inside the VBO.

 

glBufferSubData() to update the contents of VBO

glBufferData() to reallocate and init VBO

 

If you already have some knowledge open opengl you can look through the opengl wiki:

http://www.opengl.org/wiki/Buffer_Object

http://www.opengl.org/wiki/VBO#Vertex_Buffer_Object

 

Would it be best to just add/delete each game object as a new VBO? Or should I used the memory managament method Bob described with a single VBO?

 

Its up to you, try both options, pick what fits your needs best.

 

This is purely for education purposes as I find programming, and specifically graphics programming to be incredibly fascinating.

 

Then _definitely_ try both options :) Early optimization isn't vital, moreover its usually harmful. Make a working prototype first.



#10 Spck   Members   -  Reputation: 105

Like
0Likes
Like

Posted 29 December 2012 - 05:05 PM

I really appreciate your advice, thanks!



#11 mhagain   Crossbones+   -  Reputation: 8285

Like
2Likes
Like

Posted 02 January 2013 - 06:01 AM

Then _definitely_ try both options smile.png Early optimization isn't vital, moreover its usually harmful. Make a working prototype first.

 

I'd disagree with your "early optimization" comment here - getting buffer object updates correct is not "early optimization" - it's a fundamental requirement.


It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS