I am unable to wrap my mind around designing a good way to manage resources in my game. For instance, a vertex buffer in DirectX or OpenGL would lead me to believe I should have one central buffer in which I would adapt to my game. But how would I efficiently manage this? If I had 2 game objects which used the same model but with different properties such as color or position, I would I assume reading from the same section of memory for geometry and having them each passing there own properties to the vertex/pixel shader. But what boggles me is having them read from the same section of the vertex buffer and having the vertex buffer manage the streaming of new data.

Textures and sound surface the same problem to me.


2 Answers 2


You need some raw data models. For example let's consider that you've made a model in blender of a sphere, let's call this sphere_model.

On of your game classes is represented by a brown coloured sphere, the other one is represented by a blue sphere.

You first initialize the brown sphere, the asset manager checks it's cache and sees that the sphere_model hasn't been loaded yet, it loads it for you and returns a pointer to a model primitive to the brown sphere.

The primitive type has a vertex buffer assoctiated and should have some methods to make it actual.

You then initialize the blue sphere, the asset manager sees that the sphere_model has already been loaded and directy returns a pointer to the model primitive.

When drawing the brown sphere, you do something like SetVertexBuffer(my_model_primitive); after that you set the shader options (like colour = brown).

When drawing the blue sphere you do again SetVertexBuffer(my_model_primitive) which sets the same vertex buffer, however by setting different shader options, (like colour, texture, WorldMatrix, etc..) the sphere will look different.

In general proper asset management will need to statisfy the following:

  • Content primitives are only loaded once (model files, texture files, sound files)
  • Content primitives are mapped to a primitive class, like model_primitive, texture2d, soundEffect, etc...)
  • Primitive classes only retain the raw data, and methods to do something with this data, like actualizing the vertex buffer, but don't contain state.
  • Higher level classes contain the state and use the primitive classes. They can contain (visual) state like scale, tinting, etc..

I hope this makes a bit of sense, feel free to ask more questions!

  • \$\begingroup\$ So I should have for example a vector or list of "vertex buffer handles" that tells me which model is in what ever part of the vertex buffer so if I needed to draw a specific object, I would go through the vector and get the vertex buffer handle. The handle its self would have the position and size within the vertex buffer. Also how would I manage the dynamic loading and unloading of meshes? I am dealing specifically with openGL and C++. \$\endgroup\$
    – Wunkolo
    Jun 2, 2011 at 20:09

You store per-instance data in a vertex buffer too. You read from one section of GPU memory for the per-model data like the vertices and stuff, and then you read from a different section of GPU memory to determine the per-instance data.

The general rule is, you should only be sending commands to the GPU, not data- except when your data changes, of course.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .