Well... my workaround worked... surprised how easy it was...

Probobly wont work on intel gpu's due to the width of the textures. divide all(maybe) sizes in shiny2.scn by 2 if you have problems.

https://drive.google.com/open?id=0B52wt5m78EmUQjBQSmVoY3A0c0k

Much more glassy like and have enabled sitting girls.

Still need to clean up the files a bit but i though you would like a look.

@Z22 - OK, now I see what you mean - and I don't understand it either. I have hardly used the ability to pass two textures to a shader and when I have tried I failed. I suspect that it is a bug, or an unimplemented feature, in the way the scene file is processed and just something that we will have to live with for now. It is noticable that the only places in any of Totem's scenes where more than one texture is passed to a shader it is in a Sprite node - maybe the software is taking no notice of the ,0 and ,1 specifiers when the Source clause is in a framebuffer node.

It's very weird, i wish they would document how the .scn works properly.

I noticed another oddity and that was that the result of a framebuffer was getting propagated back to it's source texture, which was causing me a headache all the way back with my first scn i posted here and the reason i moved the rotation to the shader. I would have thought that eg:- texture{ id: smeg source: blah blah } would be untouched but noooo.

I am posting the latest version(unposted in this thread) in the other thread, could you take a look at it for intel and post a working version in the same thread if you have to reduce the sizes.

Mwhahaahahahahahah

It can use animated backgrounds like the fire scene.

Have been messing about in the drip4.fsh and here are a few alternatives

//vec2 xy = (Girl.r + Girl.g + Girl.b)*0.016 ; //Original

vec2 xy = tan(Girl.r + Girl.g + Girl.b)*0.005 ; //More glassy

vec2 xy = -exp(Girl.r + Girl.g + Girl.b)*0.01 ; //More chrome

vec2 xy = sin(Girl.r + Girl.g + -Girl.b)*0.015 ; // Edge falloff/compression is to low for glass

vec2 xy = log(Girl.r + Girl.g + Girl.b)*0.02 ; // Close but has problems with dark colours


just comment out the existing line and replace with one of the lines from above.

@Z22 - to be strictly legal shader code, and hence portable, those should either all use

float xy = scalar-expression;

or should either be of the form

vec2 xy = vec2(scalar-expression);

or of the form

vec2 xy = func(vec2(scalar-expression));

Where scalar-expression is a simple expression that produces a single floating point value and func is any function that accepts a vec2 argument and returns a vec2 result - essentialy all of the simple functions can do this.

You can get away with using either a float or a vector for xy because GLSL supports adding a scalar to a vector (which is how xy is used later in your shader) but it does not allow assigning a scalar to a vector, or vice versa.

The drivers/compilers often are rather lax about various features of the GLSL language and, in effect, provide a few *****, superficialy attractive, extensions to that language. However, I regard this as being ***** in the long run - it is rather like the Microsoft specific extensions to HTML that resulted in many web sites only working if they were viewed with Internet Explorer (or else meant that those sites had to try to detect what browser was being usd and act differently to accomodate to the various browsers that it did support). Originally Microsoft almost certainly did this to lock people into using their browser but even they have now moved back towards being much more complient with the standard.

@Z22 - a couple of suggestions for you to play with

1) Instead of using Girl.r+Girl.g+Girl.b you could use length(Girl.rgb). Its not quite the same and will entail changing the value that you multiply by.

2) More generaly you could use dot(Girl.rgb,vec3(a,b,c)) where a, b and c are three constants, or better still use dot(Girl.rgb,abc) and declare const vec3 abc = vec3(a,b,c); at the start of your shader. The dot function forms the dot product of its two arguments, so the example here is equivalent to Girl.r*a + Girl.b*b + Girl.g*c

Doh! it's another one of those "i fixed that already" as per your post in the other thread but in a different version than i have been messing about with.

I suppose i should think about revisiting all the old versions and bring them up to date with what i have learn't so far so i don't keep posting incorect code.

I think i had used the vec2 in the first place because it kept ***** about swizzles when i used a float somewhere. But it was probably another part of the code causing it.

Trying to figure out how to use cross atm, Seems i have something wrong as they appear to be returning 0

// v0---v1---v2
// | \ | \ |
// v3---v4---v5
// | \ | \ |
// v6---v7---v8

vec3 v0 = (vTexCoord.x - xOff, vTexCoord.y - yOff, Gray.z);
vec3 v1 = (vTexCoord.x , vTexCoord.y - yOff, Gray.z);
vec3 v2 = (vTexCoord.x + xOff, vTexCoord.y - yOff, Gray.z);

vec3 v3 = (vTexCoord.x - xOff, vTexCoord.y , Gray.z);
vec3 v4 = (vTexCoord.x , vTexCoord.y , Gray.z);
vec3 v5 = (vTexCoord.x + xOff, vTexCoord.y , Gray.z);

vec3 v6 = (vTexCoord.x - xOff, vTexCoord.y + yOff, Gray.z);
vec3 v7 = (vTexCoord.x , vTexCoord.y + yOff, Gray.z);
vec3 v8 = (vTexCoord.x + xOff, vTexCoord.y + yOff, Gray.z);


vec3 cp0 = cross(v4 - v3, v4 - v0);
vec3 cp1 = cross(v4 - v7, v4 - v3);
vec3 cp2 = cross(v4 - v8, v4 - v7);
vec3 cp3 = cross(v4 - v5, v4 - v8);
vec3 cp4 = cross(v4 - v1, v4 - v5);
vec3 cp5 = cross(v4 - v0, v4 - v1);

If i plug in v4(ect) i get a non zero result so they're holding numbers, but if i plugin cp0(ect) i get fook all.

@Z22 - your expressions for v0 to v8 simplify to

//v0---v1---v2
// | \ | \ |
// v3---v4---v5
// | \ | \ |
// v6---v7---v8

vec3 v0 = vec3 ( vTexCoord.xy + vec2(-xOff,-yOff), Gray.z );
vec3 v1 = vec3 ( vTexCoord.xy + vec2( 0.0, -yOff), Gray.z );
vec3 v2 = vec3 ( vTexCoord.xy + vec2(+xOff,-yOff), Gray.z );

vec3 v3 = vec3 ( vTexCoord.xy + vec2(-xOff, 0.00), Gray.z );
vec3 v4 = vec3 ( vTexCoord.xy + vec2( 0.00, 0.00), Gray.z );
vec3 v5 = vec3 ( vTexCoord.xy + vec2(+xOff, 0.00), Gray.z );

vec3 v6 = vec3 ( vTexCoord.xy + vec2(-xOff, +yOff, Gray.z );
vec3 v7 = vec3 ( vTexCoord.xy + vec2( 0.00, +yOff, Gray.z );
vec3 v8 = vec3 ( vTexCoord.xy + vec2(+xOff, +yOff, Gray.z );

which makes it clear that in your expressions for cp0 to cp5 the vTexCoord dependancy disappears, as does Gray.z and the statements are equivalent to

vec3 cp0 = cross( vec3( xOff, 0.00, 0.00), vec3( xOff, yOff, 0.00) );
vec3 cp1 = cross( vec3( 0.00,-yOff, 0.00), vec3( xOff, 0.00, 0.00) );
vec3 cp2 = cross( vec3(-xOff,-yOff, 0.00), vec3( 0.00,-yOff, 0.00) );
vec3 cp3 = cross( vec3(-xOff, 0.00, 0.00), vec3(-xOff,-yOff, 0.00) );
vec3 cp4 = cross( vec3( 0.00, yOff, 0.00), vec3(-xOff, 0.00, 0.00) );
vec3 cp5 = cross( vec3( xOff, yoff, 0.00), vec3( 0.00, yOff, 0.00) );

which in turn are equivalent to

vec3 cp0 = vec3 ( 0.0, 0.0, xOff*yOff*cos45 );
vec3 cp1 = vec3 ( 0.0, 0.0,-xOff*yOff );
vec3 cp2 = vec3 ( 0.0, 0.0, xOff*yOff*cos45 );
vec3 cp3 = vec3 ( 0.0, 0.0, xOff*yOff*cos45 );
vec3 cp4 = vec3 ( 0.0, 0.0,-xOff*yOff );
vec3 cp5 = vec3 ( 0.0, 0.0, xOff*yOff*cos45 );

where cos45 is the cosine of 45 degrees. So you end up with just two distinct vectors with cp0, cp2, cp3 and cp5 aligned in the +Z direction having a length of cos45 while cp1 and cp3 are aligned in the -Z direction and have a length of 1.0. I doubt very much if this is what you were trying to do.

I left out some things for simplicity.

vec4 Girl = texture2D(texture0, vec2(vTexCoord.x, vTexCoord.y )) ;

vec3 Gray = (0.0, 0.0, (Girl.r + Girl.g + Girl.b);

vec2 xOff = (1.0 / u_WindowSize.x, 0.0); // I think thats the correct thing to referance.
vec2 yOff = (0.0, 1.0 / u_WindowSize.y);


so grey.z is the result of adding the rgb of the girl to make a grayscale.

X y off are generated to give me a 1 pixel offset. Well... that was the theory...

In the end i want the combined normals for all 9 points, which i haddnt got to yet as the cp's appear to be returning zero.

I had assumed Gray was something like that, but it doesn't matter how you get it. You set the Z component of all of your v vectors to the same value, and then you caclulate the inputs to each of your cross products as the difference between two of your v vectors, so the Z components of each of the inputs to the cross products are always zero. This means that in each case the cross product is acting on two vectors in the X,Y plane so the result is aligned along the Z axis. What you had written should always give 0.0 for the X and Y components of the cp vectors, but non-zero for the Z components - however because xOff and yOff are going to be rather small, less than 0.001 for typical image sizes, their product and hence the lengths of the cp vectors will be even smaller at less than 0.000001.

In my previous post i should have used sin45 not cos45 because the length of the result of a cross product is proportional to the sine of the angle between its inputs, not the cosine of that angle, but it makes no difference because for 45 degrees they are the same.

I see. Hmm. So how do i get the correct Gray.z value into there for each of the 9 vectors?

I had thought the offests(xOff, yOff) took care of that.

What it should be doing is sampling the colour(gray.z) at the offset .xy from the current .xy that gl_fragcolor is looking for(except v4).

Am i thinking of the flow right?

gl_fragColor wants the color of the pixel at vtexcoord.xy

Previously(in drip4.fsh) that was the color at vtexcord.xy plus the offsets fm1.xy+xy

Would something like...

vec4 Girl0 = texture2D(texture0, vec2(vTexCoord.x - xoff, vTexCoord.y -yoff)) ;// this assumes that i have got the xoff correct and it's 1 pixel different.

and the other 8 locations

then use get the gray for each girl

vec3 Gray0 = (0.0, 0.0, Girl0.r + Girl0.g + Girl0.b);

but fill in the x,y 0.0s with numbers large(min 0.0 max 3.0 in this case) enough to form the grid so it's not working with tiny numbers.

then do the cross?

vec4 Girl0 = texture2D(texture0, vec2(vTexCoord.xy + vec2(- xOff, - yOff ) )) ;

error C1068: too much data in type constructor]

i presume it doesn't like (-xoff, -yoff)

nm, changed xoff to a float.

so now i have

vec4 Girl0 = texture2D(texture0, vec2(vTexCoord.xy + vec2(- xOff, - yOff ) )) ;

vec3 Gray0 = (0.0, 0.0, (Girl0.r + Girl0.g + Girl0.b)); // left the 0.0 bits out fot the moment

which gives me the expected result out of Gray0... well it goes a funny colour, but if i devide the result by 3 its fine so...

@Z22 - yes - that it the right way to go.

The simplest way to get a 1 pixel offset in x and y is

vec2 Offset = 1.0 / u_WindowSize.xy;

which makes Offset.x equivalent to your xOff and Offset.y equivalent to your yOff.

You can then use

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

vec4 G3 = texture2D ( texture0, vTexCoord.xy + Offset*vec2(-1.0, 0.0) ) ;
vec4 G4 = texture2D ( texture0, vTexCoord.xy + Offset*vec2( 0.0, 0.0) ) ;
vec4 G5 = texture2D ( texture0, vTexCoord.xy + Offset*vec2( 1.0, 0.0) ) ;

vec4 G6 = texture2D ( texture0, vTexCoord.xy + Offset*vec2(-1.0, 1.0) ) ;
vec4 G7 = texture2D ( texture0, vTexCoord.xy + Offset*vec2( 0.0, 1.0) ) ;
vec4 G8 = texture2D ( texture0, vTexCoord.xy + Offset*vec2( 1.0, 1.0) ) ;

Strictly speaking the components of the second argument to texture2D should be in the range 0.0 to 1.0 with the result being undefined if this constraint is violated. Unfortunately it is one of those area where different GPUs and their drivers do thing differently.

My NVIDEA GPU just uses the fractional part of the vlaues of the components, so a value of 1.23 would be treated as if it were 0.23, whereas my Intel GPU clamps the values to the valid range, so 1.23 would be treated as 1.0.

It usualy makes little or no difference just resulting in an imperceptable difference in the final output when it is rendered, but sometimes it is important and you have to use one of the clamp or fract functions to ***** the effect you want. I doubt if you need to bother this time.

It should be fine as i had the whole routine inside an "if alpha > 0.0" so it doesn't bother doing every pixel, i just want it to use a bullshit normal map of the girl from her grayscale.

In theory that should give me a better refraction effect where the background image that is "projected" on the girl comes from directly behind and is reversed. The crappy way is just to -1,-1 the scale of the image in the .scn, it looks ok till they move away from the centre of the screen.

I keep forgetting i can do that with .xy(it's sometimes useful to keep them seperate) that and forgeting to put ; at the end of lines... that does make vg throw up a .log file which lists errors that don't normally result in a .log though. :D

I quite often get warning implicit cast blah to blah.

when i encounter those should i raise the lower vec to be the same as the higher one and fill in some ,0.0s so it has enough data?
and change a float to a vec if needed?

@Z22 - Sometimes you want to raise the dimensionality of the lower dimensioned vec or scalar, sometimes you want to reduce the higher dimensioned vec or be selective of which parts you are using. Sometimes you want to pad with 0.0, sometimes you want to duplicate values in a vec - and sometimes you want to rewrite it in a different way altogther. There is no general answer, you have to understand what you want and how it differs from what you wrote.

I think i may well be getting that wraping round you mentioned because my result has banding where the source is a smooth scale (1.23 becoming 0.23)

Can the cross cause that because the numbers before that come out correct on a calculator?


short version

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

vec3 Gray0 = (G0.x, G0.y, ((G0.r + G0.g + G0.b))-0.5);

vec3 cp0 = cross(Gray4, Gray1);

Getting closer...

Work in progress.

https://drive.google.com/open?id=0B52wt5m78EmUYWNqQ3RaWXVtS1k

Has too much noise(looks like mpg noise, especially noticable in dark areas or dark clothes) and i should add the other offsets in.


Edit:-
Looks like the noise was coming out of float y

fix:-

float y = ((cp7.b+cp3.b)*x)*0.5 ;

@Z22 - I am not sure what you are trying to calculate with your cross products, however I think that the problem that you are seeing with them is simply due to lack of precision when using 32 bit floating point numbers.

You are taking 9 samples from the input texture, but these are only 1 pixel apart and, for the most part, the colours in the input texture do not vary much between neighboring pixels. For each of the cross products the two vectors will therefore normally be almost identical, having almost the same magnitudes and be in almost parallel directions. The magnitude of the cross product will therefore be approximately equal to the square of the magnitude of either of the input vectors (and hence smaller than either) times the sine of an extremely small angle. As such they will all have very small magnitudes and each of their components will be very small. The only times that this will not be true is when there is a rapid change in colour. The noise you are seeing may simply be the result of rounding errors when calculating with small numbers - this would be most noticible in dark areas where the numbers are all small to start with so any rounding errors will be proportionaly larger.

Another possible source of noise is that your offsets are by one screen pixel - but this is not the same as one pixel in the image acting as the source of the texture so the texture2D function will have to perform some interpolation which will introduce more rounding errors. There is a way to get the resolution of the texture, but I will have to look it up and my GLSL documentation is currently not readily available being still all ***** following some major redecorating of my flat.

One of the problems is that the colour is in 0.0 to 1.0 and the vectors are in -1.0 to 1.0
how do i stretch a 0.0 to 1.0 into a -1.0 to 1.0?

The result i want out of it eventually is the normal of v4 . rotated into 2d to create a normalmap(not actually outputting the map, just using it on the fly).

like this is doing. ish...
https://cpetry.github.io/NormalMap-Online/

where the input is the greyscale girl.

Once i have a "correct" normal map i can use refract and do a better glass effect with different difusion of the r g b to get the chromatic aberation.

plus this will lead onto lots of other things....

doh....
color*2 - 1.0

should stretch the girls colour range into the same range as the vectors

I should be able to figure it out eventually....

@Z22 - If you want to get the (x,y) offsets corresponding to 1 pixel in the texture rather than 1 pixel in the window then you can do it using the textureSize function. You would need to do something like

vec2 Offset = vec2(1.0) / vec2 ( textureSize ( texture0, 0 ) );

which calculates the pixel size in texture coordinates.

textureSize actualy returns an ivec2, i.e. a two component integer vector, holding the number of pixels in each direction. This needs to be converted to a 2D floating point vector before dividing, hence the use of the vec2 constructors. If you just coded 1 / textureSize ( texture0, 0 ); integer division would be used and the result would be (0,0).

Also, I think I now know what you are trying to do with the cross poducts etc., but I am not yet clear as to how that relates to what you coded. Its too late (actualy its far too early in the morning) for me to do anything today, but I will think about it and let you know if I come up with anything.

ahh, so the u_windowsize isn't the same as the size of the texture( size: 7680, 2160 ) i am passing into it? Is u_window size my display size eg:- 3840, 2160?

There is also the problem with resulting the aspect ratio making the x,y so my cross sources have smaller y range than x. easy to fix though, just times the offset.y by the aspect ratio(1.777777777777778 for screen space 3.555555555555556 for texture space). i think...

Perhaps I should increase the magnitude of the offset before i use it as a vector in cross to but after i have fetched the pixel colour of the grayscale girl. That should help get higher magnitude numbers out of the cross. and match the magnitude of the colour range. I may just be overcomplicating it though.


The code for the cross product is truncated from what i had because i was trying to find the problem yesterday. Which we resolved. So my original cross may have been correct if incomplete(i needed to combine the results into one vec3)

surprisingly this didn't break it..

vec2 Go0 = vec2((G0.x - Offset.x)+(Offset.x * 60), (G0.y - Offset.y)+(Offset.y * 213.333338795));

thats meant to account for the magnitude difference between .xy and z and also fix the aspect ratio difference in .xy


then use that result for the vector source.

vec3 Gray0 = (Go0.x, Go0.y, ((G0.r + G0.g + G0.b)/3 *2 -1.0));
// /3 *2 -1.0 sould be dividing the result of rgb addition and move it into -1.0 to 1.0 space.

then use that result for the vector source.