Introduction

Shadertoy.com is an online community and tool for creating and sharing shaders through WebGL, used for both learning and teaching 3D computer graphics in a web browser.

The approach in Shadertoy is to produce images with minimal data input to the graphics pipeline where most of the heavy lifting is performed directly in the fragment shader. The vertex shader in this case is only used to process a full-screen quad which functions as the canvas for these visual effects. This is not always the most ideal way of doing 3D-programming but if you want to play around with a lot of math and get creative, you’ve come to the right place.

In this post, I summarize the discoveries I’ve made along the way and updates to Luz that were necessary to implement Shadertoy support.

Plugin Demo

Here is a demo with a couple of shaders from Shadertoy that this plugin can interpret and render using Luz. They are all listed below in order, all rights belong to their respective owners:

• Playing marble
• Protean clouds
• Luminescence

As you can see, many shaders written for Shadertoy features input support and this data had not yet been forwarded to previous plugins. Alongside with mouse position updates, input callbacks within Luz are now also forwarded to the plugins. This enables us to create interactive turntable cameras or move the position of the camera.

Plugin Dependencies Localization

If you have a DLL that links to dependencies from the same folder, such as other dynamic link libraries, then it’s necessary to add that DLL directory before attempting to call LoadLibrary. Otherwise you will be given the error code 126 from GetLastError, which translates to ERROR_MOD_NOT_FOUND. This could be somewhat misleading at first if your targeted DLL file does exist at the specified location, but it’s in fact the dependency of the plugin that cannot be found.

const size_t pos = path.find_last_of("\\");
SetDllDirectory(path.substr(0, pos).c_str());

pluginHinstance = ::LoadLibrary(path.c_str());

This is an easy mistake to make and I was naive to think that LoadLibrary would be able to resolve this on its own by looking in the same folder the DLL was loaded from. I found the following statement from the official documentation which gave me a better understanding of the issue:

If a DLL has dependencies, the system searches for the dependent DLLs as if they were loaded with just their module names. This is true even if the first DLL was loaded by specifying a full path.

Hence, this is why we need to make the call to SetDllDirectory.

OpenGL Compensations

Unlike Vulkan where headless rendering is possible, OpenGL requires a window to create the context. It’s not really a problem since we can specify to GLFW to create the window as hidden so we will never be able to interact with it. Once we have set it up, we only need the window to swap buffers between render calls.

glfwWindowHint(GLFW_VISIBLE, GLFW_FALSE);
window = glfwCreateWindow(width, height, title, monitor, NULL);

Since OpenGL also defines bottom left corner of the screen as (0, 0) unlike in other API:s where (0,0) is located in the upper left corner of the screen, I felt the need to provide a way to compensate for this without tying myself up to any API conventions. Luckily, ImGui::Image lets me provide the coordinates for the corners of the image and I decided to let the user define what positions the corners should be. This means we can render an image as usual regardless of the convention used by the underlying API in the plugin and then Luz compensates it for final presentation.

  "Framebuffer": {
	"UV0": {"x": 0.0, "y": 1.0 },
	"UV1": {"x": 1.0, "y": 0.0 }
  },

Execution Warnings

Before I started writing the Shadertoy plugin, Luz had no concept of criticality levels in terms of return values from the various stages of execution. If something failed in the plugin, Luz would unload the plugin and return the latest error message.

In this case when you’re reloading shaders on the fly, it’s only a matter of time before you slip and accidentally write some invalid syntax (it’s kind of the whole point to allow for experimentation). Just because a shader could not be compiled, I don’t want Luz to unload the plugin but rather just print the latest error message and keep the plugin active. So it was about time that I introduced some criticality levels:

• Success: Everything executed as expected and the plugin continues to feed Luz with image data.
• Warning: Something of concern was detected during execution and requires the user’s attention. Plugin will continue to execute without the guarantee of correct image presentation or optimal performance.
• Failure: A critical error was detected and the plugin cannot execute properly until it has been fixed.

While the criticality levels themselves don’t always guarantee proper error handling, it can be a guiding tool for troubleshooting along with the messages recorded in the log. Below is an example of how the color coding looks like in the log:

Future Work

In order to reach full compatibility with Shadertoy, my plugin will have to increase its number of iChannel uniforms to a total of four. They are currently only interpreted as sampler2D uniforms but since I’m looking to support cube maps as well, I will work on adding samplerCube uniforms for the next version. Another concept in Shadertoy that I haven’t implemented yet are buffer stages which can serve as input into any of the four iChannel slots to allow for more advanced and longer chains of computations.

Introduction

Today I’ve been diving into the works of Clifford A. Pickover after reading some of his early books on computer graphics when I stumbled over the Clifford Attractor on Paul Bourke’s homepage.

These chaotic attractors can produce stunning visualizations and with example code provided by Paul Richards, I was able to write a plugin for Luz that could render them in real-time. Paul Bourke goes into more detail further down in the page about how these color effects are achieved:

The main thing happening here is that I don’t draw the attractor to the final image. Rather I create a large grid of 32 bit (int or float) and instead of drawing into that in colour I evaluate points on the attractor and just increment each cell of the grid if the attractor passes through it.

So it’s essentially a 2D histogram for occupancy. One wants to evaluate the attractor much more/longer than normal in order to create a reasonable dynamic range and ultimately smooth colour gradients. I then save this 2D grid, the process of applying smooth colour gradients comes as a secondary process … better than trying to encode the right colour during the generation process. One can even just save the grid as a 16 or 32 bit raw, open in PhotoShop and apply custom gradient maps there.

Of course this is “just” a density mapping of the histogram and doesn’t immediately allow for colouring based upon other attributes of the attractor path, such as curvature. But such attributes can be encoded into the histogram encoding, for example the amount added to a cell being a function of curvature.

Plugin Demo

Alongside playing around with the Clifford Attractor, I’ve added a couple of minor features to Luz:

• A grid for the viewport to replace the grey default background
• Replaced performance overlay with a dedicated performance graph to record render times
• The option to save the currently rendered image from the viewport to disk
• Frame buffer label overlay on the rendered image

Gallery

Here is a presentation of the Clifford Attractors I rendered during my session, they are somewhat grainy but the result is nevertheless pleasing to look at.

Until next time, have a good weekend!

Back again with another update!

The shader reloader now supports time related buffers which enables me to animate textures and gradients on the fly in my shaders! In order to test it, I recreated the shader code from ShaderToy demonstrating Inigo Quilez palettes using Voyager: https://www.shadertoy.com/view/ll2GD3

Here is the original article from Inigo explaining the palettes which the shader code is based on: https://iquilezles.org/www/articles/palettes/palettes.htm

I’m slowly becoming able to create more advanced shaders now that I have access to updated resolution and timestamp values from the Voyager engine. Next up on the horizon is to continue to stabilize the functionality I have today and make some necessary refactoring and cleanup. Hopefully I will be able to continue on improving the configuration settings making it easier for shader developers to set up their render passes and custom shader pipelines.

See you next time 🙂

Quick little update this evening! Added support for off-screen rendering in Voyager which enables me to edit the final image composed by all previous render passes, such as adding a “twirl” effect for example.

I was also able to reuse the quad shader for the final render pass with my “Shaderset” configuration, enabling the user to configure their own shader pipelines. Shadersets specifies an array of shaders and attributes for a pipeline where shader types are based on their extension.

Well, it’s that time again. Nothing too fancy, just some fun hobby work I’ve been doing lately on my 3D rendering framework which goes by the working name “Voyager”. In this update, I’m trying it out by making this model viewer application. Can you guess which game this little bugger is from?

I’ve mostly been working on integrating the “Shader Reloader” I created last year into Voyager and the most recent feature I added was the support for wireframe shading. Instead of using geometry shaders which is the common approach, I sent barycentric coordinates as an extra attribute for each vertex and used edge detection by checking the fragment distance against the triangle coordinates with interpolation, essentially a similar approach as in a traditional ray/triangle intersection test.

Although it’s cheaper, I have to think more about screen resolution and how I adapt the line thickness according to the camera distance (which looks awful by the way now at far distances and that’s why I’m not showing it…*nervous laughter*).

Anyway, having the shader reloading functionality implemented makes it so much easier to develop shaders as I’m saving plenty of time not having to recompile at every new startup of the model viewer application. The engine only supports an OpenGL render backend at the moment but I’ve established a high-level API agnostic interface which hopefully will help me implement DirectX backends in the future without too much pain. In the meantime while the interface grows, I’m focusing on more engine features and functionality that I want for creating effects and handling 3D-models.

(For the trained eye, please don’t kill me for the wireframe branch by the end of the shader, I will improve that check)