6
\$\begingroup\$

I find I'm a bit confused about the practical use of resource management in combination with memory not tied to the CPU. Correct resource management is often recommended in game tutorials, books and on websites to ensure the same heavy data is not loaded in memory more than once, but cached and passed out whenever needed. This seems to be a valid idea and I've built a couple of resource management classes more than once.

Resource caches work perfectly for, say, level data or audio files, but my understanding always comes crashing down as soon as we're talking about memory residing on the GPU (vbo's, textures). It would seem to me that a mesh resource class should have to store nothing more than a vbo index, yet every mesh class I look at (e.g. Ogre3D) manually stores vertex lists in mesh classes. I can't seem to grasp why that is done. What's the use of vbo's if you're storing the mesh data in your usual memory anyway?

This question is not about how vbo's work (I understand them conceptually), but more about how they're practically applied in game development.

Could someone please elaborate?

|improve this question
\$\endgroup\$
  • \$\begingroup\$ I don't know anything in particular about Ogre or what it does with those resources, so I'm guessing here...but keeping your vertex data in host memory allows you unload it from device memory when you need to, and put it back there again, without having to reload the model from disk to host memory \$\endgroup\$ – user13213 Dec 23 '12 at 12:58
7
\$\begingroup\$

Basically, it's not easy to get the vertex data back from the video card once it's there. Keeping the vertex data available to the CPU allows for a number of things, here are a few:

  • As melak47 suggests, it allows the developer to free up video memory by freeing a VBO, while being able to quickly replace the data without needing to read from disk again.
  • It allows for vertices to be added or removed. Dynamic meshes may have vertices that need to be added or removed. For example, a chunk of dynamic terrain that needs to have the effects of an explosion applied to it.
  • It allows for modification of positions or other attributes. This could be applying a formula/algorithm to alter the position, texture, color or other attribute of some or all of the vertices. Perhaps an object that morphs between different shapes.
  • These buffers can also be used just for the initial creation of the VBO. You need somewhere to store your vertices as you build them up. These buffers could easily be used to store them, then you know the size of the data to send to the graphics card. And they could be cleared after if you no longer have need of them.
  • It also allows you to create render paths without VBOs (although these aren't as necessary today as they used to be), and if you lose context for some reason (like alt-tabbing) re-creating the VBOs is easier.

All in all, having the vertex data close to the CPU allows the developer more options for what to do with the data. It makes more sense than automatically discarding the data, and leaves the choice up to the developer.

|improve this answer
\$\endgroup\$
  • 1
    \$\begingroup\$ It also allows you to create render paths without VBOs (although these aren't as necessary today as they used to be), and if you lose context for some reason (like alt-tabbing) re-creating the VBOs is easier. \$\endgroup\$ – Jari Komppa Dec 23 '12 at 17:52
  • \$\begingroup\$ In addition to the above, keeping a copy of the vertex data on the CPU side also allows a game engine to re-create VBOs automatically if it needs to recreate the OpenGL context for some reason (during a resize event, etc). \$\endgroup\$ – Trevor Powell Dec 23 '12 at 21:15
  • \$\begingroup\$ Thanks Jari, I added your suggestion. Trevor, I think you're saying the same thing as the second part of Jari's comment. \$\endgroup\$ – MichaelHouse♦ Dec 23 '12 at 21:21
  • \$\begingroup\$ @Byte56: Thanks for your answer, You cleared this up a lot for me! So for clarification purposes: the data basically resides in memory twice, then (on the gpu, and in main ram). Does this also hold for static meshes, or are these commonly just thrown away and reloaded when necessary? \$\endgroup\$ – Stijn Frishert Dec 24 '12 at 11:40
  • \$\begingroup\$ Yes, they're in memory twice. Though typically the form stored on the CPU side is in a bit different of a format, so it's easier to manipulate. Static meshes can also be kept in memory twice. It would be for some of the other reasons listed, like context switching. \$\endgroup\$ – MichaelHouse♦ Dec 24 '12 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.