Interactive Voxel Terrain

Project Features                                                  Custom C++ Engine / OpenGL / Development Time - 12 Weeks

• 2D Perlin Noise used to randomly generate terrain

• Players can add and remove voxels

• Players may place light voxels, which propagate light in all directions

• Dynamic lighting that is recalculated whenever blocks are added or removed

• World is saved from session to session using Run-Length Encoding (RLE)

• World is infinite and is populated by 16x16x128 voxel chunks

• Side-Face culling for voxels that are covered by other voxels

• Game runs at a smooth framerate while chunks are loaded and unloaded

• Procedurally generated trees

• Integrates with FMOD for audio

• 3D Ray tracing and AABB Physics

• View frustum culling of chunks

• Skybox rendering

• Three camera/physics states: No Clip, Flying, and Walking

Project Overview

This was one of my first projects at Guildhall and my first exposure to 3D rendering. The goal was to create a procedurally generated voxel world using perlin noise with dynamic lighting that could be saved from session to session. It was an invaluable introduction to 3D rendering and provided interesting problems, such as the management of voxel chunks (xyz 16x16x128), data compression, and 3D physics and raycasting.  

The project includes many optimizations, such as side face culling for voxels obscured by other voxels and chunk loading and unloading amortized over frames. The goal was to maintain a steady 60 FPS. 

Players may switch between three different camera and physics modes. 

• No Clip - Physics are turned off and the player may fly and have free roam
• Flying - Physics are turned on and the player has ability to fly but cannot fly through voxels
• Walking - Player assumes a 3D AABB and operates under all physics rules, including gravity and friction

Voxel World

The voxel world is infinite and consists of 16x16x128 chunks. Chunks are identified by their coordinates in the world. There are two 3D spheres attached to the camera which dictate which chunks are loaded and unloaded from disk. 

• Chunks that intersect with neither sphere remain unloaded and not rendered
• Unloaded chunks which intersect with the outer sphere are put in a queue to be loaded
• Loaded chunks that no longer intersect with the outer sphere are put in a queue to be unloaded and saved to disc using Run-Length Encoding (RLE) compression
• Loaded chunks that interest with the outer sphere but not with the inner sphere are marked as invisible and not rendered
• Loaded chunks that intersect with the inner sphere are always rendered
• Sphere radius values are adjustable

Project Post Mortem

What Went Well

• The game ran at a steady framerate and RLE compression allowed for minimal file sizes when loading and unloading chunks. It granted a good opportunity to identify performance bottlenecks and improve performance.
• This was a great introduction to 3D graphics and helped to give me a strong understanding of Vertex Buffer Objects and the 3D graphics pipeline.
• Gained experiencing integrating a 3rd party library (FMOD) for audio playback.

What Went Wrong

• I attempted to debug many game systems, such as physics, chunk loading and unloading, and camera view frustum culling without visual debugging. This led to a lot of frustrating and trial and error attempts to get these systems to a polished state. It made me realize the importance of visual debugging tools and ensuring they are integrated into the development pipeline. 
• Dynamic lighting calculations were often my bottleneck. I initially used recursive algorithms as it made the code look more elegant and readable. I realized there was often a trade off between code readability and performance, and I should have opted for the more performant option since dynamic lighting is an intensive algorithm calculated often. Early in development, planting trees or making world changes that caused massive lighting changes over multiple chunks would hitch the framerate or cause stack overflow issues due to the stack memory footprint of the recursive algorithm. 

What Was Learned

• Planning and designing systems will always save time in the long run and lead to better structured code and less rework. 
• Sometimes code readability should be sacrificed for more performant, less readable code, which is supplemented by comments to assist the reader. This is especially true for code that is run consistently each frame. 
• If multi-threading is not an option, amortizing the cost of operations over frames is a valid alternative. This worked well for chunk loading and unloading. 
• I should not be afraid to refactor or remove old code. Sometimes it is just better to admit something is bad or poorly executed and rework it from another angle. With many of my projects, I usually aim to 'get it working' first and as fast as possible. It is important to revisit this code and not label it as complete. I found it very helpful and moral improving to get systems working fast, but this was also a source of bugs when not revisited in the future or building upon the quick implementations. 

Code Samples