First Person Shooter (FPS) style camera

Rendering our first Sphere

Unshaded Sphere

We are ready to render our first sphere.

Lets start with defining the SDFs. In your shader create 2 new functions after uniform variables definitions:

... // uniforms

float sdSphere( vec3 p, vec3 c, float r )
{
    return length(c - p) - r;
}

float sdf(vec3 pos)
{
    return sdSphere(pos, vec3(0), 1);
}
...

sdf is our main function. It tells us how far the point pos is from the scene. sdSphere is a SDF for a sphere. We pass it our position p, centre of the sphere c and its radius r.

Lets implement the Raymarching algorithm:

... // sdf
vec3 raymarch(vec3 rayDir)
{
    vec3 hitColor = vec3(1.0, 1.0, 1.0);
    vec3 missColor = vec3(0.0, 0.0, 0.0);

    float depth = 0.0;
    for (int i=0; depth<MAX_DIST && i<MAX_STEPS; ++i)
    {
        vec3 pos = cameraPos + rayDir * depth;
        float dist = sdf(pos);
        if (dist < MIN_HIT_DIST) {
            return hitColor;
        }
        depth += dist;
    }
    return missColor;
}

As you can see, it is a very simple algorithm. We march along the ray at most MAX_STEPS times. We use ray equation

to compute current position in space. We use sdf to check if we have hit an object. If we have, we return return white color, otherwise march along the ray again. If we have not hit the ray in MAX_STEPS steps, we return black color.

Lets use this function in our main shader function:

void fragment()
{
    vec2 resolution = 1.0 / SCREEN_PIXEL_SIZE;
	
    vec3 rayDir = getRayDirection(resolution, UV);
    vec3 raymarchColor = raymarch(rayDir);
    COLOR = vec4(raymarchColor, 1.0);
}

And add these 3 uniforms at the top of the file:

uniform int MAX_STEPS = 250; // march at most 250 times
uniform float MAX_DIST = 20; // don't continue if depth if larger than 20
uniform float MIN_HIT_DIST = 0.00001; // hit depth threshold

Save the shader and run application. You should see white circle on a black background like here:

If you are stuck, you can use my project on GitHub. git checkout part2-unshaded will do the trick.

Phong Lightning Model

Basic Idea

All we can see now is a white circle on a black background. You might even think that our sphere isn’t spacial at all! And you are somewhat right – without the lights our scene looks flat. We need to implement a light model in order for the sphere to appear volumetric.

We will implement Phong light model. It states that the illumination of an objectconsists of the 3 parts

• Ambient component – no scene is completely black.
• Diffuse component – dirrect impact of the light.
• Specular component – glossiness of an object.

To gain better intuition, check out this link: LearnOpengl, Basic Lighting. On Wikipedia you can find formula we will be using in this tutorial:

Scary but in the end it all comes down to the 3 bullet points:

• Pixel color is deternined by the sum of the 2 components:
  • Ambient lightning, uniform for every object on the scene.
  • Sum of contributions of all light sources
• Each light source contribution is a sum of 2 parts:
  • The diffuse lightning – simulates the directional impact a light has on an object.
  • The specular lightning – simulates the bright spot of a light that appears on shiny objects.

In shader code:

vec3 ambientFactor = ambient * ambientCoeff;

vec3 sumOfLights = vec3(0);

for (int i=0; i<lightSourcesCount; ++i)
{
    vec3 diffuseFactor = ...;
    vec3 specularFactor = ...;
    sumOfLights += diffuseFactor + specularFactor;
}

return ambientFactor + sumOfLights;

Normal Vector and a Diffuse Lightning

Now, we have to discuss the normal vector of a surface. What is it and why should you bother? Well, normal to a surface at some point is a unit vector that is orthogonal to the surface at that specific point:

You need this vector in order to compute the diffuse lightning contribution. Lets say the a we have a toLight and a normal vectors. toLight is a unit vector from the hit point to the light source position:

vec3 toLight = normalize(lightPosition - position);

Because toLight and normal are unit vectors, their dot product is equal to a cosine of an angle between the vectors:

The more toLight and normal are aligned in the same direction, the stronger light reflects from the surface. The contribution cannot be negative, so if cosine is negative we set the contibution to 0.

The final formula looks like this:

vec3 diffuseFactor = lightColor * max(0.0, dot(normal, toLight));

How do we compute the normal to a surface? Well, the normal vector is equal to a nomalized gradient of a SDF at given point. Gradient is a vector that tells us how fast the function grows in small change of its parameters. Feel free to read more about it here. All you need to know for now is that it can be approximated using nothing but SDF itself.

Specular Component

Finally, we want to compute the specular lightning contribution. It is computed by the following formula:

vec3 toEye = normalize(cameraPos - position);
vec3 toLight = normalize(lightPosition - position);
vec3 reflection = reflect(-toLight, normal);
float specularAngleCos = max(0.0, dot(toEye, reflection));
vec3 specularFactor = lightColor * pow(specularAngleCos, specularExponent)
                    * specularCoeff;

Putting it all together

Lets implement the Phong model in our shader! First of all lets define some uniform variables:

uniform float globalAmbient = 0.1; // how strong is the ambient lightning
uniform float globalDiffuse = 1.0; // how strong is the diffuse lightning
uniform float globalSpecular = 1.0; // how strong is the specular lightning
uniform float globalSpecularExponent = 64.0; // how focused is the shiny spot
uniform vec3 lightPos = vec3(-2.0, 5.0, 3.0); // position of the light source
uniform vec3 lightColor = vec3(0.9, 0.9, 0.68); // color of the light source
uniform vec3 ambientColor = vec3(1.0, 1.0, 1.0); // ambient color

We need to compute normal vector to the surface we have hit. Here is the function:

vec3 estimateNormal(vec3 p) {
    return normalize(vec3(
        sdf(vec3(p.x + DERIVATIVE_STEP, p.y, p.z)) - sdf(vec3(p.x - DERIVATIVE_STEP, p.y, p.z)),
        sdf(vec3(p.x, p.y + DERIVATIVE_STEP, p.z)) - sdf(vec3(p.x, p.y - DERIVATIVE_STEP, p.z)),
        sdf(vec3(p.x, p.y, p.z  + DERIVATIVE_STEP)) - sdf(vec3(p.x, p.y, p.z - DERIVATIVE_STEP))
    ));
}

We check how SDF changes when we change X, Y and Z coordinates by a small amount (arount 0.0001). For X, we compute SDF in points (X+0.0001, Y, Z) and (X00.0001, Y, Z) and subtract these values. We repeat this for Y and Z. Then we normalize the resulting vector.

We are ready to implement Phong model. Here is my function:

vec3 blinnPhong(vec3 position, // hit point
                vec3 lightPosition, // position of the light source
                vec3 ambientCol, // ambient color
                vec3 lightCol, // light source color
                float ambientCoeff, // scale ambient contribution
                float diffuseCoeff, // scale diffuse contribution
                float specularCoeff, // scale specular contribution
                float specularExponent // how focused should the shiny spot be
)
{
    vec3 normal = estimateNormal(position);
    vec3 toEye = normalize(cameraPos - position);
    vec3 toLight = normalize(lightPosition - position);
    vec3 reflection = reflect(-toLight, normal);
    
    vec3 ambientFactor = ambientCol * ambientCoeff;
    vec3 diffuseFactor = diffuseCoeff * lightCol * max(0.0, dot(normal, toLight));
    vec3 specularFactor = lightCol * pow(max(0.0, dot(toEye, reflection)), specularExponent)
                     * specularCoeff;
    
    return ambientFactor + diffuseFactor + specularFactor;
}

Then we modify our raymarch function to return computed illumination color instead of plain white:

/* before change
...
if (dist < MIN_HIT_DIST) {
    return hitColor;
}
...
/*

/* after change */
if (dist < MIN_HIT_DIST) {
    return blinnPhong(pos, lightPos, ambientColor, lightColor,
           globalAmbient, globalDiffuse, globalSpecular, globalSpecularExponent);
}

Thats all the changes! Save the shader and run an application. You should see the same picture:

If you struggle, please feel free to use my GitHub project. git checkout part2-shaded should get you here.

With some parameter tweaking you can get the following result:

That is it for now! There is a lot more to cover but that’s as far as I am willing to go right now. You can continue exploring Raymarching from the Jemie Wong’s excellent blog. Cheers!

Raymarching Basics. Camera

In the previous chapter we have set up a sandbox Godot project. We have created a fullscreen shader and have used it to display an opaque red color. Quite boring.

In this chapter I will cover basics of Raymarching. I will provide you a very brief explanation of the technique and focus on implementing camera in the shader. You can jump to the code first and than see the explanation or vice versa.

Theory

Raymarching overview

Lets consider our real world. How do we see things around us? Light sources produce light. Light moves along the ray until it hits some object. Eventually it is either consumed by the object, reflected away from it or refracted. Either way, this beam of light somehow reaches your eye (or camera lens).

We can see objects because the light is reflected back to our eye. Without the light source we can see no objects.

We are going to simulate this phenomenon. But instead of tracing millions of rays from all the light sources (of which very few would hit the eye) we will do the opposite. We will shoot our rays from the eye and see what they hit. Than we will determine pixel color using the hit point, properties of the light source and of the object.

Now comes the tricky part. How do we know what our ray hits along its path? Well, we could:

• For each object find the intesection point with one ray at a time. We are going to pick the one closest to an eye. This is the raytracing technique.
  If we have N objects and R rays than we have to perform N*M collision tests at worst.
• Move along the ray with some steps and check whether or not we have hit some object. This is the raymarching technique.

Okay, so we are going with the second approach. You might ask “How do I pick a step?” and “How do I know that I have hit the object”? And here comes the brilliant solution.

Meet the SDF – Signed Distance Function (takes vec3 -> produces float). It accepts a point in space and tells how far away are we from the objects on the scene.

Here is an example: lets say we have 1 sphere. It is centered in (0, 0, 0) and its radius is 1. Now lets say that we have point (2, 0, 0). How far away are we from the sphere? The answer is

And in our example

How can we answer on “How do I know that I have hit an object?” If SDF returns small value (ex. 0.0001) – you are very, very close to an object. So close that you can say neglect it. If at any point along the ray SDF returns very small number – our ray has hit an object on a scene.

Lets answer on “How do I pick a step?” If you pick a constant step (say 1 unit each time) you have 2 problems:

• If you pick large step you are likely to overshoot your object.
• If you pick small step you are moving very slowly and can miss the 60 FPS goal.

And SDF comes to a rescue again! Lets say that SDF has returned 4. What does it mean? It means that an object is at least 4 units away from your current position, no matter the direction you are facing. It can be further but never closer. So why not march in the direction of the ray 4 units forward?

And here is full the answer: you move as far as the SDF tells you to. This way you will never overshoot the target and will move much, much quicker than with the small constant step.

Now, there is more stuff to consider. But this covers the essential basics. Please watch the video below (starting at 1:55) to gain even better intuition.

Camera

Camera is an object that has a position and a field of view. It represents our viewing window into the virtual world. My camera implementation is based on the video below.

If you’d prefet to read about camera, please follow the link: Ray-Tracing: Generating Camera Rays.

Coding

We are going to calculate ray direction in our fragment shader and display it as a color.

First of all we need a set of parameters that control our shader:

uniform float fov = 45.0; // the vectical field of view (FOV) in degrees
uniform vec3 cameraPos = vec3(0.0, 0.0, 5.0); // position of the camera in world coordinates
uniform vec3 front = vec3(0.0, 0.0, -1.0); // where are we looking at
uniform vec3 up = vec3(0.0, 1.0, 0.0); // what we consider to be up

Uniform variables can be changed outside of the shader (either from script or the Inspector tab). Later on we can manipulate camera from the game engine using keyboard and mouse (or touch on phones and tablets).

For now we will be doing no raymarching yet. We will merely set up a camera. For each pixel we are going to compute a direction that the ray is traversing in.

In the fragment shader add a new function. It will accept the screen resolution and a location of a pixel in normalized coordinates (in range [0, 1]) and produce ray direction:

vec3 getRayDirection(vec2 resolution, vec2 uv)
{
    ...
}

We start by computing aspect ratio of the screen and converting a view angle to radians and dividing it by 2:

vec3 getRayDirection(vec2 resolution, vec2 uv)
{
    float aspect = resolution.x / resolution.y;
    float fov2 = radians(fov) / 2.0;
    ...
}

After that we convert uv (nomalized pixel coordinates) to a range [-1, 1] and invert the y coordinate (because in Godot Y axis flows from the top to the bottom). We can obtain the contribution of the up and right vector:

vec3 getRayDirection(vec2 resolution, vec2 uv)
{
    ...
    // convert coordinates from [0, 1] to [-1, 1]
    // and invert y axis to flow from bottom to top
    vec2 screenCoord = (uv - 0.5) * 2.0;
    screenCoord.x *= aspect;
    screenCoord.y = -screenCoord.y;

    // contibutions of the up and right vectors
    vec2 offsets = screenCoord * tan(fov2);
    ...
}

Now comes the interesting part. We compute the unit front, up and right vectors and make sure they are orthogonal to each other. This creates a coordinate frame. We use it to compute our ray direction. Don’t forget to normalize it!

vec3 getRayDirection(vec2 resolution, vec2 uv)
{
    ...
    // compute 3 orthogonal unit vectors
    vec3 rayFront = normalize(front);
    vec3 rayRight = normalize(cross(rayFront, normalize(up)));
    vec3 rayUp = cross(rayRight, rayFront);
    vec3 rayDir = rayFront + rayRight * offsets.x + rayUp * offsets.y;

    return normalize(rayDir);
}

And we have our ray direction! Now, to test how this works we will display the direction as a color. However, because the color components should to be in range [0, 1] and the coordinates of the direction are in [-1, 1] we have to do one more conversion. Here is the main fragment shader function:

...
void fragment()
{
    vec2 resolution = 1.0 / SCREEN_PIXEL_SIZE;

    vec3 rayDir = getRayDirection(resolution, UV);
    // convert ray coordinates from [-1, 1] range to the [0, 1]
    vec3 adjustedRayDir = (rayDir + 1.0) / 2.0;
    // show direction on screen as a color
    COLOR = vec4(adjustedRayDir, 1.0);
}

SCREEN_PIXEL_SIZE is a Godot constant I use to compute resolution. You can read more about it here.

Here is the full shader code:

shader_type canvas_item;

uniform float fov = 45.0;
uniform vec3 cameraPos = vec3(0.0, 0.0, 5.0);
uniform vec3 front = vec3(0.0, 0.0, -1.0);
uniform vec3 up = vec3(0.0, 1.0, 0.0);

vec3 getRayDirection(vec2 resolution, vec2 uv)
{
    float aspect = resolution.x / resolution.y;
    float fov2 = radians(fov) / 2.0;

    // convert coordinates from [0, 1] to [-1, 1]
    // and invert y axis to flow from bottom to top
    vec2 screenCoord = (uv - 0.5) * 2.0;
    screenCoord.x *= aspect;
    screenCoord.y = -screenCoord.y;

    // contibutions of the up and right vectors
    vec2 offsets = screenCoord * tan(fov2);
	
    // compute 3 orthogonal unit vectors
    vec3 rayFront = normalize(front);
    vec3 rayRight = cross(rayFront, normalize(up));
    vec3 rayUp = cross(rayRight, rayFront);
    vec3 rayDir = rayFront + rayRight * offsets.x + rayUp * offsets.y;

    return normalize(rayDir);
}

void fragment()
{
    vec2 resolution = 1.0 / SCREEN_PIXEL_SIZE;
	
    vec3 rayDir = getRayDirection(resolution, UV);
    // convert ray coordinates from [-1, 1] range to the [0, 1]
    vec3 adjustedRayDir = (rayDir + 1.0) / 2.0;
    // show direction on screen as a color
    COLOR = vec4(adjustedRayDir, 1.0);
}

Run the application. You should see the simillar result:

In any case, the full project is available at my GitHub repository. Just run git checkout part1 to get to this point.

Now, lets tweak parameters we defined on the beginning of the tutorial. Look at the shader parameters in the Inspector window:

Change the fov to 90 and front to the (0, 0, 1). Run the application. You should see similar result:

That’s it for now. A little boring, I know. In the next chapter we are finally going to draw some objects. Until then, cheers!

Motivation

So what is Raymatching?

Raymarching is a rendering technique. It takes a 3d scene (bunch of objects like spheres, triangles, cubes, lights etc.) and produces a 2d image. Here is a list of common rendering techniques:

• Rasterizer – for real-time rendering (games, 3d modeling, user interfaces…). Fast but not realistic. Complex effects are hacky (reflections, refraction, blending…).
• Raytracer – for realistic images with reflections and refraction (Pixar cartoons, movies…). Very beautiful images, simple to implement (at least at basic level), trivial to parallel. However, it is quite inefficient and not suited for real-time rendering yet.
• Raymarcher – quite similar to the raytracing. It makes a good usage of some very clever math tricks to speed up rendering. But don’t get me wrong – it is not a replacement for the raytracing! Simplicity, small executable sizes and ability to run concurrently makes it perfect for demos!

You can see raymarching examples on ShaderToy, Youtube and more Youtube.

Rendering can be done in 2 ways:

• Static randering: you define a static scene with objects, light sources etc and render one single image.
• Real-time rendering: your program constantly updates and renders scene (preferably at 60 FPS – Frames Per Second).

Goal of this Tutorial

I am going to teach you how to implement a real-time raymarcher using Godot game engine and a fragment shader. You will be able to interact with the scene, move the camera around and tweak the field of view (FOV).

There are many ways you could go with implementing a raymarcher. If you are hardcore, you can imlement everything yourself using some 3d graphics API (OpenGL, DirectX, Metal, Vulcan). If you want to start quickly, you could use ShaderToy (I have done so on my first try). But I would recommend using a game engine.

While most would go with Unreal or Unity, I’ve decided to give Godot a try. Now, don’t dismiss it right away. Godot has a lot of nice perks and features:

• It is cross-platform (you can develop on Windows, Mac, Linux, Android, IOS)
• It is completely free
• It is open-source
• You 100% own your project (with no legal BS)
• It is quite simple
• It is quite small (~50 MB executable)
• Portable engine editor (no need to install it)
• No registration required to download it
• It is a mature project
• Community is very active and helpful

Game engine allows you to create application once and build it for any platform it supports. Projects are portable, so you will not encounter irritating problems when you change your environment. And game engine makes adding new features a breeze.

Setup environment

Okay, enough talking, lets do some coding!

Download Godot and launch it. Add new project with the renderer set to “OpenGL ES 3.0”.

Press on the “Custom Node” and search for the “Node” (with the grey doughnut icon) in the Scene tab.

Right click on the “Node” and add a “Control” child.

Now select the Layout -> Full rect layout.

Right click on the “Control” node and add a “ColorRect” child.
Select the Layout -> Full rect layout

Loot at the Inspector on the right and open the “Material” property.
Click on the “Material [empty]” and choose new “ShaderMaterial”.
Click on the sphere that appeared.

Click on the “Shader [empty]” and choose “New Shader”.
Click on the “Shader”
An editor should appear on bottom of the screen.

Type the following code:

shader_type canvas_item;

void fragment()
{
    COLOR = vec4(1.0, 0.5, 0.5, 1.0);
}

Save the scene and name it Raymarcher.tscn.
Run the project (right top corner or press F5). Select Raymarcher.tscn as a main Scene.
If you see a red rectangle like on the image above – you have done well!

Otherwise feel free to clone my project from the GitHub. Use your terminal and type git checkout part0. You will get the same red rectangle as on the image above.

Conclusion

Thats it for now! We have set up a sandbox that will turn into a full-fledged application one day. Hopefully you are as hyped as I am to render your first scene!

Meanwhile you can visit the links below. You will find there my GitHub project, useful blogs and videos. I have used them myself to implement a Raymarcher. Cheers!

Links

• My ShaderToy account
• Link to my project on GitHub.

Youtube:

• How to Make 3D Fractals
• Coding Adventure: Ray Marching

Blogs:

• Ray-Tracing: Generating Camera Rays
• Distance functions
• Godot’s Shading language
• Migrating to Godot’s shading language