Shaders, Raymarching

Here is the minimal picture i have of how a graphics card works.

There are two main stages, the vertex shader and the fragment shader. The vertex shader is given a list of triangles basically. It computes and applies the transformations necessary to rotate and translate the camera position for the vertices and compute normal vectors and some other geometrical things.

The fragments shader is then passed info from the vertex shader. It has to output a color by setting a variable fragColor. There are variables called that are given the type annotation varyings that are automatically interpolated in the vertex (think of smoothly rotating vectors or colors between vertices). The fragment shader is called once per pixel on the screen.

Mostly information is passed around via pointer rather than function return (I guess that is kind of a common C paradigm and it does make sense.). What does suck about that is you’ll see variables appear out of nowhere. They are basically global variables from your codes perspective. I assume there is a limited number of them so you get used to it. is awesome. It draws a big rectangle and gives you easy access to the fragment shader with some useful extra variables available to you.

It feels like a big map in the functional sense. You write a shader function and then the gpu runs

This is refreshing. The api I’m used to is an imperative api where you consecutively mutate some screen object by called line or point or circle on it. Not that that’s bad, necessarily. But I do like the newness.

This will draw a white circle.


Also here is a raymarched sphere with a little lighting. Ray marching uses the distance function to push the ray smart distances. There are a ton of things you could do here. Could optimize the loop to break when rays get close enough, or when they fly off to infinity.