shadertoy sender and resolume – ffgl plugin limitations?

Home Forums Spout Support shadertoy sender and resolume – ffgl plugin limitations?

This topic contains 11 replies, has 2 voices, and was last updated by  leadedge 10 months, 1 week ago.

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
  • #3900


    Hello, i’ve been making plugins out of all my favorite shaders and getting some strange behavior. As i continued to load more plugins, previous ones wouldn’t show up anymore, for no apparent rhyme or reason. happens with both generators and effects. if i just try to load a few of the ones that weren’t showing up, without the rest, they load fine, again.

    i suppose i’m trying to load over 100 of em at this point,

    so for any other super users of shadertoy sender and resolume,

    Is there a limitation with the amount of plugins that resolume can handle/ load?

    i’m also getting strange behavior occasionally when switching between generators, again, no good reason, working plugins, all of a sudden creating glitches that affect all the other generators, and something i definitely wouldn’t want to see happen to my output at a show.

    I figure users here might have experienced this more than common resolume users or resolume support itself, although that would be my next step to try to get some greater stability,




    The reason for some not showing up any more is probably because of duplicate plugin ID’s.

    Freeframe plugins have a 16 character name and 4 character ID which must be unique for each plugin. ShaderToySender uses the first 16 characters of the shader name for the plugin name and the last 4 characters for the plugin ID. So shaders with names like like “Firstshader_sts” and Secondshader_sts” will have identical ID’s and only one will show up. Check the names to see if this is the problem.

    I am not sure what the glitching is caused by. It could be some OpenGL error, but then why would all the others be affected? Is ShaderToySender running at the same time?

    I assume that these are all source plugins. Are they all created with the same resolution?



    oh, thats great to know. i’ll definitely check into that.

    i have been exploring which resolution to export as, after exporting a bunch at 1920×1080 i started to realize that they only needed to be exported 640×480, to run in resolume in HD and greater resolutions. and i would only need to change that sizing if i wanted to spout greater resolutions from the sender.

    i have noticed that changing the comp size after the plugins are in a deck, causes strange resolution placement issues, basically fixed by setting comp size first and then re-loading them into the deck. the resize options like normal clips dont resize the shaders properly. i didn’t need to do this with shaderloader for res5, but i can certainly deal with that workaround.

    glitchiness happens without the sender being open. and some of the types of glitches are actually quite wild, but hard to pin down to one particular plugin getting caught in a particular function.

    I’ll try this on a different computer etc. to equally try to pin down what may be happening.

    thanks so much for your support, you rock!!



    Keep an eye on the fps that a shader achieves in ShaderToySender itself. At 1920×1080 you might find fps loss for some shaders. One way to assess the resolution to use is to set Vsync off and watch the fps when you change resolutions. If you get down close to 60fps, it’s time to reduce the resolution. A plugin will achieve a slightly lower fps. I expect that many shaders running at once would also tax Resolume and the overall framee rate would be affected, so you might need to set the resolution so that the fps is much higher than 60. I find that 1280×720 is a good compromise if the fps is maintained.

    I had not noticed the composition size change issue and will try to reproduce it. It’s good if you can work around it.

    I would like to reproduce the glitch you mention if you can find a repeatable setup.



    naming conventions definitely helped, too many clouds, tunnels, rings, pulse at the end of my names etc. šŸ™‚

    Good tips on how to figure out the fps load of a particular shader.

    Of course the work of a VJ has always been to fight the battle of fps vs. resolution. I remember in 1999 writing a program with nato.0+55 in Max/msp to be able to mix two 320×240 clips, and it was glorious. so the battle continues.

    So to be clear on the resolution parameter set in STS vs. how resolume plugins handle varying composition sizes:

    the STS resolution size only sets the spout rendersize which will be sent to a spout receiver such as Resolume,

    loading a plugin into a resolume deck will set the width and height to the composition size in Resolume, but can be adjusted using the width and height parameters to set a lower resolution for increased fps on the shader render, and then scaled using the transform, for increased FPS at the expense of lost resolution.

    i have noticed changing width and height parameters has some unexpected effects on positioning, but this can be adjusted using the position controls as necessary.

    (please correct me if im wrong or missing something)

    I will try to pin down some specific instances of glitchiness i have observed when switching between plugins, and using multiple at the same time (screen going white, portions of effects not going away, and screen strobing type glitches), although it may be a couple weeks before i can provide a repeatable setup.

    and again to be clear, at this time, the resolution saved by STS should not have any effect on the rendering of the STSplugin within resolume.




    There are two things happening when you set the resolution.

    The first is that it sets the resolution of the sender that is received in Resolume, but that has nothing to do with the plugin. The second is that this resolution is embedded in a section of the the plugin that it reads when it loads. That resolution is used by the shader of the plugin.

    The output of the shader is drawn to an “FBO”. The FBO (or actually the texture attached to it) is created the same size as the Resolume composition and the shader output is stretched out to fill it. Then that texture is rendered by Resolume.

    This way, the texture being rendered is always the same size as the Resolume composition, but the shader can be drawn into it at a different resolution. So setting a different resolution to the composition should not affect Resolume.

    There are several things that could cause the glitches but I have not been able to reproduce it. If you can create a repeatable setup it will help a great deal to track it down.



    OK I have found something.

    There is a little little diagonal arrow in the plugin clip panel. Hover over it and it says “[Maximize Video] – Scale the video to the size of the composition”. This is not working in the plugin. I can detect the change though and I am trying to figure out how to deal with it.

    Say we have a plugin set to a resolution of 640×360 and a composition size of 1920×1080. Start up the plugin and all is well. Change the composition size to 1280×720 and Apply. It enlarges as you would expect because it is rendering into a smaller viewport.

    Now look at the width and height of the clip. It is still set to 1920×1080 as it started. Change the width/height to 640 x 480 and you get a smaller image as you would expect.

    Now click the diagonal arrow to “scale the video to the size of the composition”. The size changes to 960×720, not the composition size of 1280×720. Click it again and the size changes to 1280×960. Click again and it changes to 1280×720.

    I can detect and reproduce this, but is it the behaviour you expect?



    thanks again for digging into this, Yes, the maximize button tries and fails to do what it should do, which is to try go through the typical options to resize clips( fit, fill, etc). unless it is already at the composition’s resolution, in which case it has nothing to do and does nothing.

    I don’t believe resolume has even made it fully functional with their generators, either, so it may be on their end, although it did behave okay with shaderloader in Res5

    I’m using 6.0.7 and even though i hear what you’re saying about the frame buffer object, i tried three different exports of different resolutions, and actually thought i was able to get the increased resolution with a low-resolution shader plugin- going from a 640×480 to a 3840×1080 resolution, which was my concern. Although it didn’t work when i changed the resolume composition size and just used the maximize button(various resize glitches ensued), reloading the plugin in the larger composition worked. Unlike the spout receiver from sts that just maximizes the video to fit the output screen, which is what i would expect from your explanation of it. i got the impression from exporting at three different sizes, that the resolution saved with the sts export was more of a default parameter and not a hard frame size.

    the results of this shader create a much different pattern when created at a wide resolution such as 3840×1080, so it was a good tester

    // Created by inigo quilez – iq/2013
    // License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

    vec2 iterate( in vec2 p, in vec4 t )
    return p – 0.05*cos(t.xz + p.x*p.y + cos(t.yw+1.5*3.1415927*p.yx)+p.yx*p.yx );

    void mainImage( out vec4 fragColor, in vec2 fragCoord )
    vec2 q = fragCoord.xy / iResolution.xy;
    vec2 p = -1.0 + 2.0*q;
    p.x *= iResolution.x/iResolution.y;
    p *= 1.5;

    vec4 t = 0.15*iGlobalTime*vec4( 1.0, -1.5, 1.2, -1.6 ) + vec4(0.0,2.0,3.0,1.0);

    vec2 z = p;
    vec3 s = vec3(0.0);
    for( int i=0; i<100; i++ )
    z = iterate( z, t );

    float d = dot( z-p, z-p );
    s.x += 1.0/(0.1+d);
    s.y += sin(atan( p.x-z.x, p.y-z.y ));
    s.z += exp(-0.2*d );
    s /= 100.0;

    vec3 col = 0.5 + 0.5*cos( vec3(0.0,0.4,0.8) + 2.5 + s.z*6.2831 );

    col *= 0.5 + 0.5*s.y;
    col *= s.x;
    col *= 0.94+0.06*sin(10.0*length(z));

    vec3 nor = normalize( vec3( dFdx(s.x), 0.02, dFdy(s.x) ) );
    float dif = dot( nor, vec3(0.7,0.1,0.7) );
    col -= 0.05*vec3(dif);

    col *= 0.3 + 0.7*pow( 16.0*q.x*q.y*(1.0-q.x)*(1.0-q.y), 0.2 );

    fragColor = vec4( col, 1.0 );



    OK thanks for this. It will give me something to work on. Meanwhile any resizing other that reload will not work properly because the plugin is not detecting the change.

    If you go from a low exported resolution to a higher composition resolution, the frame is simply stretched out to fit the larger size. You can use the largest exported size to meet the performance you need for that particular shader.



    The shader seems to work OK with the size change modifications. No distortion or glitches that I can detect. It should work on your end but needs testing. I have your email address from forum registration and will send you details for test download.



    awesome, i’ll try it soon,

    makes me wonder if resolume generators/sources plugins have another different way of handling increased resolution changes. or if effects handle resolutions more dynamically as well.

    i was going heavy on shaders at a show last night, no more than three or four at a time. individually plugins work fine, over the course of layering, triggering etc. I ran into the three most common glitches.

    (i didn’t have a good “control”, for real testing, but i suppose this is the way more users might experience these plugins, various export parameters etc.)

    background going white,
    overall frame size locking in the wrong position
    strobing glitches between two frames (almost like frame interlacing)

    these maintain no matter if you cut them all and try again

    i was able to control these glitches with this workaround

    FIX – cut all playing clips/plugins,
    – change to a different deck
    – go back to the original deck

    deck and plugins reload normally

    hope this helps someone



    Doesn’t sound good. I wish I could reproduce it. Anyway it sounds like reloading the plugins fixes it. The plugins will then get the new size information and adjust accordingly. So let’s see what happens with the test.

Viewing 12 posts - 1 through 12 (of 12 total)

You must be logged in to reply to this topic.