6
\$\begingroup\$

I'm working on an experimental app to test how VBOs perform when rendering a minecraft-like world. If the performance is better than what I use now I'll update my actual game. Based on what everyone says, VBOs should totally be the right direction, but it's really hard making that become a reality.

I've finally gotten to a point where I've replicated culling block faces, I'm properly using the buffer IDs to render and not building the VBO every frame - there's no a ton of performance tweaking left aside from:

  • Using an indexed system so I can send fewer vertices
  • Using a ByteBuffer for my color/texture values instead of floats (I need to find a good way, right now everything is interleaved)
  • I could take block face culling a little further because in the test app, they don't check across chunks for solid blocks.

My primary issue is that for some reason, when I render 15x16 chunks (16x16x16 blocks per chunk in my test app) the performance and rendering is great. Movement is fluid, 60fps.

At 16x16 chunks, performance drops to like 5fps. I've run profiling like VisualVM and see no unusual differences in the speeds/memory of the code between the two states. It's odd how the addition of one extra row of chunks can take performance down so much - there must be some specific threshold I cross.

How can I better debug what's happening? Where should I be looking? There are no console errors.

This test app is open source so you can look at the code:

World Chunk Rendering

Update I've updated my actual game with the VBO work I've been doing in this test app and the performance of the 10x10 grid of chunks (16x16x128) was so horrid that my system took minutes to allow me to kill the app. I'll certainly spend some time adjusting things and making sure that it's performance-tuned for my app, but wow - still not seeing how VBOs are all they're cracked up to be.

\$\endgroup\$
2
  • \$\begingroup\$ are you using VBO per chunk? or per block? \$\endgroup\$
    – concept3d
    Dec 9, 2013 at 9:09
  • \$\begingroup\$ The buffer is per chunk \$\endgroup\$
    – BotskoNet
    Dec 9, 2013 at 17:16

1 Answer 1

1
\$\begingroup\$

For the actual problem (slow rendering of VBO), you might try to use instancing. That only helps if you have hundreds or thousands of objects to render.

You can debug the problem several ways. AMD Perfstudio and Nvidia Nsight are tools for getting debug data from the GPU. You could use those to try to find out the problem.

Another way to debug the problem is to measure the time each operation takes. Timing a certain operation looks like this:

glFinish(); // Make sure there is no work queued in the GPU
double timeBefore = getCurrentTime(); // milliseconds
theGlDrawCallOrBufferUpdateEtc(); // the GL function you want to measure
glFinish(); // Finish that
double timeAfter = getCurrentTime();

double timeTheFunctionTook = timeAfter - timeBefore;

This might give you a hint of which GL calls are causing the lag. You can use the same thing to measure any other parts of the code too. if there are no GL calls, just drop the glFinish() calls as they are not required then.

\$\endgroup\$
1
  • \$\begingroup\$ I looked into instancing quite a but but people advised that it's not useful when each block only has certain faces visible. \$\endgroup\$
    – BotskoNet
    Dec 11, 2013 at 16:01

You must log in to answer this question.

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