0
\$\begingroup\$

I'm currently working on a Minecraft clone for a university project and I'm having some trouble loading a lot of chunks at the same time without reducing performances.
What I'm currently doing is:

  1. Creating the VAO
  2. Creating the VBOs
  3. Buffering the data in the VBOs
  4. Rendering them (that isn't causing any lag)
  5. Destroying the VAO and VBOs when the chunk is no longer needed

I tried to look at other solved questions but they were too specific or too vague, or maybe I'm just dumb.
The chunks are made of 16x16x16 blocks and its VBOs contain only the vertices of the visible blocks (like Minecraft's doing).
I'm looking for a better way(in terms of speed and performance) to load them.

\$\endgroup\$
4
  • \$\begingroup\$ What profiling have you done so far? Where do the results suggest your program is spending most of its time during these performance slowdowns? \$\endgroup\$
    – DMGregory ♦
    Commented Mar 2, 2020 at 17:09
  • \$\begingroup\$ If I preload some chunks I don't have any lag, instead if I load new chunks on runtime the fps drop \$\endgroup\$
    – Tito Tigi
    Commented Mar 3, 2020 at 9:19
  • \$\begingroup\$ Right, but which specific step in the loading process is sinking.most of your time? The more specifically you can identify the source of the problem, the better we can target solutions. You might have more that can be improved than just the pooling the current answer suggests, but we won't be able to advise on it without seeing your profiling results and the troublesome code. \$\endgroup\$
    – DMGregory ♦
    Commented Mar 3, 2020 at 12:16
  • \$\begingroup\$ I will do some more profiling then. Thank you for your time \$\endgroup\$
    – Tito Tigi
    Commented Mar 3, 2020 at 15:05

1 Answer 1

Reset to default
2
\$\begingroup\$

Destroying the VAO and VBOs when the chunk is no longer needed.

This is the main thing that you're doing wrong, and it implies that you're also creating resources at runtime. Creating and destroying resources at runtime is a slow operation and something you should try to do as little of as possible.

Instead you should keep a pool of free VBOs/etc, and rather than destroying objects that aren't needed, just return them to the free pool. When you need new objects, check the free pool first before creating new ones.

Yes, this means that there will be times when you have objects in your free pool that aren't being actively used, and it's tempting to think of this as "wasting memory", but it's not - try to think of it instead as implementing a fast allocator by keeping these objects ready for reuse if needed.

\$\endgroup\$
3
  • \$\begingroup\$ Thank you! I will try implementing a pool then \$\endgroup\$
    – Tito Tigi
    Commented Mar 3, 2020 at 9:16
  • \$\begingroup\$ One more question, using glBufferData is fine or there is a faster/better way? \$\endgroup\$
    – Tito Tigi
    Commented Mar 3, 2020 at 12:36
  • \$\begingroup\$ @TitoTigo - that's probably a good topic for a separate question, although maybe try searching the site first as it probably already has an answer. Generally though, glBufferData should be fine but use glBufferSubData if the buffer size hasn't changed. But either way you don't want to be doing too many of these per frame, so it really depends on the frequency at which you update buffers. This is the kind of thing that, if you get wrong, client-side arrays or even glBegin/glEnd might be faster, but there is no one-size-fits-all right answer. \$\endgroup\$
    – Maximus Minimus
    Commented Mar 3, 2020 at 18:06

You must log in to answer this question.

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