glslViewer runs shaders from the console, and the make targets decide what you build

Six make targets, and one of them removes the window system entirely

The Makefile is short enough to read in full, and it is the clearest description of the project. `make` creates `build`, runs `cmake .. && make` inside it and comes back. `make nox11` does the same in a `build_nox11` directory with `-DNO_X11` passed to cmake, which is how you get a binary with no window system at all. Two install targets mirror the two build directories, and `make clean` removes `build*` with a wildcard, so it takes every variant at once. The consequence for a reader is that the nox11 build is not an afterthought, it is a first class target, and it is the one you want when the output is frames on a render machine rather than a window on a desk.

default:
	@mkdir -p build
	@cd build && cmake .. && make
	@cd ..

nox11:
	@mkdir build_nox11
	@cd build_nox11 && cmake -DNO_X11 .. && make
	@cd ..

clean:
	@rm -rf build*

The wasm target reads Emscripten out of your environment and optimizes for size

The third target is the least obvious. It creates `build_wasm` and passes `-DCMAKE_TOOLCHAIN_FILE=$EMSDK/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake` along with `-DCMAKE_BUILD_TYPE=MinSizeRel`. Two things follow from that line. The toolchain path is built from an environment variable, so `make wasm` fails in a shell where `$EMSDK` is not set, and nothing in the Makefile sets it for you. The build type is `MinSizeRel`, so the wasm binary is optimized for small output rather than for speed, and there is no target here that switches it. For a shader sandbox that is a defensible default, but if you are chasing frame time in a browser you have to change it yourself in cmake, and the Makefile does not offer a flag for that.

wasm:
	@mkdir build_wasm
	@cd build_wasm && cmake .. -DCMAKE_TOOLCHAIN_FILE=$EMSDK/upstream/emscripten/cmake/Modules/Platform/Emscripten.cmake -DCMAKE_BUILD_TYPE=MinSizeRel && make
	@cd ..

Uniforms and defines arrive on the same console that loads files

The defining design choice is that there is no UI to click, so everything crosses the same pipe: the POSIX console in and out, or OSC. Through it you can add and delete `#define` keys, push custom uniforms of type float, int, vec2, vec3 and vec4, and pass `#include` dependencies that get resolved for you. Alongside that, a set of defines is generated on its own from the platform, the buffer, the render pass, the geometry attributes and the material properties, which means two shaders on two machines can disagree without either file changing. A Python module can be included to build a real interface on top, and ShaderToy compatibility came from outside work on it. The cost of putting the interface on the console is that every interaction a mouse would have given you is now something you have to script.

Four root files carry the whole interface, and the tree still needs submodules

At the top level sit `ARGUMENTS.md`, `COMMANDS.md`, `DEFINES.md`, `UNIFORMS.md`, `TODO.md`, `DESCRIPTION` and a `changelog`, next to `CMakeLists.txt` and the Makefile. Those four markdown files are the actual contract of the program: arguments for launch options, commands for the console, defines for the generated vocabulary, uniforms for what you can push. Beyond the wiki, a reader has to read four files to know what a flag does. The tree also holds `deps/`, a `.gitmodules` file, a `.gitignore` and a `.travis.yml`, and the default target only creates a directory and runs cmake, so a fresh clone has to fetch submodules before anything compiles. Nothing in the Makefile does that step for you.

install:
	@cd build && make install
	@cd ..

install_nox11:
	@cd build_nox11 && make install
	@cd ..

Example shaders are named after GLSL versions, from 100 to 430

The `examples/` directory is a version matrix with filenames. You get `test.frag`, then `test_100.frag` through `test_150.frag`, then the ES variants `test_300es.frag`, `test_310es.frag` and `test_320es.frag`, then `test_330.frag` and the desktop range up to `test_430.frag`. The numbering is the fastest way to see which GLSL generation a feature belongs to, and it also shows which versions are covered by a smoke example at all. The same directory holds non shader inputs such as `flower.splat`, `head.ply`, `image.png`, `image.psd`, `image.tga`, `image.gif` and `image_depth.jpeg`, plus an `io/` subdirectory, its own Makefile and a README. What is not there is an expected output for any of those files, so the examples are inputs to look at rather than a test suite you can run.

Texture inputs run from PNG files to cameras, rtsp streams and audio

The texture list is where the scope shows. Stills cover png, bmp, jpg, tga and hdr, and gif. Video covers mp4, mov, rtc and rtsp, plus local camera devices, and audio textures are supported as well. Cubemaps and spherical harmonics have a narrower list: png, jpg, tga and hdr. Geometry import covers LST, PLY, OBJ and GLTF with their dependencies, and there are default vertex and fragment shaders for 2D and for 3D materials with a PBR lighting model, one default light and one default camera. The consequence of that breadth is that the README names no per platform requirements for the video, streaming, camera or audio paths, so you find out what your build actually supports by trying it, and the shader.zone channel is where the author points people for that kind of question.

Headless mode, frame export and LookingGlass share one binary

The last group of features is about where the pixels go rather than what they look like. Debug modes cover a histogram, textures, buffers and a bounding box. Then there is shadow maps, headless rendering, fullscreen and screensaver mode, image export, PNG sequence export, and HoloPlay rendering on a Looking Glass display. Practically, that means the same executable covers a desk preview, a batch render and a lenticular display, and the debug views are part of the running program rather than a separate tool. The sequencing matters for automation: headless rendering plus PNG sequence export is the path to a pipeline, while the Looking Glass mode needs specific hardware and cannot be reproduced from a screenshot. The repository has no tags newer than 3.5.2, released on 2026-02-07, even though the last push is dated 2026-10-24.

Editorial conclusion

Pick it when you want one binary that renders a shader, takes its inputs from a script or an OSC device, and can also export frames on a machine with no window system. Do not expect a packaged tool: the build is cmake plus make over a deps tree, editor and command references live in four separate files at the root, and the release tags stop at 3.5.2 from 2026-02-07 even though the last push is dated 2026-10-24, so pin your own version and read ARGUMENTS.md and DEFINES.md before wiring anything into a pipeline.

Frequently asked questions

Official sources

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