experimental

Aquaforge

A Rust + Bevy prototype using real ocean heightmap data to simulate large-scale water environments.

Aquaforge was an experimental project exploring the use of real-world ocean heightmap data within a 3D environment built using Rust and Bevy.

The goal was to investigate how large-scale terrain data could be visualised and interacted with in real time, using modern ECS-based architecture.

While the project did not reach a fully working state, it provided valuable insight into shader development, rendering pipelines and the challenges of working with WGSL.

Challenges

Working with WGSL shaders and understanding the constraints of Bevy’s rendering pipeline
Handling large heightmap datasets efficiently in real time
Adapting to Rust’s ownership model within an ECS architecture
Debugging rendering issues with limited tooling compared to more mature engines

Lessons Learned

Fundamentals of Rust and ECS-based engine design
Shader programming concepts using WGSL
Challenges of real-time rendering with large datasets
How to approach experimental projects and iterate on unknown problems

Reflection

Post-Mortem

Aquaforge began as an experiment in using real-world ocean heightmap data (GEBCO) inside a 3D environment powered by Rust and Bevy. The goal was to explore how large-scale, real-world datasets could be rendered and interacted with in real time.

One of the first challenges was simply handling the size of the data. The GEBCO dataset is massive, and it quickly became clear that loading it as a single resource was not feasible. To work around this, the data was split into many smaller binary (.bin) chunks, allowing sections to be loaded and processed individually.

At the time, the project was built on Bevy 0.13 (2024), which was still evolving rapidly. While the ECS architecture was powerful and flexible, the rendering pipeline and tooling - particularly around WGSL shaders - were still relatively immature.

Since then, Bevy has progressed significantly (reaching 0.18 by 2026), with improvements in rendering, tooling and overall stability.

A significant portion of development time was spent working with WGSL shaders. Debugging shader issues proved difficult due to limited tooling and feedback compared to more mature engines. Small mistakes could result in silent failures or unclear rendering issues, making iteration slower than expected.

The combination of large datasets, custom data handling, and a still-maturing rendering pipeline made the project increasingly complex. Progress slowed as more time was spent working around engine limitations rather than exploring the original idea.

Ultimately, the project did not reach a fully working state, but it provided valuable insight into the challenges of working with experimental engines, large-scale data, and modern GPU pipelines.

Revisiting the project in 2026, it’s clear that while the original vision was ambitious, the surrounding ecosystem has evolved significantly. Bevy’s improvements in rendering, tooling and overall stability would likely have made the project more feasible if started today. At the time, however, it was a challenging experiment that pushed the boundaries of what was possible with the available technology... particularly around shader development with WGSL, which at the time proved to be a significant source of friction.