Same math.Different worlds.

I asked Grok Bot to inspect two of my public repositories—ARSENAL First Drop and Countercurrent—and work out what could be reused without borrowing their art direction. Then I asked it to build an idea twice: once without incorporating their source, and once with it.

The starting point was water. The new treatments became a shifting contour landscape and a field of playable visual pads. The point is simple: a numerical component can be useful outside the scene it was written for. You can ask an agent to inspect it, adapt it, and show its contribution instead of starting every mechanism from scratch.

01 / Ocean waves → Living topography

Spectral Terrain

An ocean-wave engine becomes a black-and-acid-green landscape. Instead of reflective water, the surface is drawn through contours. Changing how energy is distributed across spatial frequencies changes the character of the terrain.

What was reused: the FFT wave cascade from The Cove in ARSENAL First Drop, modified with a terrain-oriented power-law spectrum and slower evolution, plus an adapted Gerstner-wave helper. The terrain mesh, contour material, camera and page presentation are project-specific.

Try the live A/B ↗Compare the FFT component →

The controlled view keeps the renderer, camera, mesh, palette, seeds and shared time the same. Both sides retain the upstream-derived Gerstner waves; one adds the adapted FFT cascades. Its control is not a source-free baseline.

02 / Water & float → A field you can press

Resonant Drum Field

Seven pads sit in a circular basin of color. Press a pad and it disturbs the field. In the coupled version, the field also pushes back on the pads, so their motion is part of the response rather than just an input animation.

What was reused: Countercurrent’s CPU reference solver, adapted from its water-and-float system to a multi-pad circular layout. The new colors and instrument-like presentation do not reproduce the original water scene. Here, the simulation runs on the CPU; WebGPU draws the result. This is not a port of the upstream GPU solver.

Play the live A/B ↗Open the fixed-step comparison →

Use the on-screen pad buttons, or focus a simulation and hold keys 1–7. Turn off its scripted drive to play manually. Pause and reset are available. Despite the name, this is a visual instrument with no audio output. Physical MIDI input is optional, experimental and untested.

The fixed comparison uses the same adapted solver, rendering and scripted drive. One condition disables water-to-pad feedback; the other enables reciprocal coupling. Both stop at exactly 864 steps / 3.6 seconds. The separate live control view has independent clocks and is for exploration, not equal-time measurement.

What does this actually show?

There is identifiable source reuse, a new visual treatment, and a measurable effect when a selected component is enabled. The source, notices and comparison conditions are available to inspect. That is a useful, concrete way to work with released code.

It does not show that Grok generally becomes faster, more capable, or more artistic with these repositories. There was no blinded preference study, matched agent benchmark or clean-room baseline. A different-looking image is not automatically a better one. Grok’s exact underlying model and version are unknown for these builds.

Give your agent the mechanism, not the look.

You can try the same approach with an agent that can read and edit code. Tell it what to inspect, what you want to make, and which parts should remain your own.

Inspect these released sources:
https://github.com/AdemVessell/arsenal-first-drop
https://github.com/AdemVessell/countercurrent

My idea: [describe the thing you want to make].

Find the smallest numerical components that help. Explain what each does before using it. Pin the source revision, preserve its licence and notices, and record your modifications.

Make a new visual treatment: do not copy the showcase's composition, palette, camera, branding or media. Build a runnable browser version with clear controls, reset and an honest unsupported-device message.

Show me what the reused component contributes: use the same renderer, seed, inputs and fixed simulation time, changing only that component. Keep failed checks and limitations visible. Do not call a visual difference a quality improvement.

This is a starting prompt, not a performance guarantee. Reuse the released components under their licences; repository access does not grant rights to unrelated branding or media. A fresh source-blind comparison would need a separate agent context before either source is read.

The ZIP includes source, dependency locks, production builds, tests where applicable, evidence and notices. For local editing: npm ci, then npm run dev inside either project. For a static host, use its dist/ folder over HTTPS. If your host strips query strings when redirecting .html URLs, apply the optional canonical-link adapter to dist/ before deploying; preview that export with extensionless HTML routing. No account, API key or remote asset service is required by the demos after package installation.

Sources, credits & scope

• ARSENAL First Drop: pinned revision 36ec504. The Cove’s WaveCascade.js and a modified gerstner() excerpt from WaterMaterial.js. Apache-2.0 · Notice.
• Countercurrent: pinned revision 265e954. The CPU reference.js and test lineage, adapted into multi.js. Apache-2.0 · Notice.
• Build history: I selected and directed the experiments. Grok Bot (BOTHEART) made the initial supplied prototypes. Codex repaired the remaining implementation, controls, responsive layout and evidence issues; packaged and verified the published versions; and built this article. These are collaboratively finished releases, not untouched one-shot Grok outputs.
• Dependencies: Three.js is included under its MIT licence. Complete source and third-party notices are included with both demos and in the download.

What was tested, and what remains untested?

Testing includes 18 release browser checks in Chrome 156.0.8078.48 on a Mac using Apple Metal WebGPU, publication-specific URL/mode and visible-image checks, plus 10 Drum physics tests and four image-readback layout tests. Checks exercise nonblank rendering, local-only demo requests, linked documents, controls, resets, fixed captures, narrow layouts and visible WebGPU-unavailable states. The browser checks and Drum hardware capture used headed Chrome; the Spectral fixed capture used headless Chrome with a hardware adapter. Narrow layouts were tested at 390 pixels in desktop Chrome, not on a physical phone. Other browsers, GPUs, physical mobile devices and physical MIDI equipment remain unverified. Use a WebGPU-capable browser; unsupported environments receive an explanation instead of a silent empty view.

How were the public files prepared?

The article uses actual captured frames, not generated illustrations. The numerical solvers and recorded image evidence are unchanged. A GPU row-padding error in the fixed-image display was corrected; the capture harness already handled padding correctly, so the recorded metrics did not change. Hosted HTML query links use canonical extensionless paths so the site's redirects do not discard comparison modes or capture settings; an optional adapter is provided separately from the source ZIP. Machine-local paths were removed from evidence metadata; public file manifests and the source download were regenerated. Original and current evidence are labeled separately inside the projects.

The reusable part is the mechanism. What you make it look like is still an open question.