webgl-framework VS webgl-dunes

After the terrain we draw a sky hemisphere object with the basic DiffuseShader, and then draw 11 cloud sprites. Then we draw a sun sprite. These transparent objects are rendered without writing to the depth buffer. Clouds and sun have trimmed geometries for less overdraw. You can read about this optimized sprites technique here. We decided not to use soft particles for clouds because scene size allowed us to place them so that they don’t intersect with other geometries while still partially occluding some peaks. Not using soft particles is beneficial for performance because they require additional render pass to render scene depth.

Historically, the web demo was created first — it was used as a prototyping playground to compose a scene and to fine-tune shaders. Also, this really helps in sharing work between a team of two people without necessity to learn Android Studio for both. And when everything was polished and looked good enough, an Android app was created quite fast based on the web demo code. Porting code to Android is a quite straightforward and easy process because our WebGL framework has the same method signatures as the framework used in Android apps.

To examine how objects are rendered, you can take a look at drawScene() method in DunesRenderer.ts — first we render depth map to texture (this is needed for soft particles), then render on-screen objects in front-to-back order (first closest and largest objects, then distant) to efficiently utilize z-buffer culling. Terrain in the scene is represented as a single square tile. Its polycount is reduced to 31k faces in order not to split geometry and to draw it with a single draw call. This polycount produces a reasonably good quality. However, its area is not quite large enough to create a feel of infinite sand desert — when the camera is placed slightly above terrain boundaries of square terrain its limits are clearly visible: