Hi @Number6 great..as you can imagine my tongue is hanging out a lot ;-)>

greetz @z22
I haven't a clue what I'm doing however...
I have been eliminating the 'varying' function
by applying the 'in' 'out' syntax elaborated in
https://gamedev.stackexchange.com/questions/29672/in-out-keywords-in-glsl
to RadialBlur2B.fsh
eg:
///////////////////////
//Original taked from "halloween" scene by totem(istripper)
//Adapted by z22
//tweeked to RadialBlur2Bxxx.fsh

uniform sampler2D texture0;
uniform sampler2D texture1;
uniform sampler2D texture2;

//varying vec4 gl_TexCoord[];
//varying vec4 gl_Color;
in vec4 TexCoord;
out vec4 vTexCoord;
in vec4 FragColor;
out vec4 Colsize;

//////////////////////etc.

I've done the eliminating of 'varying' also for a Combine3xxx.fsh and
ChromativAberation2xxx.fsh and it appears to work much the same as before.

This doesn't take into account all the issues @TheEmu cited about non compliance with
his intel GPU and not assigning a value to anything declared as a uniform.

Question: How does anyone temporarily disable the NVidia GPU so that their rig resorts to intel GPU only as per @TheEmu's situation.? It stands to reason, if members cannot temporarily do that, surely they will never know whether anything is working to GLSL rules or not. Problems shouldn't be fractal but they seem to beget each other lol.

Yeh , have gotten rid of the problems TheEmu told me about(i think) but now i have another problem,

I can't find the correct way of modifying a textures colour so i get a bias to the right on the red channel/texture because its using the colour cycle as x position as well as for red. Why it can do that in the first place is odd, If i can sort out that problem i should be able to get it working as intended again.

c0 = vec4(-((fm0)*ColSize), rbgT, rbgT, 0.1);
//fm's come from a modulated sine function. rgbT and ColSize are ease of use constants

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// offset texture buffers(not currently offsetting)

blur0 = c0 + texture2D(texture0, vec2(vTexCoord.x, vTexCoord.y));
the line above is the problem. its inputing fm0 into vtexcord.x and using it as a colour...( .y too but to a much lesser extent.)

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// combine buffers
gl_FragColor = mix (blur0, blur1, blur2); // addition layers removed for ease of reading.

So i can see what it's doing wrong now i just don't know how to fix it. doh!

Question: How does anyone temporarily disable the NVidia GPU so that their rig resorts to intel GPU only as per @TheEmu's situation.? It stands to reason, if members cannot temporarily do that, surely they will never know whether anything is working to GLSL rules or not. Problems shouldn't be fractal but they seem to beget each other lol.

It depends on your set up. Many PCs now have the grahpics card built in and not necessarily INTEL. If you do not have a separate graphics card then you can only work with the onboard one. Usually you woulld have to go into the BIOS to enable/disable the onboard graphics if you have a separate graphics card. Many people would not have this option if they only have the one GPU. Mine is permanently disabled as my lowly AMD/ATI is far better then the the onboard graphics.

I suspect that @ThEmu has a laptop similar to my work laptop. It has dual graphics cards (mine is INTEL or AMD). It auto switches between the two dependent on the application. For high graphics usage e.g. AutoCAD in my case, it automatically uses the AMD.

I haven't looked at mine too closely (It is only used at work) but I am guessing there is a way to ***** it to use only one of the graphics processors. I have a feeling that @TheEmu did this a while back when there were some problems with some of the stuff he had done. Apparently it worked OK on one of his GPU's but other people were having problems. When he tried it on his other GPU it also exhibited problems. Now I think he tries everything on both GPU's just to be certain.

nm.. fixed.

Right.. Fingers crossed..

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


Edit:- left one of the files out.. Corrected

Looks Good @Z22

Runs fine on my AMD/ATI and no errors reported in the vghd.log

Cool, hopefully The Emu can run it too.

@Z22

It also works with swings but initially it might be easier to do it as a separate scene.

Under the "Clip" declaration remove "top" from the "deny" line

Add new line

allow: top

In the framebuffer id: fb2, under "clipsprite" change the position to 0, -2160.

I can't see any errors in the vghd.log so it looks like this is OK.

PS
You could also combine the swing scene with the origiinal to give you both a swing and standing/pole in one scene. You will need to move the clip positions to the left and/or right to stop them clashing. Apologies if I'm teaching my grandma to suck eggs.

My Windows 10 allows me to select a default GPU to use when starting any executable or to start a program using a particular GPU. These choices are offered as a pop up menu when you right click on an executable as shown in the attached image. To run iStripper with specific GPU I therefore

1) Stop it if it is already running - using the Quit menu option from the iStripper Systray icon because closing the GUI window does not stop the program, only its user interface. Very occassionaly it has not stopped properly and I have had to ***** it using the Task Manager, but that hasn't happened to me for a long time.

2) Find the iStripper executable and right click on it to bring up the context menu, then navigate through the menu until you find and use the particular items show in the attached image. Confusingly, if you don't know the history, the executable is called vghd.exe and is found on my system in the following folder

C:\Users\X-Format\AppData\Local\vghd\bin

and should be in a similar location on yours.

I do not have time to look any further into Z22's shader problem at the moment. Maybe I can do so this evening, but I can not promise anything.

@TheEmu

@Z22 seems to have solved it. Version 5 of Acid Rain does not appear to be producing any errors in the vghd.log and therefore I would have thought it should now run on your INTEL GPU.

I will try the new version this evening.

@Z22

Don't bother with the in and out qualifiers for things declared at the start of fragment shaders. Fragment shaders can only have one output and this is the predefined variable gl_FragColor which, being predefined, does not need to be declared by you at all. Even if they could have other outputs there is absolutely nothing that could ever use these other outputs. Using "in" is redundant because it is the default and the only thing that can be a valid "out" is gl_FragColor. Things are different in vertex shaders, but we are only talking about fragment shaders here.

Everything else declared in a fragment shader but outside of its functions can only be either

1) inputs. which must be declared as either uniform or varying. Any input should have a value assigned to it by something that runs before the fragment shader otherwise it will just be zero.

2) Shader local variables which must not be declared as either uniform or varying. These will default to zero unless you assign them an initial value.

Note, every time that a fragment shader runs it gets a new set of these variables - if you give one a value it will NOT have that value in the next frame but will have been reinitialised.

If you try to import code from other sources please be aware that different systems will provide different sets of system specific uniform and varying global variables. You can rely on those begining with gl_ as those are specified by the GLSL language and must always be provided, everything else is system specific (such as the vUv variables that you have previously used). Within the iStripper system there are some of variables, such as u_Elapsed and u_WindowSize which are provided by Totem's code but if you are getting code from elsewhere that uses any uniform or varying variables other than the gl_ ones you will need to find out if iStripper provides any equivalents and if so what they are called.

Which version are you looking at?

If it's V5 then I'm not sure which in/outs you are talking about. It should be taking in 3 copies of the same texture, those 3 copies are modified in 6 different (position and colour for each 3) ways and then combined into one output texture. Is that not what i am doing?

Other than that, what specific commands(and in which .fsh) are you refering to? You have to be a bit more basic for me to get what you are saying. :/

@Number6, As i suspected the swinging girls do look quite trippy. I take it we cant have the equivelent of

If Clip Type = swing
pos = 0, -2160
else pos = 0, 2160
endif

in the .scn file
So we don't have to have 2 versions of the same scene.

@Z22

Unfortunately I don't think so.

Originally the only documentation for fullscreen scenes were the comments in the Totem Penthouse Multi-scene. Even now there is no official documentation but @Wyldanimal did creat a "tutorial" thread which explained many of the basics of creating scenes from just playing around with various values. Over time a number of people have added contributions to it.

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

Du bist nicht befugt dieses Thema zu sehen oder auf mit dem Thema verwandte Daten zuzugreifen

With regard to swing or any other clips you can of course combine them into a scene with other clips and have a multi-model scene as per the screencaps.

If you go back to the very beginning of this thread you will also find some early scenes by various authors and some tips/discussions/etc. The reason that the shared screens thread was started was because some of the early shared scenes here were getting "lost" in the discussion so this was turned into a discussion only thread.

Fixed a few more bugs and probobly created some new ones.
Added more comments.
Changes how i move the layers abit.

Acid Rain V6... The causer of headaches.

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

@Z22

You asked which version I was looking at when I suggested not bothering with the in and out qualifiers. It was not one of you version but it was something in the last post in this thread by EverthangForever which included

in vec4 TexCoord;
out vec4 vTexCoord;
in vec4 FragColor;
out vec4 Colsize;

I have to admit though that I was a little ***** and thought it was something that you had posted, however the advice still stands.

I have just downloaded versions 5 and 6.

I get no errors logged when trying to use the newer versions - 4, 5 and 6 - but I still just see a blank background behind the performer. I do not see any obvious reason for this. One possible explanation is that the large framebuffers used in the scene are exceeding some limit of my system (if it is that then I guess it is the total texture memory size supported by the Intel GPU, but that is no more than a guess), however at the moment I am not in a position to investigate in any detail and it might be a few days before I can devote any time to it.

In any case, I am impressed by the effects seen earlier scenes that did work on my system, so, @Z22, keep up the good work.

Ahh, i see. I've not come across that before so not thought to use it.

It's quite possible i am overloading your gpu with the fb's that large(16k is taking the piss really) I suppose you can reduce everything down to 1080p or lower if you short on vram.. I think some intelGPU's have a limit of 2048x2048 come to think of it.

I am currently trying to figure out how to get rid of the black line around the girls. I don't think i can use a discard for 0.0 as a lot of the girls are wearing black so i thought i could use a blurred alpha/mask somehow. I really dont like the hard edge they have when it comes to the acid type scenes.

@Z22 Superb outcome maestro ! Thanks lots for including great // comments.
Like @Emu says disregard the 'in' 'out', it relates more to vertex shader variables input use anyhow.
Ur vghd.log looks good 👍

@Z22 - I finaly ran your scenes with my NVIDIA GPU - they work when using that device.

I just made a quick and dirty change to the .scn file, for version 6. It almost made the scene work even when going back to the Intel GPU and the modified version works the same on both GPUs. I will have to leave soon so I do not have time to make properly thought out changes (though I know what I did wrong) but the experiment strongly suggests that the original version's framebuffers were just too big for the Intel GPU.

One observation - why do you feed the shaders with three copies of the same texture, why not just use one and change the shaders to use it three times?

@ET, cheers dood.

@TE,

Glad to hear you got it working(kinda)..

My thinking was... In the case of blur0 ect if i were to use 1 texture it would move it one way then the other then the other so negating the diffent motion inputs. But are blur0 ect actually just holding a bunch of offsets from the original texture rather than the texture itself?

Messing about with adding a negative b/w version of the girl to color versions. So many thing you can mess with in the BracketInsanity.fsh

This version is particularly hideous so i though i would share it...

The original aim was to remove all shading on the girls(which does partiall work if you remove a few things. The compose with unaltered girl in .scn and the last addition to the gl_FragColor in the BracketInsanity.fsh)

As for why...errr just cos.

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

@Z22

I now have AcidRain6 working corectly. I just had to reduce the framebuffer dimensions and things related to them by a factor of four (I made a mistake editing this morning which is why it didn't work then).

In RadialBlur2d.fsh you have

blur0 = texture2D(texture0, vec2(vTexCoord.x - ((fm0) * blurSize), vTexCoord.y - ((fm1) * blurSize)));
blur1 = texture2D(texture1, vec2(vTexCoord.x - ((fm2) * blurSize), vTexCoord.y - ((fm3) * blurSize)));
blur2 = texture2D(texture2, vec2(vTexCoord.x - ((fm4) * blurSize), vTexCoord.y - ((fm5) * blurSize)));

and in the .scn file you set it up so that texture0, texture1 and texture2 are the same thing, so this is equivalent to

blur0 = texture2D(texture0, vec2(vTexCoord.x - ((fm0) * blurSize), vTexCoord.y - ((fm1) * blurSize)));
blur1 = texture2D(texture0, vec2(vTexCoord.x - ((fm2) * blurSize), vTexCoord.y - ((fm3) * blurSize)));
blur2 = texture2D(texture0, vec2(vTexCoord.x - ((fm4) * blurSize), vTexCoord.y - ((fm5) * blurSize)));

and you only need to pass the texture into the shader once instead of three times. The shader does not, and can not, modify any of the textures passed to it, it only generates a new image that is a blurred copy of its inputs.

Cool, What were the sizes you changed to and are they the max an IntelGPU can support?

Yeh, I had a think about it and realised that it was just looking at the offset when it gets to gl_frag color rather than offsetting a framebuffer.



What i am trying to figure out now (before i went down the rabbit hole of todays TooManyBrackets) is...

I have made a b/w version of the girl but i want to discard all but the brightest parts so i can mess about with them before i add it to a clean girl.

nm, found it...

if (gl_FragColor.a < 0.5)

{
discard;
}

@Z22 - I have not yet tried to find what the maximum size that the Intel GPU can take, I will probably experiment a bit tomorrow.

By the way, your TooManyBrackets.fsh can be reduced to

uniform sampler2D texture0;
varying vec4 gl_TexCoord[];
void main ()
{
vec4 Value = texture2D ( texture0, gl_TexCoord[0].xy );
vec3 qq = vec3 ( Value.r + Value.g + Value.b ) * 0.3;
Value += vec4(-qq,Value.a) + 1.0;
gl_FragColor = Value * 0.075 / qq.rrrr;
}

which should be an exact equivalent but has fewer brackets. I got there by discarding two or three things that were never used and simplifying the expression without changing its value.

I think that the effect is quite appropriate for halloween.

@ET Did someone say oily skin...

WetLook v1

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

As it's discarding parts of the alpha i could blur it elsewhere, maybe pass the output from wetlook.fsh into the radial blur before combining it will work.

@TE Cool, now if i just knew what some of those things are doing...

What the smeg is qq? and qq.rrrr

@Z22

The GLSL shader languages allows a shorthand form of vector constructor when you want all of the components to be the same, for example vec3(1.0) is the same as vec3(1.0,1.0,1.0). In my code qq is therefore a three component vector each component of which is equal to ( Value.r + Value.g + Value.b ) * 0.3

The language also allows you to "swizzle" vectors, for example if you declare

vec3 A = vec3(0.1,0.2,0.3);

then A.rgb is just A, but A.gbr is the same as vec3(A.g,A.b.A.r), however you are not restricted to just permutations of the components, so A.gbg is the same as vec3(A.g,A.b,A.g).

Nor does the result of a swizzle have to be the same size as the source vector, thus A.rb is vec2(A.r,A.b).

My qq.rrrr is thus a four component vector each component of which is equal to qq.r.

It is also worth knowing that a swizzle operation on a GPU does not entail copying any data, so it is more efficient than creating a copy of a vector with the components in a different order.

I think i get it,

is r just the red component as it has already been lumped together with the g and b components to create the grayscale?

That only applies if the values are the same though, while i was testing i was messing with the relative values so i could see what was going on a bit easier. Eg:- at one point i had a shehulk dancing in pink knickers.

@Z22 - yes