Been working on a small Javascript library for generating 2D procedural patterns (with the ShaderBuilder in mind).

See the progress here or click on the image below.

The shader builder from a while ago has been resurrected/rewritten and integrated into LxEngine. I prioritized this as I wanted LxEngine Tutorial 3 to have use procedural materials to produce a somewhat advanced look – given the naive objectives of Tutorial 1 (i.e. get a window up) and Tutorial 2 (i.e. draw something as basic as possible).

The shader builder is not complete yet, but the core architecture is done.  With the core architecture in place, advancing the code is largely a matter of adding support for more parameters and adding convenience via simple bits of intelligence in the builder.  Eventually, I’d like the shader builder to be a stand-alone component that any GLSL application can use, that is to say make it usable outside LxEngine. Of course, the application using it will inevitably have to adapt to some of the variable naming, but that’s more or less an unavoidable part of interface with any code that has named arguments.

What?

Below is the demonstration screen shot of a cube with an unlit, nested spherical checker map. And immediately following is the XML + JSON code that’s the input to the shader generator.

Nested checker map procedural, dynamically generated from a JSON-based shader graph

    <Material id="checker_nested">
      {
        graph : {
          _type : "solid",
          color : {
            _type : "checker",
            color0 : {
              _type : "checker",
              color0 : [ 1, 0, 0 ],
              color1 : [ 0, 0, 0 ],
              uv : {
                _type : "spherical",
                scale : [ 8, 8 ],
              },
            },
            color1 : [ 1, 1, .8 ],
            uv : {
              _type : "spherical",
              scale : [ 2, 2 ],
            },
          },
        }
      }
    </Material>

Update:

Below is a slightly more interesting looking example: a weave pattern nested with a checker pattern.  The code for the weave pattern comes from the LxEngine wiki (with the Javascript translated to GLSL):

LxEngine Shader Builder example - a weave pattern with a nested checker pattern

How?

I’ll just fly through the how…

The graph is essentially a collection of functions, each with one output and N inputs.  The functions in the above are “solid”, “checker”, and “spherical”.  Each of these functions is packaged a snippet of GLSL code (i.e. the actual function code) and a chunk of JSON annotation that describes the functions data types and default values.  (These function + annotation pairs are not shown above.)

The builder then merely walks the JSON graph collects the set of functions being used, creates a tree of calls where each parameter is either (a) the default because it was unspecified in the material description, (b) a hard-coded value in the shader because a hard-coded value was used in the material description, or (c) the result of another function call – i.e. which has it’s value generated by recursively repeating the process.

Now, part (b) is inefficient at the moment as two identical shaders with different parameterizations will generate two different shaders because of the hard-coding; however, that’s easily fixable and on the todo list.  (The fix basically is to generate uniforms for all hard-coded values and modify the builder to output a shader + a set of uniform values.  This would then be used along with a simple cache mechanism so the same shader gets returned in case of identical graphs.)