ShaderToHuman: printing and drawing inside a shader without touching the CPU

A debugging aid scoped to small things

The README is precise about what this tool is for. It helps you with shader writing and debugging, it is meant to be used for small specific use cases such as printing or drawing a few numbers or 2D or 3D elements, and it was optimized for ease of integration, around one file and a few lines of code. The same paragraph closes the door on the obvious alternative: it is not targeting complex UI or minimal performance impact. That boundary is the design, not a limitation to apologise for. A developer who needs to know what a normal or a pixel value is doing does not need a UI toolkit, they need a printf that lands in the framebuffer. The primary language is recorded as HLSL, the licence is a custom one that GitHub cannot classify, and the homepage is seed.ea.com. The topic list of the repository is not given, but the README names the shader languages directly, and the folder structure confirms that HLSL is the source of truth with GLSL derived from it.

No C++ changes, no buffer setup, no content setup

The pitch for adoption is in one sentence of the README: use PrintF debugging, draw a watch window in the viewport, or use 2D and 3D shapes with ease, with no C++ code changes, no buffer setup or content setup required. That is the whole argument for using it rather than the alternatives. The usual way to see a value while debugging a shader is to write it into a buffer, plumb that buffer through the pipeline, add a readback, and put a number on the CPU side. ShaderToHuman removes every one of those steps by drawing inside the shader itself, which means the debug overlay travels with the shader and works in a frame debugger, in a screenshot, or in a build nobody has a readback path for. The examples in the repository show the range of the library, with directories for Features, GaussianSplatting, HelloQuadVSPS, HelloQuadVSPS_Slang, HelloScreenVSPS, HelloWorldCS and Zoom2D, covering the two-dimensional and three-dimensional drawing, a screen-space variant, a Slang variant, a compute shader hello world, and 2D zooming.

Two include sets, chosen by whether you have a preprocessor

The folder structure is where the practical decisions live. The include directory holds the S2H core include files in HLSL, and the README says that is all you need for HLSL or GLSL with a preprocessor. The docs/include directory holds the S2H core include files in HLSL for the case where you want GLSL without a preprocessor, since the GLSL documentation pages are rendered from those. The examples directory holds the S2H core examples to be run with Gigi, which is the shader authoring tool the project is built around, and there are matching JSON files at the repository root named for the Gigi techniques, including gigi_browser_technique.json, gigi_features.json, gigi_gaussianSplatting.json and gigi_helloWorld.json. The unittests directory contains Gigi techniques and shaders to verify function, run with Python from the Gigi DX12 Viewer, and the docs_src directory holds the S2H examples for the web documentation, which are the source for the transpile script.

GLSL comes from a transpile script, not from a second implementation

This is the detail that explains how a single HLSL library serves three shader languages. The repository ships transpileToGLSL.bat, described as the tool that converts HLSL code to GLSL, needed for the server or if you want to use GLSL directly. The contributing notes spell out the workflow: run transpileToGLSL.bat, as it generates .hlsl and .glsl files derived from input .hlsl files, and those are used by the WebGL documentation, and then cycle through the affected documentation pages. So GLSL support is a build artefact of the HLSL source rather than a parallel implementation, which is the right call for a debugging library and also the reason the GLSL path has its own rough edges. The to-do list names one of them in item two: fix table and function plotting for GLSL, since GLSL forward declaration of functions is different from HLSL and a different solution has to be found. The GLSL is also the less travelled branch. The to-do asks for working GLSL samples other than WebGL, ideally OpenGL and Vulkan, and notes that browsers might emulate with DirectX.

The web documentation is a Node server, and it is Windows only

The documentation is interactive rather than a set of static pages, and running it locally needs a specific setup. The README says this is only needed for development on the library, and that it is Windows only. The steps are short. First NodeJS, installing the Windows Installer x64 msi and rebooting. Then run startLocalServer.bat, which on first start installs express, and then connect a web browser to the shown web address. The server side is in server.js with a utils directory, the HTML documentation sits in the docs directory, and node_modules is generated by node.js for browsing locally. The package manifest is minimal and shows the whole dependency picture: adm-zip for working with archives, c-preprocessor for preprocessing, and express for the server, with a start script that runs node server.js and a test script that only echoes an error because no test is specified there. The interactive documentation and the release process are therefore Windows-oriented, which is consistent with the Gigi DX12 Viewer being the place the unit tests are run from.

The to-do list is the most useful documentation in the repository

Eighteen numbered items with time estimates, in days or hours for an average programmer, tell you more about the state of the library than any feature list would. The largest items are the ones that would make it a real tool rather than a debugging aid: an 80x25 text screen API for better performance with similar functions as the gather and scatter API, where the characters and text plus background color would be stored and a post-process or quad pixel shader would project the final text screen, ideally with a C64 style border, and vertical scrolling on the bottom of the screen would be nice but not needed. Item eleven proposes an optional API, another .hlsl include file, to record operations so they are persistent, using an atomic to serialize function id and parameters and a reader to play back the commands. Item eighteen asks for reproducible benchmarks for runtime and compile time on different GPUs and APIs. The quick wins are the sliders, the scroll bars and the horizontal and vertical scroll bar with drag bars that show the size of the view, and item one, a four-hour task, is to pass text in string literals, for example (ui, text), rather than the current form, for modern HLSL only.

Real uses beyond a number on screen

The README shows two examples that stretch the idea well past a debug print, and both are visible in the images directory. S2H was used to render Gaussian Splatting with a stochastic rasterizer, where the input .ply was procedurally generated, and the project links the gaussian-splatting repository it works with. S2H was also used to implement interactive panning, zooming and debugging of pixel colors, which is a viewport interaction rather than a readout. The interactive documentation is presented as the place where rapid prototyping in shaders becomes straightforward, with the Gigi browser used to find the samples by searching for Human. The roadmap section is deliberately thin, reaching out for suggestions and maybe CUDA support, and the to-do raises the same idea at item eight, implementing for other APIs such as WebGPU or CUDA only if there is interest. That conditional framing is the honest signal about where the project sees itself: a small, focused debugging library with a public extension path, not a general-purpose graphics framework.

Licence, contribution rules and who wrote it

The licence is worth reading closely because it is described twice with slightly different wording. The README says the permissive licence makes it free for commercial use and links the LICENSE.txt file, while the License section says the source code is released under an open license as detailed in License.txt. GitHub classifies the repository licence as Other, a custom licence the platform cannot map to a known identifier, and there is a NOTICE.txt at the root alongside LICENSE.txt. The package manifest, which is the npm package for the documentation server rather than the shader library, declares ISC. Contributors must have an Electronic Arts Contributor License Agreement on file, signed by each contributor, and the README says any contribution, large or small, is appreciated and earns a spot on the contributors list, alpha sorted, as part of the pull request. The coding standard section is candid that the standards need to be written up and automated as much as possible, but for now to make your code look like other code. The authors listed are Martin Mittring, Kosmokleaner as main author, and Anushka Nair, with acknowledgments to Alan Wolfe for Gigi and to Electronic Arts and the SEED team.

Editorial conclusion

ShaderToHuman suits a graphics engineer who needs a number on screen while debugging a shader and does not want a C++ buffer round trip, since the whole point is that the drawing happens in the shader with no C++ code changes, no buffer setup and no content setup required. It is the wrong tool for a real user interface, because the README states the tool is meant for small specific use cases and is not targeting complex UI or minimal performance impact, and it is the wrong tool if you need GLSL on something other than a browser, since the GLSL path is produced by a transpile script and the working GLSL samples listed in the to-do are WebGL ones. Verify first which of the two include sets you need, because the include directory is for HLSL or GLSL with a preprocessor while docs/include is for GLSL without one, and note that the project has no GitHub releases while the last push was on 2026-10-13.

Frequently asked questions

Official sources

1. electronicarts/ShaderToHuman on GitHub
2. Issues
3. Project website
4. README