@Z22 - you need to declare textureSize0 as I described in my post 10 hours ago (and you have to get the capitalisation correct).

ahh, i see now.

just though you were just saying about them using the uniform before not suggesting adding it along with the new bit.

@Z22 - exactly - the function textureSize is a 1.3 feature but the uniform variables textureSize0, textureSize1, etc. are not part of the GLSL standard, they are Totem's own uniform variables, just like u_WindowsSize;

Ahhh right, wondered why i couldn't find anything i could use in the glsl webpages, and didnt know that the window size one was theirs either. How many more have they got hidden away?

@Z22 - The only standard uniform variables begin with the reserved prefix "gl_", anything else is specific to the particular program (or one of its infrastructure components) that you are using, which in our case is iStripper.

right, i thought things like u_elapsed were just old versions of things like iTime.

There are a set of things, like u_elapsed or iTime that essentialy every implementation will provide, but the implementors are all free to chose their own names and definitions unless they have decided to stick to some common standard (such as WebGL). For example, although every implementation will almost certainly provide an elapsed time uniform it need not take the form of a float and it need not be in seconds. For the time any other choice would be very odd, but for some other things it neeed not be and for any pair of implementations it is likely that each will provide some information that is not available in any form in the other.

So, know of a better way of adding the results of those 8 cross' together? The way i tries makes the result far to small to be of use. Atm i am getting good edge detection from each of the cp0n ect cross' but it's drowning out the slopes

@Z22 - in what you posted you calculated cp0n to cp7n and then have

vec3 Fc0 = cross ( cp0n - cp1n, cp2n - cp3n );
vec3 Fc1 = cross ( cp2n - cp3n, cp6n - cp7n );

which looks odd because cp4n and cp5n are not used while cp2n and cp3n are each used twice.

Yeh, i caught that bug. i think half way through writing it i changed my mind, i was going to overlap and make 4 Fc's

Looks like the output z from cross is clamped to 1.0 so i have to do this i think.

vec3 cp0nR = cross(Gray4.xyz - Gray1.xyz, Gray4.xyz - Gray0.xyz);
vec3 cp0nG = cross(Gray4.yzx - Gray1.yzx, Gray4.yzx - Gray0.yzx);
vec3 cp0nB = cross(Gray4.zxy - Gray1.zxy, Gray4.zxy - Gray0.zxy);

vec3 combN0 = normalize(vec3( ((1+cp0nR.x)*0.5), ((1+cp0nG.x)*0.5), ((1+cp0nB.x)*0.5) ) );

unless there is a way or different version of cross that gives me a varing z

@Z22 - why do you think the output from cross has z clamped to 1.0? I have not tested it but according to the documentation the function returns just what you would expect, i.e.

cross ( A.xyz, B.xyz ) = vec3 ( A.y*B.z-A.z*B.y, A.z*B.x-A.x*B.z, A.x*B.y-A.y*B.x )

which is vec3 ( A.y*B.z, A.z*B.x, A.x*B.y ) - vec3 ( A.z*B.y, A.x*B.z, A.y*B.x )

which can be rewritten as A.yzx*B.zxy - A.zxy*B.yzx

so the z component is A.x*B.y - A.y*B.x

Also by clamp to 1.0 did you mean always had the value 1.0 or was limited to have 1.0 as a maximum value? I ask because there is a clamp function which limits an argument to a range, which is most commonly 0.0 to 1.0, but I think you just mean fixed at 1.0 which would imply that your input vectors as such that when projected onto the (X,Y) plane are most likely to be orthogonal unit vectors.

Closest i have got so far

@Z22 - A ***** observation. in your post you had

vec3 combN0 = normalize(vec3( ((1+cp0nR.x)*0.5), ((1+cp0nG.x)*0.5), ((1+cp0nB.x)*0.5) ) );

but as you are normalizing the vector the common facor of 0.5 has no effect so this is equivalent to

vec3 combN0 = normalize ( vec3 ( 1.0+cp0nR.x, 1.0+cp0nG.x, 1.0+cp0nB.x ) );

which can be rewritten as

vec3 combN0 = normalize ( 1.0 + vec3(cp0nR.x,cp0nG.x,cp0nB.x) );

which looks a little odd because I can't think what it means "physically" (though it's quite clear what it means mathematically). The oddness traces back to the terms (1+cp0nR.x)*0.5 etc. I think (2.0-cp0nR.x)*0.5 looks a bit more natural here as it can be interpreted as changing range from 0.0..1.0 to -1.0..1.0. Making this change would be equvalent to

vec3 combN0 = normalize ( 2.0 - vec3(cp0nR.x,cp0nG.x,cp0nB.x) );


Bt the way, you really should not use integer constants, like 1, where a floating point number is wanted. It is likely that this is the cause of many of the warnings that you have seen in the log file about automatic conversions to float and furthermore I have been told that the Mac version of the GLSL drivers treat this as an error so it has to be avoided if the shader is to be portable.

It's yet another example of an implementation of the GLSL language being a little less strict than it ought to be according to the language standard - which is convenient at first but can be a major ***** in the arse when you latter have to port something to a different system.

Getting the full rgb range now just need to make the edges less and the slope more...

Yeh, i was just trying things to see what worked and what didn't

Before release i now go through the log and eliminate as many of the casts as i can. but while i am trying things it's just easy not to get bogged down in those errors. As atm i am deleting the whole lines.

what i have now which give the above picture is
truncated so it all fits...


vec4 G0 = texture2D ( texture0, vTexCoord.xy + Offset*vec2(-1.0,-1.0) ) ;

float OffMul = (5000.0);// may need to change this back to seperate val for x and y

vec2 Go0 = vec2( (-1.0)+(Offset.x * OffMul), (-1.0)+(Offset.y * OffMul) );

float twat0 = ( ((2*G0.r)-1.0) + ((2*G0.g)-1.0) + ((2*G0.b)-1.0) )/3;// this was being a twat hence the name...

vec3 Gray0 = vec3(Go0.x, Go0.x, twat0 );// can be combined with other lines but is just as is for ease of reading

vec3 cp0nR = (cross(Gray4.xyz - Gray1.xyz, Gray4.xyz - Gray3.xyz));// can put log ,sin cos, or exp before cross for different effects
vec3 cp0nG = (cross(Gray4.yzx - Gray1.yzx, Gray4.yzx - Gray3.yzx));
vec3 cp0nB = (cross(Gray4.zxy - Gray1.zxy, Gray4.zxy - Gray3.zxy));

vec3 combN0 = vec3( ((1+cp0nR.x)*0.5), ((1+cp0nG.x)*0.5), ((1+cp0nB.x)*0.5) );

vec3 Out = vec3( (combN0.rgb) ) ;// so i can combine it with others, may not need to really


gl_FragColor = vec4(Out.r, Out.g, Out.b, 1.0);

Now that i have it working(ish) i may seperate the rgb channels so i am not loosing colour resolution when i divide the result of twat0, i have had it working with just the red channel so it's just adding more of the same code and combining the results, it may not be worth the hassel though.

@Z22 - Ignore what I said about not being able to think what

vec3 combN0 = normalize ( 1.0 + vec3(cp0nR.x,cp0nG.x,cp0nB.x) )

meant "physically". Its meaning came to me (a refraction) a few minutes ago just as I was about to leave for work.

that line is this now anyway...

vec3 combN0 = vec3( ((1+cp0nR.x)*0.5), ((1+cp0nG.x)*0.5), ((1+cp0nB.x)*0.5) );

have a good day..

Think there may be one or two bugs in how istripper handles framebuffers and textures in the .scn

Have posted a cut down version of the improved glass shader in the other thread.

I tried to eliminate all the casting errors but some just throw up more errors when i try to fix them or break the effect. It could do with adding in an alpha check so it only bothers with the pixels occupied by the girl instead of the whole texture. I might add a alpha discard for the original background before it comes into the glass4.fsh in case someone adds a background with an alpha but it's not like it laggs so meh...


Hit a wall with the normal shader as i need to do multiple scale checks(blur levels) and combine them but came up against the same problem with multiple copies of a buffer only working on one so would have to do it all in one shader.

Did find some other odd effects while messing about with the normal shader, one makes even "curvy" girls' muscles stand out. even tiny differences stood out, could see Sapphira's abs through her shirt. It's very grainy though but with a bit of messing it could prove interesting...

I had the usual trouble due to the Glass4 shader not being stricly GLSL complient.

You forgot the vec3 constructor for lines 32, 33 and 34 which should be

vec3 Gray1 = vec3 ( G1.x, G1.y, CastFix0 );
vec3 Gray3 = vec3 ( G3.x, G3.y, CastFix1 );
vec3 Gray4 = vec3 ( G4.x, G4.y, CastFix2 );

(although vec3 is the name of a type its use here is not as a "cast" (type conversion) but as a "constructor". It is a function that takes three arguments which is something more than just a type conversion. In any case what you had was (a,b,c) which is just a list of three simple expressions (not a vector) which are evaluted in sequence and with the final value being a scalar equal to the last of them.

In lines lines 44 and 45 the problem is that Offset is a two component vector so each of the expressions is also a 2 component vector which you then try to assign to a scaler. You needed to use Offset.x and Offset.y so the two lines should be

float x = ( ((2.0*combo.r)-1.0)+((2.0*combo.b)-1.0)*0.5 ) * (Offset.x*128.0);
float y = ( ((2.0*combo.b)-1.0)+((2.0*combo.g)-1.0)*0.5 ) * (Offset.y*128.0);

With these fixes everything works well and the result is beautiful.

thanks lots @Z22 & @TheEmu. Quick link to Share thread to get @Z22's final glass shader & @Number6's new work.

http://www.istripper.com/forum/thread/29408/18?post=557748

关于iStripper的一切 / Share your FullScreen - Member Created Scenes here

New version of my glass shader/scene Includes two versions, one for static backgrounds and one that can use animated backgrounds like the included fireplasma shader by totem. https://drive.google.com/...

@Z22 - I have a question about a comment in your latest Glass4 shader, the comment says

//Doing these seperatly ((2.0*g1.r)-1) breaks the mirroring.

What is this refering too? I can't see any reason why the three operations it seems to refer to have to be done seperately.

One very very ***** thing - near the start of the file you declare and initialise fm1 but you never refer to fm1 again. So, if only for the sake of neatness, you should delete that line.

Castfix is named that way because if i have the colours on the gray line it whinges about casts.

vec3 Gray1 = vec3(G1.x, G1.y, ( ( 2.0*((G1.r + G1.g + G1.b)*0.333)) -1.0);

ah., forgot to rename fm1 to ***** at the top, surprised that didn't break it, it used to whine if i didn't declate it up there, but i did just chop out a couple of pages...

as for the //Doing these seperatly

float CastFix0 = ( ((2*G1.r)-1.0) + ((2*G1.g)-1.0) + ((2*G1.b)-1.0) )/3;
float CastFix1 = ( ((2*G3.r)-1.0) + ((2*G3.g)-1.0) + ((2*G3.b)-1.0) )/3;
float CastFix2 = ( ((2*G4.r)-1.0) + ((2*G4.g)-1.0) + ((2*G4.b)-1.0) )/3;

Having them that way was part of my narrowing down what was going on in the normal map shader

While i was testing glass4, this way broke part of the effect, now it doesn't... odd.

@Z22 - Thanks. I was misunderstanding "seperately" to refer to doing each of the three "CastFix" calculations seperate from each other when you meant seperate from the "Grey" calculations. I do not know why you needed to seperate them from the Grey calculations, but doing so makes the shader easier to understand which is a very good reason to do so.

@Z22 - I made a ***** change to use the length function rather than the sum of components

float CastFix0 = 2.0*length(G1.rgb)*0.333 - 1.0;
float CastFix1 = 2.0*length(G3.rgb)*0.333 - 1.0;
float CastFix2 = 2.0*length(G4.rgb)*0.333 - 1.0;

I think that the final output looks slightly better with this - but you might think just the opposite.

Does length just add the rgb values together then? so (0.5, 0.25, 0.15) would equal 0.9?

Compare the two ways closely, you will see that your way has a biased distortortion down and left. mine does up/down left/right. Most noticable on the club scene(clothing dependant). My first glastastic shader did that, it's why i changed to this version.




This works on paper but doesn't give me the desired result..

int iMul = 2;

int Gi0 = (G0.r*256); // convert float to (0 - 255) range and discard the .0 .
int Gia0 = (Gi0/iMul)*iMul; // discard colour info by rounding error.
float Gf0 = (Gia0/256); // convert back to (0.0 - 1.0) range.

what have i done wrong and/or is there an easier way to remove colour resolution.

this should convert the range 0, 1, 2, 3, 4, 5 ,6... ect to 0, 0, 2, 2 ,4, 4, 6, 6 , 8, 8...ect
atm it seems to convert to 0 255 nothing inbetween(may be the normalmap routine borking it though).

<= dumbass

int Gi0 = (G0.r*256); // convert float to (0 - 255) range and discard the .0 .
float Gia0 = (Gi0/iMul)*iMul; // discard colour info by rounding error.
float Gf0 = (Gia0/256); // convert back to (0.0 - 1.0) range.

works.

do i need to say it like this though?

int Gi0 = float(G0.r*256);
float Gia0 = int(Gi0/iMul)*iMul;
float Gf0 = float(Gia0/256);

heheeh... Faceted look to the girls
/////////////////////////////
add this section


int iMul = 32;

int Gi1 = float(CastFix0*256);
float Gia1 = int(Gi1/iMul)*iMul;
float CastFix0M = float(Gia1/256);


int Gi2 = float(CastFix1*256);
float Gia2 = int(Gi2/iMul)*iMul;
float CastFix1M = float(Gia2/256);


int Gi3 = float(CastFix2*256);
float Gia3 = int(Gi3/iMul)*iMul;
float CastFix2M = float(Gia3/256);

////////////////////// change this section

vec3 Gray1 = vec3(G1.x, G1.y, CastFix0M );
vec3 Gray3 = vec3(G3.x, G3.y, CastFix1M );
vec3 Gray4 = vec3(G4.x, G4.y, CastFix2M );