So far, I’ve been working with lots of meshes that are all of the same size. I can store them all in a single VBO, maintain a length and capacity, and if I want to remove a given mesh I can “swap remove”, where I copy the last mesh over the one being removed, and then reduce the length.
I can’t do this if my meshes have all different numbers of triangles though (even if they’re the “same” object, different LODs will have different numbers of triangles!). And using a separate VBO for every mesh is godawfully slow because of all the rebinding.
How often do you need to remove these meshes? If it isnt too often or you dont have too many meshes then simply rebuild the entire VBO from ground up.
Uploading a few kb of data isnt that slow nowadays.
[QUOTE=Cornix;1262140]How often do you need to remove these meshes? If it isnt too often or you dont have too many meshes then simply rebuild the entire VBO from ground up.
Uploading a few kb of data isnt that slow nowadays.[/QUOTE]
Several times a second isn’t unrealistic - Minecraft’s creative mode certainly does that. And if I’m using my VRAM to its full capacity, it could be tons of MBs of triangles!
I feel like there’s some way to use texture buffers, but I’m not sure how unless I can tell GLSL about all the buffers up-front.
Edit: I guess I could reserve one “arena” VBO up-front for all the triangles I’ll possibly ever store, and then keep another VBO that contains indices and sizes of the individual meshes.
Edit 2: Oh that would make “allocating” from “deleted” space annoying.
Edit 3: I guess it’s not the end of the world to just do what I’m doing, and let meshes get “broken up” by swap removes. All the triangles of a mesh don’t need to be stored contiguously for rendering to work. I can have a data structure in regular RAM that keeps track of where the “pieces” of the mesh are located in VRAM.
How about you just try it and see how the performance is before making assumptions. You could even try different approaches and pick the one with the most promising results.
Well I know uploading all my meshes to VRAM takes a human-noticeable chunk of time at program startup (I had to implement staggered loading, and I’m nowhere near full VRAM usage), so doing that every time something is removed is out of the question. As for the performance of re-binding, I was originally set up with a different VBO for everything, and it was incredibly slow. And it’s fairly well-documented that that’s expected.
Using an “arena” approach would be fast enough, but managing memory is just a large and tricky amount of work. I’m okay with “breaking up” the meshes though, as I said in my post above, so that should be fairly workable and performant. I’ll post back if it isn’t.