My game is played on a fixed-size hex based arena, where each hex can be of a different type, and possibly contain some creatures/items/anything on it.
When I started out, I got the advice to have a VBO per entity, which I took quite literally and ended up creating a VBO per-hex per-frame, which got real slow. This lead me to restructure the data in a way that I pre-calculate all of the VBO data for the "background" hex grid just once, and just repeatedly draw it.
The problem is that now I can't simply rely on changing the model and having everything be updated, as the whole "map" is pre-calculated. Following this I created a separate VBO which is filled just with "dynamic" objects that change on each frame, and first render the static background, and then the dynamic part that changes.
But this leads me to a question. What if I need to change the background at runtime? For example, what if a "wall" gets torn down every once in a while, and I need to update the world data? Currently I can think of only a few options:
- Change the VBO in place during the frame. This would only work if the change is small enough to not lag the frame.
- Keep a separate VBO that just has the "changes" and is drawn over the original one. I don't really like this approach, as it doesn't really feel flexible.
- Build a new VBO in a separate thread and atomically swap them once done. While this would allow me to do a larger update without sacrificing framerate, it could also introduce a weird kind of latency, when the user would still see the old thing for a few frames until the new VBO is calculated.
Ideally I'd just change my "model" and re-build the whole VBO from it, but that's about as slow as it gets, so I'm not really sure if I should even keep thinking this way?
How do larger and more complicated games handle updating geometry on the fly? Is everything just pre-calculated animations that simply get swapped around?
glBufferSubData
to update the tiles that changed. \$\endgroup\$