maaark

Recently I've been interested in porting Shadertoy shaders, especially game of life and reaction-diffusion kind of systems that use feedback.

By reading up on the Shadertoy examples and 

great overview of what one needs to change when porting shaders (last post in thread)

One thing I'm wondering is how to deal with the feedback. I'm trying to port this shader 

, and running into problems. I tried to figure out how to deal with the feedback by looking at some jit.gl.pix examples like jitter-examples/gen/pix.game.of.life and examples/gen/reaction.diffusion.color.world. those use a combination of [zl reg] and jit.gl.slab, but I haven't been able to get that to work for this one. What am I doing wrong?

By reading up on the Shadertoy examples and this patch with ported Shadertoy tuts, as well as Syrinx' great overview of what one needs to change when porting shaders (last post in thread) I've gotten quite far.

One thing I'm wondering is how to deal with the feedback. I'm trying to port this shader "Vicious Fingering", and running into problems. I tried to figure out how to deal with the feedback by looking at some jit.gl.pix examples like jitter-examples/gen/pix.game.of.life and examples/gen/reaction.diffusion.color.world. those use a combination of [zl reg] and jit.gl.slab, but I haven't been able to get that to work for this one. What am I doing wrong?

shaders-to-jit-gl-pix-how-to-deal-with-feedback-ichannel0-etc

I like the idea of using [zl reg]. I'll have to remember that, but I don't think that's how the feedback is handled in this shader.

I recently asked about iFrame and was told to use a counter to bang param values into [jit.gl.pix] . Set params in [codebox] with the form: 

. Remember that params have to be inserted after function definitions and before everything else.

If you take that approach, the if statement in the last few lines will make more sense. You can use something like:

Use [jit.matrix @thru 1] or better yet [jit.gl.texture] to handle buffer outputs (not [jit.gl.slab] ) - however, in this case, notice that the code on shader toy has two tabs.. "buffer" and "image". You likely need to use both., so you can use a second [jit.gl.pix] object to mediate re-entry.

Also notice that you can't directly reconnect to the first inlet of the parent without a stack overflow error, so you have to use a 2nd inlet in the main gen patch. The other clue that points to the need for a second inlet is the use of both ichannel0 and ichannel1 in the same code. That means 2 inputs. They can be whatever inlets you want as long as everything maps properly .

Something counterintuitive I learned.. often times [in 1] is fed an empty matrix. It sets the dimensions of the gen object. All of my first gen shaders had [jit.noise] objects feeding them... you don't need that most of the time. In general, you don't have to put any pixel data into a gen shader if the output is generated purely from dimensional references. Beyond that it's your choice how to organize i/o.

Be sure to use the 'max ' and 'code' windows to check for errors and confirm that your code is compiling. I saw a couple when skimming your code:

- variables e and norm are already in use by Gen. Gotta use other names (lines 22 & 57)

- clamp operator in line 69 is missing range arguments

I will post the shader once I have more time (if I can get it working). Please do the same. . It's a beauty. Looks amazing after it has been running for a while... like sand dunes. Good luck!

I like the idea of using [zl reg].   I'll have to remember that, but I don't think that's how the feedback is handled in this shader.  

 I recently asked about iFrame and was told to use a counter to bang param values into [jit.gl.pix] .      Set params in [codebox] with the form: Param ();.  Remember that params have to be inserted after function definitions and before everything else.   

If you take that approach, the if statement in the last few lines will make more sense.    You can use something like:out1 = (iFrame

Use [jit.matrix @thru 1] or better yet [jit.gl.texture] to handle buffer outputs (not [jit.gl.slab] ) - however, in this case, notice that the code on shader toy has two tabs..  "buffer" and "image".    You likely need to use both., so you can use a second [jit.gl.pix] object to mediate re-entry.  

Also notice that you can't directly reconnect to the first inlet of the parent  without a stack overflow error,  so you have to use a 2nd inlet in the main gen patch.   The other clue that points to the need for a second inlet is the use of both ichannel0 and ichannel1 in the same code.   That means 2 inputs.  They can be whatever inlets you want as long as everything maps properly .  

Something counterintuitive I learned..   often times  [in 1]  is fed an empty matrix.  It sets the dimensions of the gen object.   All of my first gen shaders had [jit.noise] objects feeding them... you don't need that most of the time. In general, you don't have to put any pixel data into a gen shader if the output is generated purely from dimensional references.  Beyond that it's your choice how  to organize i/o.

Be sure to use the 'max ' and 'code' windows to check for errors and confirm that your code is compiling.     I saw a couple when skimming your code:

- variables e and norm are already in use by Gen.   Gotta use other names (lines 22 & 57)
- clamp operator in line 69 is missing range arguments

 I will post the shader once I have more time (if I can get it working).   Please do the same. .  It's a beauty.  Looks amazing after it has been running for a while... like sand dunes. Good luck!


Thanks so much for your extensive reply! Slowly learning, and your reply helps me a whole lot further in one go. :)

It's not doing what it should do exactly *yet*, though it is giving me a kind of reaction-diffusion-looking output!!

Some thing I'm wondering about is the buffer outputs for feedback like you're describing. I've tried with jit.gl.texture and jit.matrix @thru 1, but those keep giving me stack overflow errors... So I used the way I first put in with jit.gl.slab.

Will be tweaking a bit more... let me know your thoughts!

Thanks so much for your extensive reply! Slowly learning, and your reply helps me a whole lot further in one go. :)
It's not doing what it  should do exactly *yet*, though it is giving me a kind of reaction-diffusion-looking output!!

Some thing I'm wondering about is the buffer outputs for feedback like you're describing.  I've tried with jit.gl.texture and jit.matrix @thru 1, but those keep giving me stack overflow errors... So I used the way I first put in with jit.gl.slab.

Shaders to jit.gl.pix - How to deal with feedback? (iChannel0, etc.)