Building a Browser-Based Voxel Editor with React Three Fiber

Nigisa Yamada — Fri, 18 Sep 2026 01:24:56 +0000

I have been building VoxelDraft, a voxel editor that runs entirely in the browser without an account or installation.

The editor supports block painting, layers, keyframe animation, GIF recording, local projects, and exports for OBJ/MTL, GLB, VOX, Minecraft Schematic, and Roblox RBXL. This post covers the architecture choices that kept those features manageable.

Keep edit data serializable

The editable model is an array of plain voxel records rather than a collection of Three.js objects. That decision makes JSON backups, local persistence, undo and redo snapshots, sharing, and format conversion simpler. Three.js objects are derived render state, not the source of truth.

Render repeated cubes with InstancedMesh

Creating one mesh and one React component per cube becomes expensive as a model grows. VoxelDraft uses THREE.InstancedMesh where geometry and material can be shared. Pointer intersections return the instanced mesh and instance ID, which can be mapped back to the editable voxel record.

There are tradeoffs. Per-voxel colors need instance colors or grouping by material, and changing a single block still requires carefully updating the instance buffers. The reduction in draw calls is worth that complexity for repeated cube geometry.

Make exporters independent from the UI

The format exporters accept voxel records and produce a Blob. The UI is responsible for validation and triggering a download. VOX, Minecraft Schematic, and RBXL are generated directly. For GLB, the app builds a temporary Three.js scene and sends it to GLTFExporter.

Keeping binary generation separate from React event handlers makes exporters easier to test and reuse.

Move GIF encoding off the main thread

GIF encoding can freeze an editor, so gif.js runs its encoder in a Web Worker. The editor captures canvas frames, sends them to the encoder, and displays progress. Resolution, frame count, and FPS need sensible limits because all three affect memory use.

Start local-first, but provide backups

Projects are stored locally so the first editing session requires no backend or signup. This is convenient, but browser data can be cleared and storage is limited. The UI therefore offers JSON export for durable backups.

Pre-render the pages around the editor

An interactive editor is not a great search landing page by itself. The surrounding pages explain the workflow, formats, and use cases. A browser tool has two surfaces: the client-heavy workspace and the indexable pages that explain why someone should open it.

The practical lesson is to keep the data model simple, isolate exporters, move CPU-heavy work to workers, and give users a no-account path plus explicit backups.

Try the free browser voxel editor or read the voxel file formats guide.

Disclosure: I am the developer behind VoxelDraft.

Building a Browser-Based Focus Timer with Web Audio API and Picture-in-Picture

Nigisa Yamada — Sun, 31 May 2026 07:27:24 +0000

I built Pomoria, a browser-based focus timer that combines custom work and break sequences, ambient sound generation, notes, and Picture-in-Picture.

At first glance, it may look like another Pomodoro timer. But the part I found most interesting was not the countdown itself. It was building a small focus environment directly inside the browser.

Most Pomodoro apps are based on a fixed 25/5 loop. That works for some tasks, but not for everything. Studying for an exam, writing, coding, or reviewing a long project often has a different rhythm.

For example, a study session might look like this:

setup
60-minute attempt
short break
review
correction
cooldown

I wanted a timer where each step could have its own duration, notes, and sound context.

The audio engine

The core audio system is built with the Web Audio API.

Instead of only playing background audio files, Pomoria generates and mixes several sound layers locally in the browser:

white noise
pink noise
brown noise
rain-like ambience
binaural tones
metronome sounds
premium soundscape loops

The app creates an AudioContext and builds a simple mastering chain with gain, EQ, compression, an analyser, and output nodes.

Conceptually, the audio graph looks like this:

sound layers
-> atmosphere / binaural / generative buses
-> master gain
-> EQ
-> compressor
-> output gain
-> analyser
-> speakers

This makes it possible to control the whole sound environment from one place while still letting each layer behave independently.

Noise colors

White noise is generated by filling an audio buffer with random values.

Pink noise and brown noise need a little more shaping.

Pink noise feels softer and more balanced than white noise. Brown noise is deeper and warmer. This difference matters because in a focus app, sound is not just decoration. It changes how aggressive or calm the work environment feels.

I wanted users to be able to choose the kind of masking that fits the session.

Smooth transitions

One thing I learned quickly: sudden audio changes are distracting.

So volume changes are scheduled gradually instead of jumping immediately. For longer soundscape loops, I also used crossfading so the loop does not restart in an obvious way.

This is a small detail, but it matters a lot for an app that is supposed to help people stay focused.

Picture-in-Picture without a real video

Another feature I wanted was a timer that stays visible while working in another tab or app.

To do this, Pomoria draws the timer interface to a canvas, turns that canvas into a video source, and sends the video element into Picture-in-Picture.

So the PiP window is not a normal video. It is a live timer view.

It can show the current step, remaining time, visual progress, and different timer styles.

I also connected the timer state to the Media Session API, so play and pause controls can reflect the session state.

Why build it this way?

Because I think a focus timer is not only about measuring time.

It is also about rhythm, sound, visibility, and flow.

A normal timer asks: how much time is left?

I wanted Pomoria to ask a slightly different question: what kind of environment helps you stay with the work?

That is why I am trying to describe it as a focus environment rather than only a Pomodoro timer.

What I learned

Web Audio API is powerful enough for lightweight generative ambience.

Picture-in-Picture can be useful even when the app is not a video app.

Browser autoplay restrictions force you to design around user interaction.

Small UX details, like fade-ins and persistent visibility, matter a lot in productivity tools.

A timer becomes more interesting when time, sound, notes, and session structure are designed together.

Try it

Pomoria is live here:

https://pomoria.app

I would love feedback, especially on the audio controls, the Picture-in-Picture experience, and whether “focus environment” makes sense as positioning.

DEV Community: Nigisa Yamada