CODEWITHSUNDEEP
openglvbo
rlkw1024
rlkw1024

Reputation: 6525

Dealing with dead objects in OpenGL VBOs

Imagine a typical game where objects in the simulated world are created and destroyed. When these objects are created, their vertex data is stored in a VBO. This VBO is rendered once per frame.

Is there a best practice for dealing with dead objects? I.e. when the object is destroyed and thus no longer needs to be rendered, what should happen to its corresponding VBO data?

It seems like you'd want to "free" that memory up for future use by other objects. Otherwise, your VBO would eventually be filled almost entirely with dead data.

I have one possible idea for implementing this: a map of VBO memory wherein individual bytes are marked as free or in use. (This map would live on the CPU as a normal array, not on the GPU.) When an object is created, we buffer its data to a free region as determined by the map. We mark that region as used on the map. Then when the object is destroyed, we mark that same region as free. I'm thinking you would store the map either as an array of booleans if you're lazy, or pack it in as one map bit per VBO byte if you want to do it right.

So far, does this sound like the best approach? Is there a more common approach that I'm not seeing?

I know a lot of these questions hinge on the characteristics of the scene you're rendering, so here's the context. My scene consists of several hundred objects. Each object has about eight vertices. Each vertex has a position and texture coordinate stored as floats. So, we're looking at approximately:

4 bytes per float * 6 floats per vert * 8 verts per object * 500 objects
= 96,000 bytes of vertex data

Upvotes: 2

Views: 523

Answers (1)

Ben Voigt
Ben Voigt

Reputation: 283893

Sounds like you're thinking of using a pool allocator. There's a lot of existing work done on those, which should apply quite well to allocations inside a VBO also.

It will be pretty straightforward if all elements are the same size. Otherwise, you need to be concerned about fragmentation, but heap managers are quite well known.

The simplest improvement I would offer is to start your scan for a free slot from the last slot filled, instead of always from the beginning.

You can trade space for speed by using a deque-style data structure to store a list of free locations, which eliminates the need to scan for a free spot.

The size of the data stored in the VBO really has no impact on the manager. Only the number of slots which can be invididually repurposed.

Upvotes: 3

Related Questions