Many Scene's use a background Shader
and the Only real Difference from one scene to the Next is what Shader is used for the background.

If you create a set of shaders that all accept the same uniform values, or don't use any uniform inputs,
then is it possible to select the background shader at random, like we can with background textures?

I've tested many different syntaxes for the shader and have not found a way to do it.

So I decided to write my own utility that gets a list of all the shaders in the folder
and it picks one at random, and creates a New shader called Random.fsh by making a copy of the randomly selected shader.

In your Scene file you then just define the shader as Random.fsh

sprite {
source: solid
size: 1920, 1080
hotspot: 0.5, 0.5
pos: 0, 0, 0
shader: fragment, shaders/Random.fsh
}

Now the Random Shader app runs in the background every 5 seconds and changes the shader.
The Shader change is NOT dynamic, you won't see a Shader change Mid Scene
but each time the scene is restarted a new background is seen.

each time the scene is played, there is a random shader applied.
( because it is random, it is possible to get the same shader multiple times in a row )
But the more shaders placed in the folder, the more it will be different.

you have to Manually Start the Random Shader App
then minimize the app to the task bar.

One Scene file, Many different Shaders for the Background.

@Calgon

I was wondering if there is a way to create a random float in a shader that is different every time the shader is run.

you can create multiple copies of the same shader and make the random float calculation different in each one.

Save all the copies to the same folder.

I threw together a quick App to do the random shader copy
I made a demo Scene to show how it works.

Shaders provided in the demo
are copied from @EverthangForever Scene's

https://www.istripper.com/forum/thread/29408/82?post=756628

Tutto su iStripper / Share your FullScreen - Member Created Scenes here

Play the scene to see the random Solid Backgrounds To Experience the Random Shaders Open the Shaders Sub Folder and run the RandomShaders.exe app Minimize the app to let it run in the background. Note...

Brilliant !@Wyldanimal.. I posted a shortcut to RandomShaders.exe to my desktop ..
While RandomShaders.exe is running,..
the keyboard 'down' arrow key flips the shaders nicely too . Thanks Lots 😊

@WyldAnimal - thanks. That's one work-around. I may have another one coming as well.

Just wanted to confirm that out of all the Shadertoy inputs.....

uniform vec3 iResolution; // viewport resolution (in pixels)
uniform float iTime; // shader playback time (in seconds)
uniform float iTimeDelta; // render time (in seconds)
uniform float iFrameRate; // shader frame rate
uniform int iFrame; // shader playback frame
uniform float iChannelTime[4]; // channel playback time (in seconds)
uniform vec3 iChannelResolution[4]; // channel resolution (in pixels)
uniform vec4 iMouse; // mouse pixel coords. xy: current (if MLB down), zw: click
uniform samplerXX iChannel0..3; // input channel. XX = 2D/Cube
uniform vec4 iDate; // (year, month, day, time in seconds)
uniform float iSampleRate; // sound sample rate (i.e., 44100)

..... the only ones that we have on this platofrm are:

iTime
iResolution
iChannel0..3

@WyldAnimal - thanks. That's one work-around. I may have another one coming as well.

I shouldn't be coding at nearly 2:00 am but here's an alternative way to create a random number which could then be used in many ways to vary what happens in the rest of the shader.

This isn't a polished scene - just an example:

http://bit.ly/3XL6O5P

The clock in the scene should display a time between 0:00 and 1:40 seconds. i.e 0 to 100 with a random number each time you launch it - though I'm suspicious that some numbers come up more often than others.

If you Change the multiplier value you can get many more random times on the clock
You were using 100 as the multiplier
But if you change it to 525600
Also some changes so the date is also random
also Added the update on the seconds to count up.

void mainImage(out vec4 O, vec2 U)

{
// Calgon - Get a random number...
// Next 3 lines will generate an integer between 0 and 100 or thereabouts
vec4 myColor = texture(iChannel0, vec2 (0, 0));
float myNum = (myColor.r ) *31536000 + ((iTime * 6.)/8.);// count seconds
int myInt = int(myNum);

// We feed that to the clock and it gives a time of up to 1:40
int t = myInt;
ivec4 i = ivec4(0); // Convert everything to integers
// End of Calgon stuff

// Back to the clock display which will treat our random number as seconds
vec2 R = iResolution.xy;
U += U - R;
U /= R.y / 3.; // Global scaling with aspect ratio correction
O-=O; // Zero the pixel

// colon blink rate
float x = U.x - U.y * .2 - 2.8, // Slight skew to slant the digits
y = --U.y;
// changed to 60 = 1 second
i.w = int(iTime * 60.) % 100 // Replace with centiseconds

// Seconds (preceded by a colon)
Z(t % 60)
C

// Minutes (preceded by a colon)
Z(t % 60)
C

// Hours
Z(t)

// Smaller digits
x /= .6;
y /= .6;
R *= .6;

// Centiseconds
x -= 14.;
y += .53
Z(i.w)

// Day (preceded by a hyphen)
x -= .8;
y += 3.
// Z(i.z)
// H(1)
Z(t)
H(1)

// Month (preceded by a hyphen)
// Z((i.y + 1)) // Is it a bug in shadertoy that we have to add one?
// H(1)
Z((t)) // Is it a bug in shadertoy that we have to add one?
H(1)

// Year
// Z(i.x % 100)
// Z(i.x / 100)
Z(t % 100)
Z(t / 100)
}


/////////////////////////////////////////////////////////////////////////////////


void main ( void )
{
mainImage ( gl_FragColor, gl_FragCoord.xy );
}

@WA

If you Change the multiplier value you can get many more random times on the clock
You were using 100 as the multiplier
But if you change it to 525600

100 is the limit of random start points on this version, you've just taken that 100 and multiplied it into something bigger but there's still only 100 random start points.

Another day, another coding brick wall.

Is it possible to pass 2 texture files to a shader or are we limited to the one that is referenced when the shader is called ?

e.g:

texture {
id: Torus
source: Textures/Surfaces - 512x512/Wood - 01.jpg
}

sprite {
source: Torus
size: 1920, 1080
hotspot: 0.5, 0.5
pos: 0, 0, 0
shader: fragment, Shaders/AieKick/Frozen SwampMod01.fsh
}

This will end up with the texture "Wood - 01.jpg" on iChannel0 BUT what if I need a second texture is this possible ?

@Calgon
Not sure if this addresses your query..but it is about assigning
textures in the .scn before you get to rendering em with a shader.

In FG842 there are two separate textures declared in the .scn
These are assigned as separate framebuffers. Each of these are
rendered independently by the same shader.
In the camera node, a sprite node uses combine.fsh
to combine those two original textures via their numbered framebuffered forms.

I have not had any luck using combine.fsh in a framebuffer with 2 textures..
If I do, it all seems to be error free according to vghd.log but nothing
shows on my screen..Combine assignments only seem to work for me in
a sprite post-camera

@EverthangForever

Thanks I will have a look at it, I will see if the syntax you use here works for me:

sprite {
size: 1920, 1080
pos: 0, 0, 0
source: Sweet2, 0 // combine 0
source: Torus2, 1 // combine 1
shader: fragment, Shaders/Combine-Exclude/combine2.fsh
blend: false
}

@Calgon What are you trying to do? Are you inputing two textures and outputting one or do you want the same shader to do the operation on two textures and use both of them?

In the first case you can have 4 (think 4 is max) input textures that the shader can operate on and output a single texture. In the second case this is not possible on one sprite or framebuffer as they would both have the same id so you need two sprites with calls to the same shader.

The ways I have seen for getting random numbers for use in shaders are

1) Use a texture that consists of random noise, use the elapsed time to select a point within that texture and then either use the value of the corresponding pixel or some function of it as a random number. At first sight you might think that this would create the same sequence of values each time but there is enough variation in the "start-up" time for a scene to overcome this predicability.

2) Just use a complex function of the least significant digits of a high multiple of the elapsed time. Or of the fractional part of such a function.

3) Use something based on a random selection of a texture from a folder full of textures and name this foder rather than a specific texture in a Texture: statement in the .scn file.

4) Instead of a random image use a randomly selected clip as the source of the texture used by the shader. This way you can expand the selection of random textures to include your whole iStripper collection.

These all boil down to one of

1) Use a randomly selected image of some sort as your source of randomness

2) Use the least significant bits of the elapsed time as your source of randomness. The variability of a scene's startup times and timing jitter when running stop this being predictable.

Or you can combine them.

Then use a function to amplify that randomness. For use in iStripper scenes you do not need a high grade random number generator.

If you want to generate a whole series of random numbers for a single output image then you can use the pixel co-ordinates as inputs to the "randomness amplifier".

Thanks @ThEmu, I was hoping you would join the discussion

These all boil down to one of

1) Use a randomly selected image of some sort as your source of randomness

2) Use the least significant bits of the elapsed time as your source of randomness. The variability of a scene's startup times and timing jitter when running stop this being predictable.

In the digital clock scene I posted a few days ago http://bit.ly/3XL6O5P I already used 1) above. Having first set up 100 shades of grey that could be picked at random. I was very pleased with the result but of course this seems to have used up the one and only texture slot.

@Everthang mentioned that he uses framebuffers to get two separate textures into the shader e.g In FG842 so what I would like to understand how to do next... if possible is to convert that input which appears like this:

uniform sampler2D texture0;
uniform sampler2D texture1;
varying vec4 gl_TexCoord[];

...

highp vec4 zero = texture2D(texture0,vTexCoord.xy); // input zero 0
highp vec4 one = texture2D(texture1, vTexCoord.xy); // input one 1

... and further process that back into a format that a shadertoy shader would understand to be multiple textures that could then be used as normal.

highp vec4 zero = texture2D(texture0,vTexCoord.xy); // input zero 0
highp vec4 one = texture2D(texture1, vTexCoord.xy); // input one 1
... and further process that back into a format that a shadertoy shader would understand to be multiple textures that could then be used as normal.

highp is pointless for rgba 8 bit. highp is 16 bits per channel(i made this mistake ages ago). The output from the shader will always be in 8bit as we cant use even 10 or 12 bit hdr colour.


normal as in normal map? take a look at the lights and glass scenes, i create and use a normal map on the fly with them.

@TheEmu

2) Use the least significant bits of the elapsed time as your source of randomness. The variability of a scene's startup times and timing jitter when running stop this being predictable.

Tried to code that but it updates the random number throughout the time the shader is running. How can I get it to just calculate the number once, cache it, and be able to call it as needed ?

@Calgon

I am not sure what you mean by "How can I get it to just calculate the number once".

Do you want

One random value to be used througout the run of the scene.
A random value calculated separately for each frame with the same value used for each pixel
A random value calculated separately for each pixel with the same values used in each frame.

Some thoughts are

Use a vertex shader. Vertex shader outputs can be seen by subsequent fragment shaders as uniform variables.

Use a fragment shader to generate a tiny image in a framebuffer - the value of one (even the only) pixels in the image being the value you want to cache fr later use. Use the frame buffer as a source for a subsequent shader in a different node of the scene and extract the value you want from it.

You can use a variation of the second of these if you are already generating an intermediate image in a frame buffer as you can "sacrifice" a single pixel of this image to carry the information.


I also do not understand what you mean by

but of course this seems to have used up the one and only texture slot.

as you can have up to four textures acting as sources for a shader.

One random value to be used througout the run of the scene.

👍

@TheEmu - I know I'm probably being a *****. But this is not my original programming language and a lot of the concepts in it are new to me. In the past I've worked mainly in perl doing statistical things which are a lot simpler.

So what I'm trying to do is make interesting conversions of shaders and eventually my own. The one I'm working on at the moment is on Shadertoy here: https://www.shadertoy.com/view/cl23Wd

I've tweaked it so that each time you run it a random number based on iDate makes the shape of the cavern different:
Line 214 - 219

// Calgon - randomised start depending on time
float startSecs = iDate.w - iTime;
float randThing = sin(startSecs);

To bring that over to vghd I found we don't have iDate so I used 100 texture files to create a random number from the pixel shade.

...but this shader needs two textures as well.

So I'm really looking for a way to get 3 textures into the code OR 2 textures and a different method to create a random number that is constant "througout the run of the scene".

Once I understand how to do that, there are endless possibilities to tweak other shaders into novel designs that are different every time you run the scene.

There have been earlier posts in this thread, one of which you quote, telling you how to pass multiple texture to a shader. Namely using something like this in the .scn file

source: ImageA, 0 // Assign ImageA as the first source (Channel 0)
source: ImageB, 1 // Assign ImageB as the second source (Channel 1)
shader: fragment, TheShader.fsh

where ImageA and ImageB are the names used as the ids ifor two Texture nodes (or two frame buffers, or clips)

and in the .fsh file receive the two textures using something like

uniform sampler2D iChannel0;
uniform sampler2D iChannel1;

The names iChannel0 and iChannel1 can be replaced by anything you like.

In the scene file
you can pass up to 4 inputs which can be any combination of Textures, clips, or shaders
If you previously created a framebuffer using that shader.

source: ImageA, 0 // Assign ImageA as the first source (Channel 0)
source: ImageB, 1 // Assign ImageB as the second source (Channel 1)
source: ImageC 2 // Assign ImageB as the second source (Channel 2)
source: ImageD, 3 // Assign ImageB as the second source (Channel 3)
shader: fragment, TheShader.fsh

The Source Names are the ID name you use for your Texture, Clip, or Shader


Then in the Shader, you Use the Textures passed from the Scene

uniform sampler2D iChannel0;
uniform sampler2D iChannel1;
uniform sampler2D iChannel2;
uniform sampler2D iChannel3;

The Names iChannelN can be any Name you want to use for that particular input channel.

But it seems easy to just use the names as given in the Shader example to keep track of things.

Having first set up 100 shades of grey that could be picked at random. I was very pleased with the result but of course this seems to have used up the one and only texture slot.

You created 100 single Pixel textures.
Then used a swizzle to get just the Taxture.r value from it.
so that is what Limited you to 100 possible Start points.

Knowing that the Texture.r is a 3 digit decimal value from 0.001 to 1.0 ( or 1000 posible values )
A larger texture of random colored pixels and a Combination of all of the color values
(Texture.r * Textuer.g * Texture.b)
gives a possible 1,000,000,000 start points

But since our textures are limited to being 8 bit
the real limit is 16,777,216 random start points.
(256 * 256 * 256 ) = 16,777,216

If your Texture also contained random level of opacity ( the Alpha channel )
then you can extend the number to 4,294,967,296 random Start points.
(Texture.r * Textuer.g * Texture.b * Texture.a)
(256 * 256 * 256 * 256 ) = 4,294,967,296


go back and re-read this post from @Theemu

https://www.istripper.com/forum/thread/27449/147?post=756851

Tutto su iStripper / Discussions for Scenes for Version 1.2.X Fullscreen Mode here

The ways I have seen for getting random numbers for use in shaders are 1) Use a texture that consists of random noise, use the elapsed time to select a point within that texture and then either use th...

Hi @WA

I've been trying that but I think I must have a screw loose somewhere.

When I try to access a pixel color to then generate a random number I have accessed the pixel with this:

vec4 myColor = texture(iChannel0, vec2 (0, 0));

but if I try to do the same on any other iChannel than the first one it doesn't work.

In @Everthang's combine2.fsh the syntax is like this:

uniform sampler2D texture0;
uniform sampler2D texture1;
varying vec4 gl_TexCoord[];
...
highp vec4 zero = texture2D(texture0,vTexCoord.xy); // input zero 0
highp vec4 one = texture2D(texture1, vTexCoord.xy); // input one 1

If I follow @Everthang's syntax, what would be the right way to access a single pixel color from texture1 ??

But since our textures are limited to being 8 bit
the real limit is 16,777,216 random start points.
(256 * 256 * 256 ) = 16,777,216

Yes @WA I understand that but I'm never going to need more than 100

here is an example random number function

// random number
uniform sampler2D tex;

float rand(vec4 co) {
return fract(sin(dot(co.xyzw ,vec4(12.9898,78.233, 45.8438, 100.0)*fract(iTime))) * (43758.5453*fract(itime)));
}

vec4 effect(vec4 color, Image tex, vec2 tc, vec2 sc) {
vec4 textureColor = texture2D(tex, tc);
float randomValue = rand(textureColor);
return vec4(randomValue, randomValue, randomValue, 1.0);
}
#endif

// In this version, the rand function takes a vec4 as input, and uses the x, y, z, and w components (red, green, blue, and alpha) to generate a random number.
//The dot product is taken with a vec4 that includes the alpha channel as well.
//
// This way, the resulting random number will be different for each unique combination of red, green, blue, and alpha values in the texture,
//which means that the randomness will be influenced by the alpha channel as well.

@WA

here is an example random number function

Won't that change on every frame/pixel ? My objective was just to get one random number that is fixed until the scene is restarted.

Won't that change on every frame/pixel ?

Yes it will.

There is no easy solution available in iStripper other than one based on selecting a random texture from a folder of textures.

What is really needed for this sort of things is a "compute shader". The GLSL graphics pipe line comprises roughly the following series of "shader" stages executed in the following order

Initialise
Compute
Geometry
Vertex
Fragment

where each acts on the output of the previous stage and handles it in increasing detail.

The .scn file is handled at the Initialise and Compute stages (Animate clauses need actions after the initialise stage) providing data that is then used to compute the scene's geometry. The scene is then divided into a set of triangles each with three vertexes and each triangle divided into pixels each of which is handled as a fragment.

iStripper allows us to provide our own shaders for the vertex and fragment stages, but only allows us to provide limited data inputs to the compute and geometry stages.

It would be nice if iStripper provided more standard data via uniform variables - such as the date, time of day and mouse position etc. For example I have a set of clocks I would like to use as screen savers and it would be nice if they showed the correct time.

Another thing I would really like to see (but which I doubt will ever be implemented) is to be able to do simple calculations in the .scn file - with these calculations having access to such data as the date and time and to a few functions like sin(), cos() and rand().

ADDENDUM:

I suppose you could use one of Z22's feedback buffers to cache a calculation. A shader could be used to generate a copy of this "cache" for use next time or to generate its value if that old value was 0.0. But this would be far from a simple solution.

@Calgon

Use the static buffer hold the random number once created, the buffer can be one pixel but you cant use the alpha(its either 0 or 1) so you have >17 million values, you can doi a quick check to see if that pixel is uncoloured.

Give me a min an i will set it up for you

Another, but complex, solution would be to use an external program to generate either the .scn file or a shader.

An external program could be written in any programming language you choose and could do anything you want making use of any inputs you think may be useful. It could take the form of a preprocessor for .scn files. But you would need to run the program before starting the scene which would be inconvenient and greatly limit the usefulness of this approach.

You could, however arrange to have the program run on a regular schedule e.g. to generate a new version of its output .scn file every few seconds. As the .scn and shader files are (I hope) read one when the scene is run any output from the external program would have no effect on a running scene but would affect its next run.

@All

Thanks for your input

I think @Z22's buffer sounds like the best route, sounds similar to this:
https://stackoverflow.com/questions/68931433/where-to-store-cached-data-for-access-within-vertex-shader

I could write something to automatically generate new scn files like @WA did to switch the shader and create any uniform needed to pass into the shader but I was trying to create a self contained solution that wouldn't need a helper program.

The approach of using a random texture works fine but I can't seem to get the syntax right when the texture is not the first texture.

I still don't understand what this code is doing:

uniform sampler2D texture0;
uniform sampler2D texture1;
varying vec4 gl_TexCoord[];
...
highp vec4 zero = texture2D(texture0,vTexCoord.xy); // input zero 0
highp vec4 one = texture2D(texture1, vTexCoord.xy); // input one 1

and what comes next to access a pixel of data from texture1 😠

https://www.istripper.com/forum/thread/29408/78?post=756918

Tutto su iStripper / Share your FullScreen - Member Created Scenes here

FG853-FG863 Eleven selected WebGL shaders remixed & converted to OpenGL to run &/or remix on iStripper's Fullscreen OpenGL platform. Standing or table work randomly applies to all these scenes unless...

In the above post, I believe @TheEmu meant to say..

As the .scn and shader files are (I hope) read once when the scene is run, any output from the external program would have no effect on a running scene but would affect its next run.

@Calgon maybe leave a space before writing your 's apostrophes.. avoids too many 's 😉