Using fwidth for distance based anti-aliasing

Analytic, function-based distance fields are great for drawing things procedurally in the shader. As long as you can combine a few function and model the distance right you can simply create sharp-looking geometrical objects – even complex combinations are possible. The following is also true for texture-based distance fields (sdf fonts), but I’ve decided to give distance functions the space they deserve.

2D portal, composed of 2D distance field functions

2D portal, composed of 2D distance field functions

One of the great aspects of these functions is that they can be evaluated for every pixel independent of a target resolution and can thus be used to create a proper, anti-aliased images. If you set it up right.

Instead of the usual circle example where the distance is simple the distance(coordinate, center) and create a diamond pattern:

Distance Field Diamond

Distance Field Diamond

float dst = dot(abs(coord-center), vec2(1.0));

Using a radius as a step/threshold we can very easily create “diamonds” in the size we like:

Diamond Step Function

Diamond Step Function

vec3 color = vec3(1.0 - step(radius, dst));

So far so good. what’s missing is now the antialiasing part of it all – the step function creates a hard edge. Enter smoothstep, a function that performs a hermite interpolation between two values:

y = smoothstep(0.3, 0.7, x)

y = smoothstep(0.3, 0.7, x)

If both values are the same, it boils down to a step. What we now want is to “blend” the diamond into the background, ideally on the border pixels (and therefor not wider than 1 pixel). If we had such a value, let’s call it “aaf” (= anti-aliasing-factor), we could smoothly fade-out the diamond into the background:

Diamond Smoothstep

Diamond Smoothstep

vec3 color = vec3(1.0 - smoothstep(radius - aaf, radius, dst));

Luckily most OpenGL implementations have the three functions dFdx, dFdy and fwidth:

  • dFdx calculates the change of the parameter along the viewport’s x-axis
  • dFdy calculates the change of the parameter along the viewport’s y-axis
  • fwidth is effectively abs(dFdx) + abs(dFdy) and gives you the positive change in both directions

The functions are present in >= GLSL 110 on desktop or >= GLSL ES 3.0. For es pre-GLSL 3.0 there’s an extension GL_OES_standard_derivatives that allows to enable the usage:

#extension GL_OES_standard_derivatives : enable

But how does it connect together? What we need is the effective change of the distance field per pixel so we can identify a single pixel for the distance field. Since we need this for both axis we can do this:

float aaf = fwidth(dst);

fwidth evaluates the change of the distance field, the value stored in the variable dst, for the current pixel – relative to it’s screen tile. The size of that change determines how wide our smoothstep interpolation needs to be set up in order to fade out the pattern on a per pixel level. The antialiasing fade can be used in numerous ways:

  • store it in the alpha-channel and do regular alpha-blending
  • use it to blend between two colors with a mix
  • use it to blend in a single pattern element

The whole shader boils down to this:

float dst = dot(abs(coord-center), vec2(1.0));
float aaf = fwidth(dst);
float alpha = smoothstep(radius - aaf, radius, dst);
vec4 color = vec4(colDiamond, alpha);

Selected remarks:

  • fwidth is not free. in fact, it’s rather expensive. Try not to call it too much!
  • it’s great if you can sum up all distances so that you can arrive at a single dst-value so you only call fwidth once.
  • give fwidth the variable you want to smoothstep. Not the underlying coordinate – that’s a completely different change and would lead to a wrong-sized filter
  • length(fwidth(coord)) is “ok”, but not great if you look closely. Depending e.g. on the distortion/transformation applied to the coordinates to derive the distance value it might look very odd.

Enjoy!

Modified lambert in webgl

i wrote a little demo with a modified lambert function in webgl:

You can clamp the illumination into the “brighter” colors that is expanded into the (usually unlit) back areas and thus allows you lit the whole object. The light can be toggled between a (fixed) lightsource and the camera-position. This is usefull if you (cheaply) don’t want to show “dark parts” of 3d-models while still showing the structure. It can be further tweaked (not implemented yet!) by adding gamma or a two-tone mapping.

WebGL-Paccer (more three.js)

Here’s a little simplified version of a rather known game I’d like to call “WebGL-Paccer”. You play as a yellow ball, trying to eat all the dots before the enemy gets you. Yeah, that one.

WebGL-Paccer

http://www.numb3r23.net/webGLex/paccer

Even though it has a distinct “retro” look, I added an FXAA-aliasing and a bloom-filter to it. I tried doing some dynamic cube-map for floor-reflections, but it didn’t fit the theme.

Maybe in an extended version could not only add more enemies (Blinky, Inky, Pinky, Clyde) but also some more fx. I loved Geometry wars, maybe some effects from them could fit in here…

WebGL: three.js & dat.gui.js

I’ve uploaded an updated WebGL demo I wrote some time ago. It shows a vertex displacement shader on simple models and applies some screen-space image filter (=fragment shaders) to it:

http://numb3r23.net/webgl/vertexAndImages

Here are selected screenshots:

Screen Shot 2013-05-17 at 7.03Screen Shot 2013-05-17 at 7.07

Screen Shot 2013-05-17 at 7.04Screen Shot 2013-05-17 at 7.06

The effects implemented are:

  • Vertex shader displacement
  • TwoTone shading
  • CEL-Shading
  • Gaussian Blur
  • Image Enhancement by unsharp masking the depthbuffer
  • Gamma/Contrast/Brightness adjustment

Github: GLSL shader library

Modern OpenGL relies heavily on GLSL shaders. They are needed for pretty much everything you draw. To ease the handling of shaders I’ve decided publish my shader-collection (well, part of it, for now) on github. The shaders are sorted by GLSL version (currently: version 1.5, webgl 1.0) and “purpose”. Their implementation is focused on readability, not speed. Hence, they can be optimized quite heavily and be combined as well. Anyway, here’s the link:

https://github.com/numb3r23/GLSLShaderLib

I’m planning on continuously adding shaders.

Github: OpenGL 3.2 core Render-library [cpp]

I’ve shared parts of my rendering library on github:

https://github.com/numb3r23/ScIll-library

here’s a feature list:

  • OpenGL 3.2 core profile rendering
  • cpp, compiles with gcc & VS 2010
  • cmake project-file
  • focus on Imagefilters via GLSL fragment-shader

Here’s a little code example on the usage:

using namespace SciIllLib;

CFilter fltFXAA = new CFilter();
fltFXAA->LoadFragmentShader("res/glsl/filter/FXAA.frag");

SFilterEngine::ReGenerateTexture(&m_rtScene, GL_FLOAT); SFilterEngine::ReGenerateTexture(&m_rtFinal, GL_FLOAT);

SFilterEngine::PreRender(m_rtScene);
... render as usual ...
SFilterEngine::PostRender();

SFilterEngine::Apply(fltFXAA, m_rtScene, m_rtFinal);
SFilterEngine::ToScreen(fltDisplay, m_rtFinal);

Of course it can do much more – load textures, load models, …

Video: Spectral rendering on the GPU – soap bubble!

I came up with an idea for a soap-bubble shader!

Two-sided soap bubble thin-film interference

More generally speaking it does dynamic thin-film interference of hollow convex two-sided objects in a deferred rendering configuration. In two passes front and back are rendered and the ray is traced through the object. To give you a better idea I screen-captured my demo-program and uploaded it:

As before all physical parameters of the shader can be changed at runtime (as seen in the above video). Bear in mind, that the program uses OpenGL 3.2 core and runs on my late iMac 2011 – it uses a Radeon 6960M, a mobile GPU.

The cube maps are from Emil Persson and can be found at humus’s textures. The head model is copyrighted to © I-R Entertainment Ltd., taken from Morgan McGuire‘s Graphics Data.