# vertices, better to have more but draw a smaller area or less but expand a larger area

I have a simple question really. I am creating water for a game and had two different design approaches:

1. Make a single plane that expands the entire playspace, which would take 6 vertices but cover a much larger area. The idea being the plane would be at a certain height so the sourrong land if higher should cover it.

2. Check at regular intervals around the created land, ask if the height of that peice of land is below a certain height if so, draw a small square to cover the area and then check the next interval and the next... The idea being you'd have a lot more vertices but much less area will be drawn.

Any help would be appreciated as to which design approach makes more sense.

• Fewer vertices is better. Though I'm not really sure what you're describing.
– House
Apr 30 '13 at 11:21
• Essentially I have a landscape and am trying to add "water" to it. The idea being if a part of the landscape is lower than a preset height, water should be created to cover that area. I am wondering if it's better to just use one large plane to draw the water and let the depth culling ensure the water can't be seen through the landscape or if it's better to draw multiple small squares at all areas that need water. Apr 30 '13 at 12:09

That's really not that important. Computers nowadays are fast, more important is not to use a "dumb" approach.

When I first started programming in OpenGL (for Android, OpenGL 1.0) I made a Minecraft-like game, but instead of using VBOs or moving to OpenGL ES 2.0 I sent all vertex data, every frame to the GPU. You can imagine how slow it was. I was getting about 3-4 FPS on a 32x32x16 world. Then I implemented octree frustum culling which improved nothing. But I did learn a lot from that.
Logic of the program is much more important than some micro-optimisations in the code that only gets executed once.

About two years later I know better and program OpenGL for a hobby and it is very fun.

• It's good that you're sharing your experience, but try to answer the question too.
– House
Apr 30 '13 at 14:59
• Well, the first sentence was kind of meant to be the answer. Thanks for the feedback though, I will do better next time. Apr 30 '13 at 15:05
• True enough, that's a reasonable enough answer.
– House
Apr 30 '13 at 15:09

As long as you do not require the vertices for animation and you don't want to have caves or other holes below sea level you should probably use your first approach:

1. If you render the water after your land geometry all fragments not visible will get depth culled which is very efficient.
2. The water geometry is clipped before shading the fragments which means only visible fragments will get shaded.
3. You have only one draw call. 2 would require to batch the patches or combine them into one buffer.

You'll be fine with the first approach. Just don't make them too far away or you'll run the risk of having some odd graphical glitches due to floating point imprecision happening.

Making a big square that covers the entire game world is a fine approach unless you run into some problem with it. There are a couple of potential problems you should remain aware of that could make it better to tessellate the water a bit more:

• If the game world is very large, the water vertices will be very far away from the camera. It's possible to run into floating-point precision problems where the water plane would appear to be unstable and "vibrate" as the camera moves around. Tessellating the water plane more would alleviate this, since it would add vertices closer to the camera.

• If the water has an expensive pixel shader, you might end up paying the performance cost of it even when it's underground (because it's still being drawn). Removing water from underground areas would help this. However, you can also fix this by doing a depth pre-pass, or simply by drawing the ground before you draw the water. Then the GPU's hierarchical Z culling should eliminate the underground water pixels quite efficiently.

So, if you don't have such a large game world that floating-point precision becomes problematic, and you make sure to draw the ground before you draw the water, then having one big square for the water should be fine.