Example: Dynamic Reload of Shaders

[slimsag]

From @dskinner on August 29, 2014 15:58

Can be accomplished with fsnotify. Different editors save files in different ways which can complicate the implementation.

I'll put together a short sample of how I accomplished this later tonight. The example would perhaps be a simplified version of the following that I do:

• Keep shaders in a data/ directory
• Names by convention, so there would be a triangle-vert.glsl and triangle-frag.glsl
• When creating a new shader on an object, call obj.Shader = gfx.NewShader("triangle")
• During object rendering, first check if a shader has been compiled. If not, load the shader data.
• If fsnotify over shaders is enabled then:
  • When a file is changed, lookup objects using shader based on name, for example triangle
  • Mark each object shader as dirty
  • During object rendering, if shader is marked as dirty, reload the data

The example could provide some values in the shaders that encourage the user to change while the program is running.

See azul3d-legacy/gfx-gl2#1

Copied from original issue: azul3d-legacy/issues#19

[slimsag]

Names by convention, so there would be a triangle-vert.glsl and triangle-frag.glsl

I wonder what the most common convention is for GLSL shaders? I thought normally triangle.vert and triangle.frag -- but I am curious ?

[slimsag]

From @dskinner on August 29, 2014 16:32

couldn't say, the only reason i went with .glsl was b/c glsl syntax
highlighters in emacs and sublime recognized that by default, though .vert
and .frag were my first choice, this left me under the impression that
.glsl was more standard.

On Fri, Aug 29, 2014 at 11:30 AM, slimsag notifications@github.com wrote:

Names by convention, so there would be a triangle-vert.glsl and
triangle-frag.glsl

I wonder what the most common convention is for GLSL shaders? I thought
normally triangle.vert and triangle.frag -- but I am curious ?

—
Reply to this email directly or view it on GitHub
azul3d-legacy/issues#19 (comment).

[slimsag]

Ahh. I hadn't thought of that.

[slimsag]

From @dskinner on August 30, 2014 5:25

Here's a sample: https://github.com/dskinner/shadernotify

It was a Gist but the site was doing weird things like erasing the go file when editing desc.

The sample isn't quite how I'm doing things but was the quickest I came up with while trying to keep it simple.

[slimsag]

Very interesting idea! I'd like to see this turned into a simple little package -- I have a few remarks about the code but aside from that I find this to be a very neat idea!

I'll have to think about turning this into a package -- and where to host it.

[slimsag]

From @dskinner on August 30, 2014 14:55

thanks, its mostly a copy/paste fest of code except I actually operate directly on my tree of objects in the watcher of our project instead of returning the event channel from watchShaders in the example.

I think it's worth pointing out here that fsnotify in its current form (I didn't look over the new api of v1 any more so than to make it run) is suppose to make its way back into the std lib so if you're considering a holistic approach to a package that does this I would think this would be a useful debugging tool and rapid prototyping. One would likely disable this for a release build.

In that case, the api would likely provide some sort of func arg that is called to replace the bit of code in the example that parses the shader name to look for from the file name. Implementations based on conventions could also be provided, triangle.vert, triangle-vert.glsl, etc, but a user should be able to define their own.

There's that funky select/case/default to retrieve a value or move on during render as well. Did that mostly b/c of operating on a global slice of objects meant to represent a collection stub of sorts. Really, pulling values should probably happen in another routine.

[slimsag]

From @shurcooL on December 25, 2014 22:3

I tried github.com/dskinner/shadernotify but it didn't compile. I'm guessing it doesn't support OS X, because it uses azul3d.org/chippy.v1 which had no OS X support and is deprecated in favor of glfw3 that does.

~ $ go get github.com/dskinner/shadernotify
# azul3d.org/chippy.v1
/tmp/tempgopath/src/azul3d.org/chippy.v1/glconfig.go:93: undefined: backend_GLConfig
# azul3d.org/native/gl.v1
In file included from /tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.go:33:
/tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.h:2200:13: warning: inline function 'gl_wrap_context_glAccum' is not defined [-Wundefined-inline]
/tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.go:78:2: note: used here
In file included from /tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.go:33:
/tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.h:2739:13: warning: inline function 'gl_wrap_context_glActiveShaderProgram' is not defined [-Wundefined-inline]
/tmp/tempgopath/src/azul3d.org/native/gl.v1/gl.go:89:2: note: used here
...

[slimsag]

@shurcooL I forked and submitted a PR to update it to azul3d.org/gfx/window.v2 so it should work on OS X now.

Merry Christmas =)

[slimsag]

From @dskinner on December 25, 2014 22:56

thanks, merged. It's an older sample where most relevant part is the watchShaders func and an implied reload based on shader name.

What a better solution should do as discussed elsewhere is be able to reload a single shader attached to multiple objects since that's more along the lines of what you would see in a larger application.

[slimsag]

From @shurcooL on December 25, 2014 23:15

Thanks!

It runs now but I'm seeing version '130' is not supported errors compiling shaders. Not sure what the OpenGL version being used is. But in any case, I was able to make changes to shader files and see them being reloaded at run-time. This is a very neat and useful ability.