Hi everyone! I’ve been building pb_emu, a browser-based Pixelblaze pattern
emulator. It runs with .js / .epe patterns against pixel maps
and renders the result live with Three.js. No hardware required.
Some of the features:
- Loads patterns from file, paste, URL, a built-in file browser, or
drag-and-drop. - Supports 1D, 2D, and 3D maps: Marimapper CSV, Pixelblaze JSON, or a
mapper function. There’s also a Gen tab to spin up an ad-hoc matrix (e.g.
16×16) so you can quickly test a 2D pattern. - Auto-reload on save: point the
Pathtab at a file you’re editing in your
editor and the preview updates within a second of hitting save. You can
mount an external patterns directory via PB_EMU_EXTERNAL_PATTERNS in
.env.local so you don’t have to copy files into the project. - Exported sliderX/hsvPickerX/rgbPickerX/toggleX/triggerX/inputNumberX
controls render as live widgets; values persist per-pattern in localStorage. - HUD: LED inspector (click a pixel to see index / raw / normalized coords /
RGB), palette strip when setPalette is active, view presets
(front/top/side/iso), speed slider + single-frame step, screenshot. - Linter flags hardware-fidelity gotchas at load (e.g. time() in render,
perlin/atan2/sqrt per frame).
Known fidelity gaps
- Math is Float64, not 16.16 fixed-point — patterns that deliberately
overflow at ±32768 or exploit 32-bit bitwise fraction bits will diverge.
Almost every published pattern I’ve tried is unaffected. - Transform stack (translate/rotate) is tracked but not yet multiplied
through per-pixel coords. - Sensor-board globals (frequencyData, accelerometer, light) are
zero-filled.
Why
Fast iteration loop when you don’t want to flash a board for every tweak or you’re away from your pb, and a way to preview 3D maps (egg-style scans, Marimapper outputs) before
wiring them to hardware. Happy to hear feature requests, bug reports, or
pattern compatibility issues.