One HTML file carries the water scene
Clearwater puts its shallow-water renderer, camera controls, and seabed texture inside index.html. The interaction described in its English README is immediate: drag to change your view, then tap the water to create ripples. For a developer who wants to study how a water scene is drawn, having the shaders beside the browser code makes the effect inspectable. I'd choose it for a standalone graphics experiment or a starting point for a custom visual.
WebGL2 does the rendering, with floating-point textures holding intermediate results. That requirement is the first decision to make before copying the file into a website. A browser capable of displaying ordinary HTML can still lack the graphics features this scene needs. The single-file packaging reduces deployment work, while the browser and GPU determine whether the effect can appear at all. Treat the compatibility check as part of adopting the renderer.
What happened when we ran it
Our lab did not run Clearwater commit 4bc8261 on October 12, 2026: HTML was not a supported ecosystem, and the repository had no Dockerfile. The supplied sandbox record lists 3 CPUs and 8 GB of RAM in an unprivileged container without secrets. It provides no install, build, or test results, and no container image was recorded. Those machine specifications do not establish browser or GPU compatibility.
The practical consequence is that we cannot attach a measured frame rate or a passing browser check to this recommendation. The README says to open index.html from disk or a static host. That is the documented route, separate from a result observed in our sandbox. Clearwater's suitability therefore rests on its documented requirements and visible code, with rendering behavior still needing validation on the devices you intend to support.
Unsupported graphics hardware gets an error message
The page requests a WebGL2 context and checks for floating-point render-target extensions. Its initialization code displays an error and stops if the context or required texture capability is unavailable. The README names EXT_color_buffer_float; the code also checks a half-float extension. That detail doesn't justify promising broader compatibility, but it does show that the author handles a missing capability explicitly.
There's no alternate still image in that failure path. For an optional experiment, a visible error is adequate. For a customer-facing page, I'd add a static visual and keep essential text and navigation outside the canvas. The supplied October 12 record gives no evidence for how phones or restricted browsers handle Clearwater. Test the actual supported devices before making the scene part of a page visitors need to use.
Adaptive resolution trades detail for responsiveness
Clearwater changes its rendering resolution in response to frame timing. Its frame loop reallocates render targets as quality changes, and the code refreshes glare less often under certain conditions. The README's ?debug option exposes frame rate, resolution, and quality level. That makes it possible to see which compromise the renderer is making on your machine instead of assuming an attractive scene stays equally detailed everywhere.
The URL controls also help isolate visual choices. ?noglare disables lens-diffraction glare, while ?view=caus displays the light pattern focused through the water onto the seabed. Camera direction can be supplied through yaw and pitch. These are practical tools for examining the effect. They are not performance results: neither the README's adaptive-resolution statement nor the presence of a debug display supplies a frame-rate guarantee.
Editing the seabed means replacing an embedded image
The pebble texture sits in a base64 block at the end of the HTML file. Clearwater therefore doesn't need to retrieve a separate seabed asset to draw the scene. The README maps the code into named sections, including wave generation and the main water shader. That organization gives an experienced graphics developer clear places to change wave steepness, water appearance, or sun position without tracing an unrelated application framework.
Regenerating the seabed uses tools/make_pebbles.py, which the README says requires NumPy, SciPy, and Pillow. You then paste the generated JPEG's base64 data into the HTML block. That's manageable for occasional art changes, but awkward for an application with interchangeable environments. Three.js's Water addon accepts geometry and options through a documented constructor. Choose that integration style if your scene already lives inside a larger Three.js application.
Reduced-motion handling doesn't stop the water
The CSS reduced-motion rule removes the interaction hint's fade transition. It does not govern the water animation, and the normal frame loop continues requesting frames. Camera movement and ripple input use pointer events. Those specific choices need attention before using the page as a website background: provide a way to avoid animation, and don't depend on pointer-only interaction to communicate anything essential.
The documented ?t=5 option freezes simulation time for screenshots, so Clearwater already has a useful route for inspecting a still composition. It isn't a visitor-facing pause button or an automatic response to a reduced-motion preference. Evan Wallace's WebGL Water demo includes a spacebar pause control and a movable sphere. Pick that project for studying those interactions, while checking its own graphics-extension requirements.
September activity supports a cautious recommendation
The last push was September 23, 2026. GitHub listed 511 stars and 1 open issue or PR on October 12; that item is an unmerged jetski-simulator pull request updated September 24. There was no latest release returned by the release endpoint. This is a small project with recent visible activity, but the proposed simulator belongs to the pull request, not Clearwater's published feature set.
MIT licensing and an embedded scene make Clearwater worth examining when you want to adapt this particular shallow-water effect. Its shader code and hardware requirements call for a developer comfortable owning the graphics work. Use the standalone page to study the renderer, then decide whether you can support its browser limits. For a production background, the fallback image and motion controls are work you still need to supply.