Understanding Post Process Shaders

Preamble: this document is not a A-Z guide for writing shaders. It only pretends to explain the basic principles behind minecraft's post process shaders.

When the game is rendered each frame, it is not drawn directly onto the screen. Rather, it is more like it draws shapes onto a canvas^[1] , layer over layer, before copying the result onto your screen. Just like the canvas' content can be drawn onto the screen, it can be drawn onto another canvas. A shader lets you give instructions describing how the drawing will get copied from one canvas to another. Because shaders are run on the GPU, they are optimized for image processing, letting you render impressive effects at a much lower performance cost. The downside is that shaders do not have direct access to code and variables from the java application, so every data needed in the shader must be uploaded to the GPU first. _{Also, maths}.

^[1] such a canvas is called a framebuffer.

A post process shader effect takes the currently rendered frame, draws it to any number of intermediate buffers, then (optionally) draws it back to the main framebuffer. Each time a framebuffer is drawn to another is called a pass.

Each pass is characterized by a main input framebuffer, an output framebuffer, and a shader program. The shader program takes data from one or more textures (main texture being the input framebuffer), as well as arbitrary data from the java application (called 'uniforms'), and computes the resulting 2D image that will be drawn on the output framebuffer.

If you have little to no experience with shaders, I now recommend you go through The Book of Shaders before proceeding. It is an excellent resource to learn how to write shaders, with an integrated playground. If you want to use another resource to learn, that's fine too. Just try to get a basic feel before working on them for a mod.