Shadertoy buffer support

[jonbro]

I realize this is a way bigger ask than the other shadertoy features that you have included already, but it would be a really nice one, especially for the ability to do things that are easier with feedback shaders (i.e. light propagation, CA, physics, interactive particle systems). I notice that there is already support for a backbuffer, but multiple buffer support would allow for things like : https://www.shadertoy.com/view/XdtSRn

The major things I think this would require would be:

• [ ] support for passing multiple frag shaders at the command line
• [ ] internally use ping pong fbos for buffer shaders
• [ ] be able to reference the texture uniforms from the fbos

I think it would also cause compatibility issues with https://github.com/patriciogonzalezvivo/sublime-glslViewer - but just posting here to start a conversation about whether it is something that is wanted or not.

[doug-moen]

I'm an OpenGL newbie, and I'm not familiar with the techniques or terminology you mention, so be patient with me, as I'm using google to understand your post. Is "CA" cellular automata? Did you mean "iterative particle systems"?

The shadertoy example you give has 4 fragment shaders and no vertex shader, so I think you meant to write "support for passing multiple fragment shaders at the command line".

I think what you are describing is closely related to the fragment shaders at www.interactiveshaderformat.com. There are "generators", which generate animated images, and "image filters", which transform one image into another. You can plug these shaders together like programs in a Unix shell pipeline, and there is a library of shaders that you can play with. If we supported just this, it would add interesting new possibilities.

However, you mention "feedback shaders", which I guess is more complex than a simple pipeline. In the "Light Propagation Volume" shadertoy you linked to, the Buf C shader reads from the same buffer that it outputs to. The comment is "iterative light propagation, one step per frame", so I guess that's an example of a feedback shader.

---

If the goal is compatibility with Shadertoy source, then we would have to account for the metadata attached to each fragment shader in a multi-shader shadertoy. For example, in "Light Propagation Volume", there are 4 fragment shaders named Buf A, Buf B, Buf C and Image. Buf C has metadata that maps the outputs of Buf A, Buf B and Buf C onto iChannel0, iChannel1, iChannel2, while Image has metadata that maps Buf C into iChannel 0. So, where do we put this metadata?

Do we specify a channel map on the command line, with a separate map for each shadertoy fragment shader? This is similar to how textures are currently specified. It might look like this:

  glslViewer Image.frag -iChannel0=BufC.frag BufA.frag BufB.frag BufC.frag -iChannel0=BufA.frag -iChannel1=BufB.frag -iChannel2=BufC.frag

Or do we look for a specially formatted comment at the start of the shader file that defines the meaning of iChannel0, iChannel1, etc. It might look like this:

[contents of Image.frag]
/// iChannel0=BufC.frag
... rest of the file as found on shadertoy.com

[contents of BufC.frag]
/// iChannel0=BufA.frag
/// iChannel1=BufB.frag
/// iChannel2=BufC.frag
... rest of the file as found on shadertoy.com

Then you just type glslViewer Image.frag to view this model, and the other referenced files are pulled in automatically.

[jonbro]

yeah, CA is cellular automata (which is already supported by glsl viewer), and iterative particle systems is a typo. Meant to say "interactive particle systems". and yup, you are right, I meant multiple fragment shaders. Will edit the issue.

IRT feedback, it is already supported to some extent here, but the access to output of different fragment shaders is exactly what I am asking for. I like the idea of a command line system for defining inputs rather than a preamble on the shaders themselves. I think you don't need the metadata at all, just different u_backbuffers for each fragment shader you define as part of the input on the command line. You would need some way to define which one is the final screen output, but that doesn't seem too difficult.

[wraybowling]

I think we are near a solution since all of the legwork has been done for glslCanvas :) http://editor.thebookofshaders.com/?log=180614121858

[patriciogonzalezvivo]

We have multiple buffers in glslViewer!

[ryanpeach]

Is there an example anywhere?

[patriciogonzalezvivo]

@ryanpeach on:

• the examples/ folder.
• this other repository with lygia examples
• the wiki
• this online curse about pipeline shader prototyping
• and more advance examples on the sponsorware repository you get access through sponsorship