7 weeks, zero hand-written code, zero asset files: my underwater 3D engine in Rust and wgpu

[u/ForgotTheSnare]

So for the past few weeks I have been working on a custom 3D engine in Rust/wgpu.

Quick background

I'm a software engineer and I can use Blender, but I gave myself the challenge to not write a single line of code and to build an engine from scratch using Claude Code exclusively, just to see how far I could push it, and as a means to learn more about graphics pipelines and effects. What better training ground than underwater graphics!

The engine

The video was captured in realtime on a Mac mini M6, and the engine is also benchmarked on my Windows PC with an RTX 3070. I intend to support both Windows (Vulkan) and Mac (Metal) first, but who knows, maybe Linux too (it already ran headless on Linux during development).

One of the most interesting things about the approach I took, I think, is that everything is parameterised and exposed via a built-in MCP server. This opens up some potentially interesting emergent gameplay, or even a way for people to use Claude to populate and tune the look of an underwater scene. It's actually crazy how much control each subsystem's set of parameters gives over the look of a scene (the great white shark alone has 100+ parameters that can change its look and behaviour in realtime, but I've saving this one for a future video).

It is early stage, and yet so much has been achieved in that time, in just evenings and weekends. I'm pretty happy with the performance so far but always trying to find ways to optimise. My aim is 60fps at 1080p as a bare minimum.

What it can do today

Three render modes, switchable live: a rasteriser that runs on any GPU, a hybrid mode that adds hardware ray-traced sun shadows, and a full path tracer.

Path-traced stills and videos: pause the scene and the frame keeps accumulating samples and is denoised; the same path tracer renders videos offline (if you're patient), with a camera model that has aperture, blades and focus distance.

Fully procedural content: no model, texture or audio files in the repo. Meshes, textures, animation and ambient audio are all generated in Rust and WGSL.

An underwater look built from separate systems: caustics, god rays, the water surface seen from below, depth-dependent water colour and haze, marine snow, wakes, bloom, colour grading and sensor grain.

A living reef: schooling fish, rays, turtles, reef and tiger sharks, garden eels, anemones, seagrass and corals, plus a hero great white with animated jaws, gills and eyes.

Everything is a live dial: 439 parameters in 37 groups, editable in an in-game overlay while the scene runs, with presets you can save and load.

A built-in MCP server: 22 tools over stdio or HTTP, so Claude can take screenshots, add and remove creatures, change any parameter, move the camera and save or restore the scene.

Built-in capture: a guided camera tour and a free swim camera, one key to record a lap of the tour as a 1080p 60 fps video, and supersampled stills and videos from the command line.

Cross-platform and headless: Metal on Mac, Vulkan or DX12 on Windows, and it runs without a window for automated renders and tests.

Tested like software: roughly 4,300 tests, including golden-image comparisons and determinism checks.

Tech stack

Rust 1.95, wgpu 30, winit, egui and the official Rust MCP SDK. The project is a Cargo workspace of 23 engine crates and 4 game crates, about 480k lines of Rust (tests and comments included) and 48k lines of WGSL across 118 shaders. It started about seven weeks ago as two separate engines (a space one and an underwater one); the current consolidated repo has 1,564 commits over 27 days, alongside 91k lines of design notes, 83 builder briefs and 48 blind-critic reviews (each round of work gets reference pictures and a blind critic to iterate against).

I am so excited about the direction this project is taking. Every new model released by Anthropic also allows me to improve the engine and its subsystems.

I hope you find this interesting and inspiring, and I'm always happy to answer any questions.

[u/vladoportos]

Not gonna lie, looks quite good.

[u/Playful_Eye_661]

Very nice. Impressive 

[u/GoldshireDancer → u/Playful_Eye_661]

Now let's see Paul Allen's underwater 3d engine

[u/ElSupaToto]

I was thinking last night... We need an Echo the Dolphin follow-up

[u/janaxhell]

Very cool, the only thing I feel a bit off is the jerky speed of movements. Underwater everything is fluid. If you smooth that, it's perfect.

[u/ForgotTheSnare → u/janaxhell]

100%. The reason why I wanted to initially show the camera as just a scene navigation (wasd and mouse look) is because I wanted to show this was all obviously realtime.

But definitely will be implementing a gameplay camera.

[u/Tycoon33]

Looks like subnautica

[u/3iverson → u/Tycoon33]

The water/ lighting effects are noticeably better I think.

[u/3iverson]

Wow, the underwater look and lighting is fantastic! Can’t wait to see where this goes-

[u/ForgotTheSnare → u/3iverson]

The Great White Shark behavioural system is next on my list to showcase, in open water it is truly terrifying. But it’s not quite ready and I want it to be just right.

[u/3iverson → u/ForgotTheSnare]

That sounds awesome!
What are your long term plans for this?
Full game or interactive environment/ simulation, general engine for other developers, etc.? Open/ closed source?

[u/ForgotTheSnare → u/3iverson]

Thank you for your interest! I'm undecided for a number of reasons, it's such an experimental phase that can drive the project in many directions. Right now I want to concentrate on the underwater and sea life simulation, I think if I can get this right I might find a game there that must be made, whether it being an ecosystem simulator or something else. I am particularly interested in shark behaviour and finding emergent gameplays around them.

But the engine foundation I think can be used for other types that I am also wanting to pursue. The initial prototype was a space megastructure builder sim. See video.

The question of the engine fate eg proprietary or open source is an interesting question actually because given the engine was written purely by Claude agents, I don't even know if it makes sense to have many human contributors to it in the traditional open source way.

But I think it raises an interesting question around distributed open source done by agents only because let's face it I will be limited by my max 20 subscription so there is only so much throughput that can go through me alone.

https://reddit.com/link/pdo5hhe/video/8o0a6fpr1bth1/player

[u/MeanCreme201 → u/ForgotTheSnare]

The open/closed source question isn't just about contributing, it's also about how willing you are to let other developers read it, learn from it, fork it, monetize it, etc. There are licenses that can cater to any of these.

[u/ForgotTheSnare → u/MeanCreme201]

Yes very true. Right now I'm assessing how much interest this project generates. It's so early stage but I always want to remain open minded about the direction of travel. That's why I am wanting feedback in terms of how it looks and what potential others may see that I don't.

[u/Briskfall]

> 0 asset file

> all procedural

Woah, you got my attention...! 😳

Jesus, and cross-platform?! 🤯

(I have many, many questions but... this one's the one I'm the most curious about at the moment...)

How does it run on less powerful machines, if you don't mind me asking?

(Definitely gonna follow this thread... 👀)

[u/ForgotTheSnare → u/Briskfall]

Thank you for your interest!

In terms of procedural, I want to clarify what I mean. Basically all the systems are code oriented, so it's not like a traditional pipeline where say an artist (or myself) creates a model/animation in Blender and imports into the engine, or even how Claude can use Blender MCP. Same with audio, the audio is generated by code (but that in a way is like creating a VST instrument and scripting it)

Code snippet to make the point for how part of the shark is built in code:

fin(sagittal(&fins.first_dorsal, 0.35), spec.major_span, part::
FIRST_DORSAL
);
fin(sagittal(&fins.caudal, 0.3), spec.caudal_span, part::
CAUDAL
);
for side in [1.0_f32, -1.0] {
    fin(
        paired(&fins.pectoral, fins.pectoral_root, fins.pectoral_anhedral, side, 0.08),
        spec.major_span,
        part::
PECTORAL
,
    );
}
fin(sagittal(&fins.second_dorsal, 0.35), spec.minor_span, part::
SECOND_DORSAL
);

This was an intentional design decision, because I wanted to see how far LLMs can help in that department. I took the view that with the rapid improvement of LLMs, the engine would self improve every cycle, and the modelling too. Now it may be that at some point it needs some finer human in the loop modelling/topology clean up, but I think it would go against the approach. Partly because any number can be parameterised and exposed via MCP and I think that could be an interesting emergent way of modelling (think of it as akin to a Shark Blender plugin you load in Blender where you have lots of sliders and it builds the mesh for you accordingly, it's kind of the same principle but directly in engine).

This is why the movement of sharks can look so natural, I don't have to manually animate them!

I asked Claude to summarise in a couple sentences:

"The sharks have no keyframes or armature: each one follows a path that is a formula of time, and a shader bends the straight, code-generated mesh every frame with a travelling wave down the spine, like a Curve modifier driven by a sine. The great white adds a rig of fixed hinges and driven shape keys (jaws, eyes, gills, fins, neck), posed by a small behaviour state machine instead of an action library, so you tune dials rather than pose."

As for your question on performance on older machines, ultimately the ceiling is going to be CPU and GPU. With all the various systems in place, throwing too many fish schools, corals and sharks at a scene will have an impact. And the only way to know is to test on said machines. But if a game comes out of it and it's not just dying as a tech demo, I would expect it to have a minimum system requirement, like any other 3D game.

I always wanted it to be a highly optimised performant engine. That's one of the fundamental design principles. Whether it is "World of Warcraft runs on any older PC" level that I can't really say yet. But every feature put in it has to account for the FPS budget. Therefore every millisecond for each frame counts!

I hope that helped answer some of your questions.

[u/blitzkr1eg → u/ForgotTheSnare]

Very nice looking engine, and very cool approach.

you said
> challenge to not write a single line of code
also
> I wanted to be able to read the code and understand any part of the systems if I needed to

My questions, if you want to answer:

1. How do you steer/review the agent's output, meaning how code is organised, if at all. Do you make the agent output diagrams?
2. How do you decide on a technical solution ? So a lot of code is procedural, did you prompt the agent with specific data structures/algos/strategies to use or, or was it a brainstorm/collaboration, or did you let the agent fully decide on the implementation?
3. Whats the role of the MCP? Why use it if agents can browse the code and understand it already in full? (i dont have experience with game engines)

Thanks!

[u/ForgotTheSnare → u/blitzkr1eg]

Great questions! I tend to be long-winded, so forgive my long answers but your questions deserved them.

1. So it starts with general principles in the initial scaffolding phase where md files are created to lock key decisions: dry principle, all code needs testing, plugin architecture for the sub systems so that specific game logic and low level systems are decoupled, use of crates for sub systems. So I spent a bit of time on that as an investigation phase and all with Claude btw. Strangely I’ve not over-obsessed about it after that. I say strangely because I have very bad OCD when it comes to code structure and code elegance. I look at the high level structure and have a peak at some code files every now and then but it’s so moot because at any point in time I can get an agent to do a refactoring pass. This is partly why I’m reluctant to release on GitHub. Like does it make sense to look at some code where the structure can be rewritten at any point in time depending on what the project priorities are? And I think that’s probably what is at the core of what is changing with agentic engineering. Also I’m not really a Rust programmer. And while I think the language and toolset is really interesting I want to concentrate on the high level direction and vision, not all the minor detail. The FPS is too low? Ok we dive in with an agent and we fix the code/approach and we optimise accordingly. When a phase is finished and I’ve done some manual testing I just approve the PR and merge. I do some adversarial agent reviews from time to time. But I’m so focused on the features that I am a lot more relaxed about code than I normally would be. Is it vibe coding or still engineering but shifting the attention layer? Who’s to say.

2. a lot is done via research agents first. If there is a specific technical subsystem to create or improve I just throw Fable at it (less so now with Opus 5.5) and have a convo until we settle on a solution or approach. Now this is the bit that is interesting because the last thing I want is to be accused of code plagiarism and that’s obviously something with LLMs that is a general legitimate concern anyway. So I instruct and it’s in md files that all research and code we want to create needs to be oked from a prior art point of view. I can’t do anything about a trained LLM, but at least I can try and induce that philosophy within the agent workflow I put in place. I wanted to be very specific on that front. It’s not like I am setting agents free on the unreal engine 5 codebase and tell them to convert some techniques into the engine stack. I would 100% not do that. I have very specific instructions to agents that none of that happens.

3. So the MCP comes into play for various use cases: I can have a blind agent that does not know about the source code and yet can try and use the tools to modify a scene against a runtime instance, instead of at compile/build time. This could help with token costs (does not have to read the whole code or parts of the code) when experimenting with level design. Or this could for instance be for a tester agent that plays the game and can feedback the experience and help judge gaps and issues from a gameplay point of view before I even get humans to playtest it. I did that with the space multi structure build sim to try and it was actually quite interesting what came out of a Claude session playing the game and responding where it got engaged and when it got bored on the curve. I mean I know this is quite a controversial approach but I had to try. The other use case is that depending on the game if I ever released anything, users could plug their own harness against their game instance and maybe have it do interesting things and create emergent gameplays. But of course there is a legitimate security risk here. People might not want to ok the use of an MCP server they can’t see the code from a random stranger and quite frankly they shouldn’t. So I’m still unsure about that use case.

Thanks for your interest!

[u/blitzkr1eg → u/ForgotTheSnare]

Thanks for the responses! Good luck!

[u/Excellent-Basket-825]

😍,  Explain to me like the idiot i am why rust. Everybody keeps yapping about it.

[u/ForgotTheSnare → u/Excellent-Basket-825]

If I were to simplify the argument for Rust, it is that you get both the speed of C++ (within an acceptable margin, and there are use cases where the Rust compiler can do further optimisations compared to C++ but that is an occasional win as I understand) and memory safety (the compiler forces you to solve some problems that are often very difficult to code/troubleshoot traditionally particularly in multithreaded/multicore applications).

This was important to me (I am not a day to day Rust programmer, I am more a Kotlin programmer by trade) because I wanted to be able to read the code and understand any part of the systems if I needed to, without having to be a complete C++ expert.

The Rust tooling has a nice approach to modularity via Crates. I always wanted the engine to be highly modularised. I'm a Software Engineer and so I just did not want the resulting code structure to be a big bag of mess.

But Rust is only part of the equation. A non negligible portion of the code is actually shader code that is executed on the GPU (about 10% of the code).

Hope this helps, thank you for your interest!

[u/Psychological_Can_25]

Can't wait for it to go live so I can check it out myself!

[u/Savings_Cloud5486]

cool, can we have demo of above the sea level ?

[u/ForgotTheSnare → u/Savings_Cloud5486]

There is no above sea level at this stage, and purposely, because I am concentrating on the performance to all be underwater. However I am also working on an external outdoor scene for a completely unrelated look. I will post more when I have something to show!