simplified Rnd.fsh

#version 120

uniform sampler2D texture0; //random picture starting point 1
uniform sampler2D texture1; //static buffer
vec4 vTexCoord = gl_TexCoord[0];
vec3 outp;


void main(void)
{
vec4 In = texture2D(texture0, vTexCoord.xy);
vec4 SB = texture2D(texture1, vTexCoord.xy);

if (SB.r == 1.0 && SB.g == 1.0 && SB.b == 1.0 && SB.a == 1.0)
{
outp.rgb = In.rgb;
}


gl_FragColor = vec4(outp.rgb , 1.0);

}

do what ever extra randomness you want inside the "if"

the "if" is there because the first frame of the static buffer is all white so it's easy to detect. Just dont use any pictures that are white at 0,0

@EverthangForever

I meant what I wrote, but your modification does usefully emphasise what I meant - which was that the time at which the files are read is at the start of the run rather than later. For all I know the files are read two or more times during initialisation, though this is unlikely (multi-pass processing of files used to be common when storage space was small - I well remember having to load the same deck of cards twice into a card reader twice to be read by the linker when building overlayed programs on an IBM 360).

oh yeh, that if needs an else

else
{
outp.rgb = SB.rgb;
}

Only if it is your Loop.
It is is joust at the top then it becomes static.

Call the function one time before entering the loop.

Assuming that the 2nd and 3rd of the following quotes are a sequence starting from the first

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)));
}

Won't that change on every frame/pixel ?

Only if it is your Loop.
It is is joust at the top then it becomes static.

Call the function one time before entering the loop.

Then my answer to "Won't that change..." is still "Yes it will".

iTime, and hence the result of calling rand() will certainly be different for each frame and can be different for each pixel in the frame. This depends on exactly what iTime represents - if it is truely the instantaneous elapsed time then it will be slightly different for different pixels, if it is the elapsed time atthe start of the frame then it will be different for each frame. This is true even if to initialise a "global" variable in the shader - these initial declarations get re-evaluated for every pixel.

As to "call the function before entering the loop" - what loop is that ? You would need to call it outside the loop that invokes the graphics processing for each frame and the only place that we can do that is in the scene file which has no facilities for doing such calculations.

If I am ***** and you were referring to something else than I am sorry.

@Z32

I tried to modify what you have said to get a visual return on screen using a folder of surface textures and another folder of greys shades that would generate the random numbers.

sprite
{
source: ST01, 0
source: ST02, 1
source: StaticBuffer, 2
shader: Rnd_01.fsh
}

When I try to ***** the shader to output the second input it seems to show the first insted:

#version 120

uniform sampler2D texture0; //Random Surfaces
uniform sampler2D texture1; //Random Greys
uniform sampler2D texture2; //static buffer
vec4 vTexCoord = gl_TexCoord[0];
vec3 outp;


void main(void)
{
//vec4 Pc1 = texture2D(texture0, vec2(0.0, 0.0));
//vec4 Rn = texture2D(texture2, vTexCoord.xy);

// if (Rn.r == 1.0 && Rn.g == 1.0 && Rn.b == 1.0 && Rn.a == 1.0)
// {
outp.rgb = texture2D(texture1, vec2(0.0, 0.0)).rgb;
// }


gl_FragColor = vec4(outp.rgb , 1.0);

}

Full code here:
https://drive.google.com/file/d/1AZMLZYDyp8VbDIcOh2m2P8wyJgcb5XqH/view?usp=share_link

Feel like I'm going around in circles 😟

Simple oversight

shader: Rnd_01.fsh

Should be

shader: Shaders/Rnd_01.fsh

Simple oversight

Aha ! 👍thanks

Made some progress at last. I found after too many hours of hacking stuff around that this:

uniform sampler2D texture0; //Random Surfaces
uniform sampler2D texture1; //Random Greys

needs to be "texture" and not "iChannel"

With that, I was able to use texture1 to create a random starting number BUT it has screwed up the texture on texture0 in the scene.

If you load up the attached scene...
http://bit.ly/3XVcSZC

You will find 2 versions adapted from ET431. In the RandomCave version, the "cave" that is shown is different every time i.e the random number is being generated but the textures are all messed up.

There's a second NonRandom version to see what the textures should look like but in this version the shape of the cave is always the same.

If anyone knows if/how I can fix these textures .... 👍

In the .fsh need to change your use of 'texture' to 'texture2D'

@EverthangForever
😕 Could you be a bit more explicit please ?

in the shader preamble use

vec4 texture2D_Fract(sampler2D sampler,vec2 P) {return texture2D(sampler,fract(P));}
vec4 texture2D_Fract(sampler2D sampler,vec2 P, float Bias) {return texture2D(sampler,fract(P),Bias);}
#define texture2D texture2D_Fract

and in the rest of the code replace all use of 'texture' with 'texture2D'
its an OpenGL thang

OMG ! It works

Thanks @Everthang - what a slog that was.

Just needed to add this:

#define texture2D texture2D_Fract

(Whatever that is)

Nice going 😊

Just needed to add this:

#define texture2D texture2D_Fract

(Whatever that is)

That is a pre-processor directive that defines a simple text macro substitution.

It causes any use of the name "texture2D" that is encountered later in the source fle to be replaced by "texture2D_Fract"

texture2D_Fract is a locally defined function that is used as a wrapper around the standard GLSL function "texture" that uses only the fractional parts of the position coordinates, P, passed to it to identify which point is being sampled.

The result of the standard GLSL function texture() is only defined when both coordinates are in the range 0.0 to 1.0 (actually I think the condition might be greater than or equal to 0.0 and less than 1.0 which would exclude 1.0 from the valid range). How the function behaves when fed values outside of this range is implementation dependant, some clamp the values so that any out of range value is treated as either 0,0 or 1.0 while others discard the integer part of the value and just use the fractional part. Using texture2D_Fract either directly or via texture2D macro ensures that the second of these variations is used. This means that "wrap around" semantics are used for out of range values.


Some history. The texture2D() function is an old, deprecated, part of the GLSL language having been superceded by the newer texture() function. By defining a macro near the start of the shader source file we can effectively replace all uses of the deprecated function with the newer function without having to edit the body of the shader. At the same time this macro also eliminates the ambiguity as to what happens if the function is passed an out of range value for the texel position (I can say this with certainty as I was the person who introduced this way of using macros to adapt shadertoy shaders for iStripper - for example on my system the texture() function clamps the position coordinates but quite a few of the shadertoy shaders assumed wrapping semantics)

Thanks @TheEmu

You should write us a book ! The notes on here and those you have left in many of your scenes are always very helpful.

@TheEmu has written a book in the best possible way. As commented shaders in his website
http://www.theemusnest.eu

Me again ;)

Has anyone written a shader that separates the model name from the scene name in the clipNameSprite ? Sure I saw one somewhere.

@Calgon , No need to write a shader..its all just a masking..
In FG024 I did it by deliberately positioning/hiding the part
of the name/title I did not want to see in each location

For scenes using shader backgrounds like in FG448 , same deal. You can just position
& render a small masking sprite ( like 'Torusadj' ) using the same shader
as the background uses , over the part of the name/title you don't want to see.

@Calgon - separating out the parts of the clipNameSprite would not be quite as simple as it sounds as some contain three lines of text while most have only two. The same holds for the use of a mask.

That is not to say that it would be difficult, only that it is a little bit more complicated than it might first appear. At the very least if you have something that seems to work you should test it with a Duo card's clipNameSprite.

Also, Totem have at least once changed the font used for clipNameSprites and if it changes again this might invalidate any method that currently works.

@EverthangForever

its all just a masking..

Yep 👍 Of course - and I used it extensively in the past. Except, just thinking.... my scene won't match as it now has a random element.

@TheEmu
Is it possible to calculate the size from the bottom up - if the bottom is consistent ?

Is it possible to calculate the size from the bottom up

If you specify a hotspot for the clipNameSprite (or anything else) then that is the point in the object that is put at the position specified by the accompanying pos: clause. The default hotSpot for clipNameSprites is 0.5,0.5 - i.e the centre of the sprite.

Specifying "hotspot: 0.5, 0.0" will put the hotspot in the middle of the object's base. Do this with a clipnameSprite and all the text will be above that point (assuming that you have not rotated it).

As with any other object in the scene you can either explicitly specify a size: clause or let it take its default size. But in either case you will not know just how much of the object you will have to cut off in order to hide the name of the card - but with a bit of trial and error it should not be difficult to find something that works (but be sure to test with Duo cards as well as the more common solo performer cards)

If, for example, you find that cutting off the bottom fifth of the clipNameSprite would work you might consider using "hotspot: 0.5,0.2" to place the hotspot at the top of the part you want to obscure, you can then position the clipNameSprite at the top of (but behind) the top of whatever you use to mask it.

Technically
you can use the same pos:
for both the Clipname Sprite, and the Mask
and just adjust the hotspot: values

This would give you course adjustment control

Then make fine adjustments a few pixels at a time by changing the pos: values.
You can use this as a reference for the hot spot.

https://www.istripper.com/customdata/forum/2014-04-28/1132923_1398646460.jpg

https://www.istripper.com/forum/thread/27410/2?post=428459

このトピックに関して見る事やデータへのアクセスは許可されていません。

Humm,
It's been quite a satisfying journey..
I went back to the beginning and re-read many of the posts.

it Started a little before this Post.. But this was the Beginning of the Scenes as we know them..

https://www.istripper.com/forum/thread/21580/1?post=342285

このトピックに関して見る事やデータへのアクセスは許可されていません。

I had dove in to the prior Screen Saver offerings and figured out how to customize
the existing offerings by making up my own set of assets and packaging them up.

When REX introduced this New Strip Club concept.
I didn't want to lose my Ability to customize the Screen Savers.

Totem not only accommodated my input, but went above what was previously possible.

https://www.istripper.com/forum/thread/21580/1?post=342379

このトピックに関して見る事やデータへのアクセスは許可されていません。

and the demo videos
https://www.deskbabes.net/files/stripclub/Demo-002-Desktop.m4v
https://www.deskbabes.net/files/stripclub/Demo2-Desktop.m4v

I've been doing custom Screen Savers for VG longer than I can remember...

https://www.istripper.com/forum/thread/21580/1?post=354832

このトピックに関して見る事やデータへのアクセスは許可されていません。

And the rest began here
The 1st Release of the NEW FullScreen Scenes

https://www.istripper.com/forum/thread/27389/1?post=427152

このトピックに関して見る事やデータへのアクセスは許可されていません。

Man, I couldn't wait to Dive in a Figure out how it all worked...
So I did, and I made my 1st Scenes and Made notes
and in a matter of hours I wrote a Tutorial
and then shared what I learned through trial and error

https://www.istripper.com/forum/thread/27410/1?post=427679

このトピックに関して見る事やデータへのアクセスは許可されていません。

Some Crazy suggestions: wish we got these...

https://www.istripper.com/forum/thread/27439/1?post=428220

このトピックに関して見る事やデータへのアクセスは許可されていません。

It's just nice to look back and see a community that creates and shares and inspires others...

Keep Creating, Keep Sharing, Keep Inspiring others to join the Journey!.

Awesome. 👍 😎

Is it possible to calculate the size from the bottom up

@TheEmu

I'm trying to use a shader because I need other features. The following code works for a non duo card but to make a version that works for a larger duo card name.... is there some way that I can get the shader to detect the size in pixels of the original clipname, with that information I could specify an alternative point at which to crop the name from the 0.63 specified below:

#version 120
uniform sampler2D texture0;
uniform sampler2D texture1;
uniform float u_Elapsed;
varying vec4 gl_TexCoord[];
//varying vec4 gl_TextureMatrix[];



float weight=0.14767;
// changes and additions by WyldAnimal of the totem occluding.fsh shader used
// here to make a static color clip name.


uniform float set_r; //
uniform float set_g; //
uniform float set_b; //

uniform float delay_time;

//uniform vec3 set_cols;



void main(void)

{
vec4 vTexCoord = gl_TexCoord[0];
vec4 occluding = texture2D(texture0, vec2(vTexCoord.x , vTexCoord.y )) ;
float save_alpha = occluding.a;
float fade_again = 4.;

if (u_Elapsed < delay_time ){
occluding.a = u_Elapsed - delay_time;
}

gl_FragColor = vec4(set_r,set_g,set_b,occluding.a);

if (vTexCoord.y > 0.63){
vec4 black = vec4 (0.);
gl_FragColor = black;
}

}

The uniform u_WindowSize gives you the size ofthe "window" in which you are working which for a clipNameSprite will be what you are looking for.

uniform vec2 u_WindowSize;

u_WindowSize.x will be the width,
u_WindowSize.y will be the height.

I think that is correct, for various reasons I can't actually check anything directly at the momemnt.

@VincentSnyder ..welcome Vincent..pls use the Scenes Discussion thread (here) for general questions..

Are there any scenes that play only table poses at a particular sittingHeight? Or only play standing/pole poses at a particular standingHeight? If not, how would I write a scene clause that does that? I know how to edit scene cards, and I've made a very basic black-screen scene of my own, but I don't know how to tell a scene to play table poses at x height.

Also, can a .scn file filter out cards to play, or do I have to use the disable features in iStripper to do that before I launch the scene?

@TheEmu said..

Yes, there are many such scenes. In fact almost every scene. There are relatively few scenes (though they are not rare) that allow both table and non-table clips for a particular place in the scene and, as far as I am aware every use of a clip has has an appropriate standingHeight or sittingHeight clause.

@VincentSnyder hi 😉
For each model clip in a .scn you can set what will play
(standing or sitting) using the allow or deny parameter
in each clip node. I tend to avoid using 'allow' as it seems
to be very specific to selecting clips for what you list after it.

Under the Clip: node..
Its a bit tricky because Totem only allow using certain terms
for this and neither 'sitting' or 'standing' are used.

Sitting uses 'table' which includes 'fronttable', 'behindtable'
unless you directly specify to deny use of these.

Standing is what remains after you apply..
deny: table, cage, top
and this includes using pole unless you include that in deny:

In the clipsprite node you can adjust the SittingHeight (in pixels)
&/or the StandingHeight

For SittingHeight I usually adjust the model size to accomodate
a taller model like Verena Maxima in kneeling pose

For a StandingHeight I usually adjust for her being in front of a pole.
Example:

clip {
id: Clip
//allow: table, pole
deny: top, inout, cage
nameGlowColor: 0, 1, 1
}

camera {
type: 3D
angle: 45
pos: 0, 0, 1272


clipSprite {
pos: 0, 205, 700
sittingHeight: 290
standingheight: 365
resolution: 20
scale: -1.0, 1.0
source: Clip
}
}