2
\$\begingroup\$

Okay, so I have a bunch of cubes in a 3d-world. I already implemented face culling, so that when a cube is next to another cube, their touching faces won't be drawn, or even sent to the buffer. However, a while back when I was still researching how to make a 3d block-based game, I came across a stack overflow question where the asker posted an image of their cubes, which had not only been culled but they had also merged the faces of adjacent cubes into larger rectangular faces. Like this: combining faces

My question is, should I do this? Will the drawing time be saved enough to justify the longer update time? And if so, I'm not even sure if it would work some of the time. The cubes aren't textured, they're coloured, so I'm not entirely sure if it would work with multiple colours of cubes.

\$\endgroup\$
  • 2
    \$\begingroup\$ If the two cubes have different textures or colours, they need to be separate. If they are the same, I guess they could be merged together. You would save time in the vertex shader by doing this, but none in the pixel/fragment shader. As long as they are still grouped together in the same draw call, I don't think the difference will be that much. I could be wrong, though. \$\endgroup\$ – Ben Oct 14 '14 at 10:59
  • \$\begingroup\$ Oh, well in that case... I'm using a pixel shader. Thanks for the info! \$\endgroup\$ – Mackenzie McClane Oct 14 '14 at 11:01
  • \$\begingroup\$ it requires some extra effort with ensuring the textures are sampled correctly as well \$\endgroup\$ – ratchet freak Oct 14 '14 at 11:09
4
\$\begingroup\$

There are many different variables that come into play regarding this. If two faces are next to each other that use different textures, light levels, colors, etc.. you more than likely won't be able to join them together anyhow (nearly anything's possible with enough work, but it'd probably be FAR too much work).

If, however, you have a lot of cube faces with the same textures, light levels, and colors, it's totally possible and could make a huge difference in your performance.

My engine, which may be completely different than yours, keeps all like faces segregated into different arrays. By this, I mean for a chunk (32x128x32), all visible faces that are on the tops of all the cubes are in their own array and the same for the north faces, the west faces, the bottom faces, etc. With this, I can easily cull entire chunks from being passed to the render stage or I can simply skip sending all west faces from a chunk that the player is east of.

With that in mind and understanding that joining neighboring cube faces requires nearly identical data on each of them, if you set up a good way to keep your arrays sorted and "walk" over the array properly, it's completely possible to improve performance. Whether or not you want to go through all the work to find out is up to you though.

I don't think anyone can actually answer the question of SHOULD you do this except you. Without knowing how you store your data, how often you have situations that even let you join faces, etc.. I don't think anyone can truly answer.

If you want to look into it though, I'd suggest going the shader route described here. That's the way I'd suggest doing the actual joining. To join them, however, I suggest the way I describe in this post at the end. It's easy, while not 100% optimal, it is quite fast.

|improve this answer|||||
\$\endgroup\$

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.