3merillon

I built an open-source WebGPU demo with fluid physics, volumetric clouds, and destructible procedural planets. Water, lava, and terrain all react as you reshape the world. Try it in your browser: 🕹 tmt.3merillon.workers.dev Source: 💾 github.com/3merillon/TMT #WebGPU #OpenSource #gamedev

🍂op.99 no.2 Robert Schumann

🍂 opus 99, IV Robert Schumann

🎯RMT Compose is now free and open source Big update. RMT Compose is now MIT licensed, and this release also brings a settings system, a real reverb, multi-note editing, a much bigger library and a serious performance jump. You can try it in your browser at rmt.world/ Quick reminder for anyone new here. RMT stands for Relative Music Theory, and the idea is that notes are defined as relationships instead of fixed values. A note isn't "E4". It's A4.f * (3/2), a perfect fifth above whatever the base happens to be. Pitch, duration, start time and tempo are all exact fractions referencing other notes, so a composition is really a dependency graph: move one note and everything anchored to it follows, with exact precision. The familiar 12 keys still exist in this world (written as 2^(7/12) and friends), but they turn out to be a small island in an infinite space of pitch that you can actually navigate. So, what's new in this release: Free and MIT licensed. The whole thing: renderer, expression compiler, audio engine. The bundled instrument samples are CC0. Use it, fork it, build on it. A settings panel, finally. Themes with presets and full appearance control, arrow behavior, audio options, library management, and scale controls with editable limits. It's a floating widget you can drag wherever you want. Better sound. New audio signal graph with an algorithmic room reverb, pitch-based stereo panning and a limiter. The synths got an overhaul, and the piano and violin are proper multisamples now. Also fixed the click on stop and the note blast on pause, which had been bugging me for a while. Multi-note editing. Shift-click or long-press to select several notes, then move, delete or copy them to a new module as a group. Composing in gestures instead of one note at a time changes how the tool feels. A much larger library. A full catalog of just intonation intervals, chords, progressions and cadences, some familiar melodies to pick apart, and complete scale systems: 12, 19 and 31-TET plus Bohlen-Pierce, all written in the same rational language. Not perfectly curated yet, but there's real material to learn from and build with. Performance. Evaluation is 6 to 38 times faster, the math stays exact at any depth (BigInt fractions, so no precision cliff, ever), and the WebGL2 renderer draws each note class in a single instanced draw call. A 100,000 note module pans at 60 fps, in a browser tab, and it feels native. Why bother? Western music has spent centuries working with 12 pitches per octave. It's a wonderful palette, but it's a fixed one. Think of it as a box of 12 crayons: you can draw amazing things, and we have, but you're still choosing from the box. RMT hands you the pigments. Any interval you can write as a relationship, you can hear, retune and build on. Exactly, not approximately. An invitation What this needs now is musicians, especially electronic musicians, to pick it up and make something nobody has heard before. Microtonal drones, comma-shifted progressions, harmonic series chords that beat in ways 12-TET physically can't produce. It's all sitting there. And since compositions are plain text expressions, this might be the most AI-friendly music format around. Hand a module to Claude, describe the harmonic structure you want, let it write the relationships, then pull the exact frequencies into your production software and go. Be early. I'd love to hear what you find. Tell me what's broken A new way of thinking about notes only works if the tool itself gets out of your way, and I'm too deep in it to see where it doesn't. So honest feedback is worth more to me than praise right now. What confused you in the first five minutes? What did you expect to happen that didn't? What's bothering you every single time you do it? Open an issue at github.com/3merillon/rmt-com… or just write me. And if you want to go further, the code is open and the developer docs at docs.rmt.world/developer/ cover the architecture: pull requests are very welcome, whether it's a fix, a library module, or a correction to the docs. Where should this go next? I'm at a fork in the road and I'd genuinely like input on it. There are three directions pulling at me: One is depth: turning RMT Compose into a full composition environment. Real per-note dynamics, articulation, better instruments, proper mixing. Everything you'd need to finish a piece without ever leaving the app. Another is bridges: accepting that people already love their production software and building export paths instead. MIDI with pitch bend, MPE, tuning files, or just clean frequency lists, so RMT becomes the composition brain and your DAW stays the studio. The third one sounds crazy but I keep coming back to it: physical instruments. Imagine an auto-tunable piano that retunes itself to the exact ratios of the piece you're playing, or shifts tuning live as the harmony moves. The math for it already exists in this repo. Depth, bridges, or hardware? If one of these makes you want the future to hurry up, tell me which. That's how I'll decide. Links Try the app at rmt.world/ in your browser. The docs with some basic tutorials live at docs.rmt.world/ if you want a guided start. The source code is at github.com/3merillon/rmt-com… under the MIT license, and feedback, bug reports and ideas all go to github.com/3merillon/rmt-com… where I read everything. And if the project resonates with you, there's a little Donate button in the app. #microtonal #justintonation #xenharmonic #musictheory #electronicmusic #musictech #webaudio #opensource

🌍 My 3D engine went deferred, making room for shadow casting volumetric point & spot lights, SSAO. Plus spherical impostors for asteroids, and particles: fire, rain, bubbles. You'll want a gaming PC (~RTX 3060). planets-nine-mu.vercel.app #solodev #gamedev

Procedural Planetoid : added a few new mechanics to the engine. -spherical impostors : asteroids on keplerian orbits, will be repurposed for spaceships in the future. the shadows fall on the player and the terrain as you pass through. -building planting : "B" drops one and "9" stresstests with a couple hundred, the terrain teramorphs underneath. there's also a well with proper rope physics on the bucket "Z or Y". -NPCs : massive NPC handling, N drops one near you or you can populate the whole planet from the UI. early social interactions, they turn their head as you walk past. -mega objects : a world tree to see how planet-scale objects sit in the renderer. -flight model : a new third-person freeflight model. finally ditched the orbital approach, this one should drop straight into space flight when we get there. planets-nine-mu.vercel.app/

❛ :🅟🅡🌎🅒🅔🅓🅤🅡🅐🅛 🅟🅛🅐🅝🅔🅣🌏🅘🅓 ❜ A custom WebGPU 3D engine I have been building. 🚀planets-nine-mu.vercel.app/ The visuals sit closer to a modern installed game than to what typically runs in a browser: a procedurally generated sphere-planet with Rayleigh-Mie atmosphere, volumetric clouds, water with above and below-surface transitions and caustics, grass and trees that respond to wind and to footsteps, procedural music and wind synthesis. Nothing is pre-baked. The only downloaded assets are textures and character models; the terrain, sky, vegetation, and audio are all computed at runtime. What is actually interesting here is not any one of those systems in isolation, but that they all fit together in a page a visitor did not have to install. How it hangs together: Physics, audio, and graphics share source data where it makes sense. The physics fork reads the same density function the renderer uses to mesh terrain. The wind synth reads the same gust field the grass shader uses; what you hear and what you see are one signal, sampled twice. Most dev-facing knobs (cascade priorities and splits, per-cascade shadow resolutions, PCF kernel, cloud step counts, sun direction) are exposed at runtime rather than hardcoded, so tuning is measured in seconds. How it got built... fast: Two forces, both necessary. Claude does most of the coding. I describe the subsystem "a welded marching-tetrahedra mesher with edge-ID vertex deduplication on a GPU compute pass, feeding the existing chunk pipeline" and Claude translates that into working WGSL and TypeScript in minutes, not days. I still make the architectural calls, read the diffs, decide when a subsystem is shipped-adequate. Claude writes most of the code around those decisions. The inner loop is fast. Sub-three-second cold load. Hot-reloaded shaders. A perf HUD that is always on. This is what lets me see, by the end of the day, whether the thing Claude and I just built was the right call. Either one on its own is not enough. An AI that writes code fast without a runtime you can evaluate quickly just generates a lot of half-right code. A fast runtime without fast implementation means a lot of feedback on too few candidates to matter. Together, the cost of trying a structural idea drops from weeks to an afternoon. The current terrain mesher is the fifth approach I tried. Each of the first four ran in the real, playable game long enough to reveal what it could not solve before being replaced. Five meshers over a handful of days is not a consequence of either force alone, it is what both together make possible. Vibe engineering: The label that fits this working mode is *vibe engineering*: rapid iteration at the level of system architecture, rather than at the level of lines of code. Claude writes the code; the inner loop and physical testing validate the result; I stay at the level of *which algorithm, which data layout, which invariant* because the typing and the compilation and the deployment are no longer the bottleneck. It is still engineering, with benchmarks, correctness checks, and measured budgets. What changes is the timescale. Questions that would normally sit in a design document for a quarter get answered in days, on evidence, tested against reality. And the question "is this even worth trying?" changes character entirely when trying is this cheap. The enabling conditions are unglamorous. Pair with a capable AI coding assistant. Keep the inner loop tight. Instrument heavily. Expose the knobs that matter. Move to the next subsystem as soon as the current one is shipped-adequate, rather than polishing any one thing to death before the whole picture is up. Every system in the demo can still be improved. The point is not that anything is finished, it is that the whole thing is a running, playable whole, in a browser tab, highly optimized, built this way in record time. Credits: Predecessor: neural-planetoid. Physics is a custom Rapier / Parry fork. TurboTwig, integrated in under an hour (see previous X post). And Claude, who writes most of the line-level code and without whom the iteration pace that defines this whole project would not exist. #vibeengineering

I couldn't activate SpeedTree, so I built my own procedural tree generator. It runs in your browser. — TURBOTWIG — turbotwig.com I'm working on a planet renderer (Neural Planetoid 2) and need to populate it with trees. SpeedTree was the obvious choice, I even wrote a full loader for it. Then I hit a wall: the editor was corrupting exports because my license wasn't activated. >Fine, I'll just activate it... Except you can't. The SpeedTree website never sends confirmation emails. Their account system has been broken for months. They were recently acquired by Unity and got hacked, and from everything I can tell, solo developers and hobbyists simply aren't on their radar anymore. The only path that seems to work is emailing them directly, and they don't respond to individual hobbyists. This is a real gap. SpeedTree is the industry standard for procedural vegetation, and there's essentially no open-source alternative that runs without a heavyweight engine, at least none that weld branches properly. So I built one. In 3 days. TurboTwig is a procedural tree generator that runs entirely in the browser -- TypeScript, WebGL 2.0, no install required. It uses L-system grammars, CSG branch welding (via manifold-3d), root generation, wind animation, PBR rendering, and exports to glTF so you can drop trees straight into your game engine or 3D pipeline. The UI is built on my own custom GUI framework with dockable, resizable windows. It's MIT-licensed and fully open source: github.com/3merillon/turbotw… Right now tree species are defined in code (presets for broadleaf, conifer, etc.), which actually makes it easy to integrate. You can programmatically generate tree configurations directly in your app; ask your favorite AI to adapt it to your needs. If there's enough interest, the plan is to build this out into a full visual tree editor along the lines of what SpeedTree offers. Automatic LOD generation and billboard baking will be added shortly regardless. Give it a try and let me know what you think. If you find it useful, a star on the repo goes a long way.

This is going to be incredible when I get back to working on trixel.me (a CSS only isometric 3d engine with multiplayer voxel editing and dungeon crawling) I could completely overhaul the character / object handling. I implemented the "Liberated Pixel Art Character Creator" library since I wasn't able to generate gear with previous tools. (Press V in game) First thing I would probably try to do is expand the rotations from Pixel Art to 8 instead of 4 and fill in the missing animations:D This is really cool and I probably have to get an illustrator sub just to try it out!

There have been some massive improvements to Trixel, my CSS-only isometric RPG engine. Play it free:🎮 trixel.me Peer-to-peer multiplayer. Powered by @dcmotz's Trystero, which handles WebRTC matchmaking over MQTT with zero servers. You can create or join rooms, chat with other players (with a profanity filter), and co-op farm procedurally generated dungeons together. The sync model uses authority-based NPC control and velocity-predicted interpolation so everything stays smooth even on rough connections. Character creator with hundreds of assets from the @opengameart Liberated Pixel Cup spritesheet collection. Access it from settings>game or just press V. Mix and match hair, armor, weapons, wings, tails, and more. It fills gaps in animations automatically, so some edge cases have ordering issues, but the variety of assets makes it worth it. Loot you pick up shows on your character. Bows, shields, all of it. AI-powered NPCs. Talk to Cyril the surfer, an NPC who's actually me (the dev) role-playing as a chill surfer dude inside my own game. He's powered by Llama 3.3 70B through @OpenRouterAI, with per-NPC conversation history, a typewriter text effect, and client-side rate limiting. He knows about the game's features and can help you out, or you can just chat. Has fallback models too (Gemma 3, Qwen 3) in case the primary is rate-limited. Dynamic sky and clouds. The sky uses a technique I originally built as a WebGL shader for my looptile repo, which generates seamlessly tiling and looping animated textures using 4D torus mapping. Here it's ported to JavaScript. On top of that, there's a multi-layer cloud parallax system with Perlin noise morphing that follows the camera. Procedural dungeons with themed rooms (crypts, treasure rooms, shrines, boss arenas), difficulty scaling per floor, and a quest/objective system that tracks kill counts, boss kills, and item finds. Full UI rework. Everything is simpler and mobile-friendly now. Proper resizeable window system for inventory (16 slots + 13 equipment slots with drag-and-drop), character sheet with leveling up to 20, map, settings. Weight-based speed penalties if you're carrying too much. Engine improvements. Better A* pathfinding over arbitrary-sized non-overlapping cuboids, improved SAT + KD-tree depth sorting with lazy construction and fragment limits, transparency sprite clipping fixes, virtual DOM reordering optimizations. Ambient Occlusion performance improved. Building a game engine with only CSS transforms is a wild set of constraints. No WebGL, just divs. Early on I tried CSS 3D transforms and hit a wall with performance, so I switched to isometric projection using only 2D transforms, which are significantly faster and can handle more elements. That div limit ruled out a voxel approach, so I needed larger cuboids that don't intersect since there's no z-buffer. That led to sorting with the Separating Axis Theorem and a KD-tree, and from there an A* pathfinding system that navigates through arbitrary-sized non-overlapping cuboids. It still has rough edges but it's surprisingly robust. All of this needs more work and polish. Next up: PvP combat, player trading, improved dungeon generation, a better progression system, static and perhaps dynamic lights using the AO, etc...

LoopTile : browser-based tiling & looping GIF/video generator powered by WebGL shaders. Caustics, lava, plasma, and more. Needed seamlessly tiling and looping water GIFs for a game engine I'm building. Spent 15 min googling, found a couple free assets I didn't like. So I 2-shotted it with Claude Code instead.🤯 Live demo: looptile.vercel.app/ Open source: github.com/3merillon/looptil…

🚀 [RMT] Compose POC just got FAST Rebuilt the engine from the ground up: → Binary expression engine (bye bye text parsing) → Hot paths ported to WASM/Rust → Reverse dependency tree + streaming playback → Visual dependency links for frequency/startTime/duration Dragging a note with 1000s of complex dependents? Undo/redo? Pressing play? Nigh instant. ⚡ Next up: making custom formula editing more user-friendly, and adding useful modules to the editor to make it less obscure 🎯 🎵 Try it: rmt.world/ 💻 Code: github.com/3merillon/rmt-com…

Been hacking away at my little 3d engine and it’s starting to feel like an actual game👀. New stuff since last time : -Resizable window system for map / inventory / character sheet -Dynamic texture atlas for more varied terrain -Transparent objects, procedural rocks, trees, and lathe objects (vases, bottles, potions) -Particle system (currently used for fireplaces and light billboards) -Water with SSR, ripple maps, underwater shader, and basic object physics -Texture splatting on terrain for footprints (player + NPC) and blood pooling during combat -Simple melee combat (yes, you can punch things now using "f" or the circle icon on mobile) -A bunch of new tiling textures generated with Pixio’s Pixcraft -Grass implementation (it works, but it’s on the refactor list) -Simple SSAO (screen-space ambient occlusion) …and probably a lot I forgot along the way It’s still rough, but most of the engine's core pieces are in and it’s edging closer to being a playable game rather than just a tech playground. You can try the current build here: 🎮zengine-xi.vercel.app/ (You'll have to give it some time to load) Huge thanks to: -Polyhaven (textures) -Ez tree (tree assets) -ws.q3df.org (Chaos Marine player model) -Brian Collins (Ratamahatta NPC model) -Id Software -@myaitutor and @pixio_ai for the awesome tools