glslViewer: the shader sandbox that works from a terminal

A sandbox that refuses to be an IDE

glslViewer is a flexible console-based OpenGL sandbox for displaying 2D and 3D GLSL shaders without the need for a UI, and that last clause is the design, not a limitation the author failed to fill. Everything the program does is reachable through the standard POSIX console input and output, or over OSC, the Open Sound Control protocol that creative-coding environments speak, which means a shader can be loaded, tuned and captured from scripts, schedulers, Max patches or performances. For those who do want an interface, the project includes a Python module, and the README's framing is that you can definitely make your own UI or wrapper on top. The author is Patricio Gonzalez Vivo, the community gathers in the GlslViewer channel of the shader.zone Discord, and the license is BSD-3-Clause.

Conventions documented as four protocol files

The repository root carries four documents that other projects would bury in wiki pages, ARGUMENTS.md, COMMANDS.md, DEFINES.md and UNIFORMS.md, and their existence describes the architecture, the tool's surface is a protocol, so the protocol is versioned beside the code. The defines are the most interesting half, an automatically generated set based on the platform, the buffer, the render pass, geometry attributes and material properties, so a shader can adapt its own code to its circumstances rather than being configured from outside. Defines can also be added and deleted at runtime through console commands or OSC, toggling shader features live during a performance, and custom uniforms of the float, int, vec2, vec3 and vec4 shapes travel the same channels. Reading those four files is the entire onboarding, and their presence at the root rather than in a docs directory is a statement about who the tool is for.

Every texture is an input, including live ones

The texture support reads like a media inventory, static formats png, bmp, jpg, tga and hdr, animated gif, video as mp4 and mov, streaming rtc and rtsp sources, local camera devices, and audio textures, sound made sampleable as an image, the audio path credited to contributor Sergei B. Beyond flat images, cubemaps and spherical harmonics import for environment lighting, the spherical harmonics code originating in Andsz's playground project. The consequence is that a shader session can be wired to the world, a webcam feed, an RTSP stream, a microphone, without leaving the console, and hot reload applies to shaders and to their inputs alike. For live visuals and installations this is the difference between a demo and a instrument, the piece reacts to whatever the room is doing.

Geometry, PBR defaults and shadow maps

On the 3D side, glslViewer imports LST, PLY, OBJ and GLTF files together with their dependencies, and ships default vertex and fragment shaders for both the 2D case and a 3D material shader with a PBR lighting model, so loading a model and immediately editing a physically based shader is the documented workflow rather than an achievement. A default light and a default camera exist out of the box, and shadow maps are supported, which elevates the sandbox from preview tool to something a scene can be lit in seriously. The debug modes betray the author's teaching background, histograms, texture and buffer inspection and bounding boxes, the instruments for understanding what the GPU is actually doing rather than staring at a wrong pixel. The examples directory supplies geometry to start from, including a PLY head model and a flower point cloud.

Hot reload, headless and export in one binary

Three capabilities in the feature list combine into the tool's working rhythm. Hot reload watches files and applies changes as they are saved, the edit loop that makes shader authoring tolerable. Headless rendering runs the same engine without a display, so servers and containers can render frames. And export covers both single images and PNG sequences, turning an animated shader into frames for video or print workflows. Around them sit the presentation modes, fullscreen and a screensaver mode, and the exotic endpoint, HoloPlay rendering for the Looking Glass light-field displays, holographic output from a console tool. The trajectory of these features points away from the developer desk and toward embedded contexts, museum installations, signage, performance rigs, places where the shader is the product and nobody will ever open an editor.

Thirteen GLSL versions in the examples directory

The examples directory contains a quiet compatibility matrix, a test fragment shader for GLSL versions 100, 110, 120, 130, 140 and 150, the ES variants 300es, 310es and 320es, and desktop 330, 400, 410, 420 and 430, thirteen files whose names alone communicate the spread of GPUs and contexts the tool expects to meet, from decade-old embedded GLSL to modern desktop versions. Beside them sit the input assets, images in png, tga, gif and psd, a depth jpeg, and the geometry files, making the examples a self-contained curriculum. The include resolution feature matters here too, resolving shader dependencies the way C compilers do, which is what allows shader libraries to exist as shared files rather than pasted blobs, and the compatibility with ShaderToy shaders, acknowledged in the credits, imports the largest existing body of fragment shader art into the tool.

no-X11, WebAssembly and a credits section as history

The Makefile's three build targets describe the deployment ambitions, the default cmake build, a nox11 variant for machines without X11, and a wasm target wiring the Emscripten toolchain with size optimization, putting the whole sandbox in a browser tab. The credits section doubles as a project history, Mihai Sebea and Bertrand Carré for making the Windows compile happen, Karim Naaji whose fragTool and hdreffects inspired concepts and code, Doug Moen for ShaderToy compatibility and raymarching features tied to his curv project, Wray for the OSC listener that opened the tool to other ecosystems, and Yvan Sraka for shaping the code and setting up CI. Releases 3.5.0, 3.5.1 and 3.5.2 all landed in February 2026, the repository was pushed on 2026-09-27, and against browser sandboxes and desktop IDEs the difference is simple, this is the one that runs where there is no one to click.

Editorial conclusion

Use glslViewer when shaders are assets in a pipeline rather than files in an editor, live performance visuals, generative prints, render farms or installations, where headless rendering, console control and image export beat a graphical IDE. Use Shadertoy for browser sketching or SHADERed when you want a desktop IDE, since both provide the interface this tool deliberately omits. Verify first that your driver and platform match one of the documented compile paths, including the no-X11 and WebAssembly variants for unusual targets, and read the DEFINES and UNIFORMS convention documents before writing shaders, since the automatically generated defines are the contract between your shader and the engine.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. patriciogonzalezvivo/glslViewer on GitHub
3. Project website
4. README
5. Releases