Thanks , hmmm still not compiling it seems. I'm still using iS version 1.2.242
I will wait see if @Wyldanimal or @TheEmu can cast some light on what is going on.
Keep on coding guys ..👍😉

OK, and in addition to that I can say that i donwnloaded some scenes from @TheEmu as well and in my scene library of the Istripper Software they appear the same ( with white background) but when i play this scenes they work just fine. (For example: Bana Split and Ergometer Scenes).

THX so far @EverthangForever and @TheEmu and all the other creative people here for the great scenes you already created.


Cheers

J'ai le même problème également sur version 1.2.242 . Quoi qu'il en soit nous patienterons en vous remerciant @EverthangForever 😉
I have the same problem also on version 1.2.242. Anyway we will wait and thank you @EverthangForever 😉

FG 110 Possible error and location.

one final last try for FG110 with thanks to
@DAN070 @JupKowalski @Philours @ComteDracula
and all others who might benefit..

FG110
Example of layering two shaders
via alpha length coding on a
transparent rendered quad

https://scenes.virtuastripper.net/ET_FractalGarden110.zip

fingers crossed

Ha,ha Bravo, c'est gagné 👍👍 Ha, ha Bravo, it's won 👍👍

Hourra tu as fait ma journée 😉

Problème corrigé. Merci beaucoup @EverthangForever 😊

@JuppKowalski

OK, and in addition to that I can say that i donwnloaded some scenes from @TheEmu as well and in my scene library of the Istripper Software they appear the same ( with white background) but when i play this scenes they work just fine. (For example: Bana Split and Ergometer Scenes).

I often use a technique where the same image is used for both the foreground and the background of a scene. When I do this I have edited the image such that the pixels in the part that only appears in the backgound have an alpha channel value of 0.0 (i.e. transparent) whereas those that are part of the foreground are assigned an alpha channel value of 1.0 (opaque) while, for all pixels, the red, green and blue channels are left unchanged from their original values. When used for a background the sprites for such images use the "blend: false" option which tells the system to ignore the alpha channel values encoded in the image and treat them as having an alpha value of 1.0.

However, when generating the scene previews the program gets it wrong and instead of just setting the alpha component to 1.0 it seems to also set the red, green and blue components to 1.0 as well - so we see white pixels in the previews but properly coloured ones in the full sized versions.

However, when generating the scene previews the program gets it wrong and instead of just setting the alpha component to 1.0 it seems to also set the red, green and blue components to 1.0 as well - so we see white pixels in the previews but properly coloured ones in the full sized versions.

The scene FG110 before correction, had a white background both in the preview and in the real scene.

The scene FG110 before correction, had a white background both in the preview and in the real scene.

I know - but I was replying to @JuppKowalski and explaining why the scenes of mine he mentioned were OK when run but showed white areas in their previews, which had nothing to do with FG110's problem - which is why I addressed him and did not refer to FG110's problem at all.

In fact the two problems may be due to the same sort of coding error - a mismatch in the number of components between a value and what it is being assigned to with the compiler "helpfully" accepting the bad code - but if so they are in very different places. Or they may be due to very different types of error, I have no way of knowing.

Yes, it works for me now as well. FG 110 is fine now. Thank you very much @EverthangForever .

And thank you for your explaination as well, @TheEmu . Your Scenes all work pretty good, personally I do not care about the white backgrounds in the preview. But if you want me to test something feel free to ask. I´ll try then.


Cheers

Note For anyone who had a problem compiling the earlier parent scene
FG108P please note I have made some ***** code adjustment since,
that should fix any compile problems. (req. re-download)

Pour tous ceux qui ont eu un problème pour compiler la scène parentale précédente
FG108P s'il vous plaît noter que j'ai fait quelques ajustements de code mineurs depuis
cela devrait résoudre tous les problèmes de compilation.

https://scenes.virtuastripper.net/ET_FractalGarden108.zip

https://www.istripper.com/forum/thread/29408/65?post=719136

Wszystko o iStripper / Share your FullScreen - Member Created Scenes here

@EverthangForever Problem with FG114. I have a grey Background. Thank you !

@ComteDracula thanks for feedback. Both shaders are compiling ok on my rig..
My vghd.log is not showing any shader errors..
I cannot yet determine why this is not compiling on your PC.
We may need @DAN070 or another brilliant member here to come to the rescue

@ComteDracula merci pour vos commentaires. Mon vghd.log n'affiche aucune erreur de shader
Je ne peux pas encore déterminer pourquoi cela ne compile pas sur votre PC.
Nous aurons peut-être besoin de @DAN070 ou d'un autre membre brillant ici pour venir à la rescousse

Line 115 of the Deformation Shader.

data\Scenes\ET Scenes\Shaders\Inigo Quilez\Sine deformationMod01.fsh

p.x *= iResolution.xy/iResolution.y;

change it to this

p.xy *= iResolution.xy/iResolution.y;

Thanks @WA, updated that shader ..
Sine deformationMod01.fsh on the server. 👍

How do you find the error?
in your VGHD.log file it will list the error and what line of code the error took place.

this is what was reported in the vghd.log

2021-07-17T03:35:54[] WARNING[QOpenGLShader::compile(Fragment): ERROR: 4:115: 'assign' : cannot convert from '2-component vector of highp float' to 'highp float']

lets break the error into smaller pieces.

2021-07-17T03:35:54[] WARNING
[QOpenGLShader::compile(Fragment):
ERROR: 4:115:
'assign' : cannot convert from '2-component vector of highp float' to 'highp float']

the error is a 4, and it happened on line 115

the error description is
assign : cannot convert from '2-component vector of highp float' to 'highp float'

Note: Some GPU's will ignore this error and just swizzle the vectors to match

Here is the snippet of code around line 115
notice that p is assigned as a vec2 float on line 114
then on line 115 it is attempting to be converted to a vec1 float.
( we don't use vec1 as part of the language.
but I wrote that so you can see, converting from a 2 vector float to a single vector float )

vec2 p = -1.0 + 2.0 * q;
p.x *= iResolution.xy/iResolution.y;

Now there are several ways to fix the error, and you have to try them to see if it gives the desired results.

you could change line 115 to

p *= iResolution.xy/iResolution.y;

or

p *= iResolution.xy/iResolution.yx;

or

p.xy *= iResolution.xy/iResolution.y;

or

p.x *= iResolution.x/iResolution.y;

all of those will correct the vector conversion error
but not all of them will give the same results

in this case, all of the results are acceptable.

if you think of the Vec2 as TWO boxes
then p has TWO boxes that you must always put something in.

Also the results of a formula, must have a Box for each of it's results.

lets look at this example

vec2 p = -1.0 + 2.0 * q;
p.x *= iResolution.xy/iResolution.y;

the 1st line vec2 p =
this assigns TWO boxes to p

so p by itself needs to have TWO boxes filled.

in the second line p.x =
here we are using a swizzle to put something in JUST ONE of the BOXES, the BOX called x
But on the other side of the = the formula produces TWO results, So we need to have TWO boxes to hold the results.

this
iResolution.xy/iResolution.y

it is Taking the TWO boxes of iResolution.xy or BOX iResolution.x and BOX iResolution.y
and dividing them by the same box iResolution.y

is a shorter way of
doing this
(iResolution.x/iResolution.y , iResolution.y/iResolution.y)

the results is TWO boxes
but on the front side of the =
there was only ONE BOX to hold the results.

that is what is Meant by you can't convert from a Vec2 float ( 2 Boxes ) to a float (a single BOX)

the Number of BOXES on both sides of the = must be the same.



Now there are several ways to fix the error, and you have to try them to see if it gives the desired results.

you could change line 115 to

p *= iResolution.xy/iResolution.y;

the p alone has 2 BOXES and the formula produces a TWO BOX result.
or

p *= iResolution.xy/iResolution.yx;

again, both side have 2 BOXES
or

p.xy *= iResolution.xy/iResolution.y;

and Again, Both Sides have two BOXES
or

p.x *= iResolution.x/iResolution.y;

this one is different
both sides have only ONE BOX, but Both sides still have the same number of BOXES

a vec3 has 3 BOXES so both sides of the = must have 3 BOXES

a vec4 has 4 BOXES so both sides of the = must have 4 BOXES

The first, second, third, and fourth BOXES can be referred to by using the Swizzle letters
xyzw where x = BOX1, y=BOX2, z=BOX3, w=BOX4
rgba where r = BOX1, g=BOX2, b=BOX3, a=BOX4
stpq where s = BOX1, t=BOX2, p=BOX3, q=BOX4

you can jumble the order of the letter, but the letters are fixed to which BOX they represent.
x is always BOX 1
g is always BOX 2
z is always BOX 3

Some GPU's will ignore this error and just swizzle the vectors to match

@WA thank you so much for this explanation (above)

I noticed that if I delete my vghd.log , then quit iStripper and re-open it
to play one scene file, the newly generated vghd.log provides
a summary of fullscreen OpenGL dumps showing data specific to my graphics card.
including:

OPENGL GL_VENDOR: NVIDIA Corporation]
OPENGL GL_RENDERER: GeForce GT 730/PCIe/SSE2]
OPENGL GL_VERSION: 4.6.0 NVIDIA 462.30]
OPENGL GL_SHADING_LANGUAGE_VERSION: 4.60 NVIDIA]
OPENGL version: "4.6"]

OPENGL features: ("Multitexture", "Shaders", "Buffers", "Framebuffers", "BlendColor", "BlendEquation", "BlendEquationSeparate", "BlendFuncSeparate", "BlendSubtract", "CompressedTextures", "Multisample", "StencilSeparate", "NPOTTextures", "NPOTTextureRepeat", "FixedFunctionPipeline")]

OPENGL texture features: ("ImmutableStorage", "ImmutableMultisampleStorage", "TextureRectangle", "TextureArrays", "Texture3D", "TextureMultisample", "TextureBuffer", "TextureCubeMapArrays", "Swizzle", "StencilTexturing", "AnisotropicFiltering", "NPOTTextures", "NPOTTextureRepeat", "Texture1D")]

OPENGL texture units: 32]
OPENGL texture max size: 16384]

I noticed that within the 'texture features' includes "Swizzle"

Could lack of a "Swizzle" feature explain why some other members' rigs are not compiling some shaders
where the code "boxes" (so to speak) don't balance.. yet the shader on my graphics card still compiles ok
without reporting an 'ERROR' ?

Could lack of a "Swizzle" feature explain why some other members' rigs are not compiling some shaders
where the code "boxes" (so to speak) don't balance

No. The "swizzle" operation is a very basic feature of the GLSL shader language and will be supported in hardware by all GPUs (there may be some that did not, but if so the compiler has to generate extra code making them very slow, just as it has to if everything is done in software). The incusion of swizzle as a texture feature indicates that the hardware also has a feature that enables swizzling to be done directly when acessing texture memory but that is not relevant to the simple case under discussion.

The problem is that the compliers in some GPU drivers accept as valid statements that the published GLSL standard says are invalid and, instead of issuing an error message and rejecting the program, they try to be helpful by doing something that may or may not be what the programmer intended.

For example, if v2 and v3 are of type vec2 and vec3 respectively the statement

v2 = v3;

which being short for

v2.xy = v3.xyz;

should be rejected because you can't put three values into something that can only hold two. But some of the compliers treat the above as if it was

v2.xy = v3.xy;

similarly they accept v3 = v2, i.e.

v3.xyz = v2.xy;

as valid and just partially update the value of v3 leaving v3.z unchanged even though the language standard says otherwise.

This behaviour is never useful in new code as it hides bugs. All it ever does is save a few characters in a statement at the expense of making its meaning obscure. The only excuse for it is that the earliest compilers did it so the behaviour is kept so that old programs keep on working - but in that case it would be far better to at least issue a warning rather than silently accept what the language standard defines to be invalid code.

NB: FG98: a shader code typo has been corrected on server 24thJuly 2021
Omission occured in code of ..ET Scenes/Shaders/Maurogik/Night road v1mod.fsh
Edit da shader (as above) or just re-download zip & extract overwrite to ..scenes/

https://scenes.virtuastripper.net/ET_FractalGarden98.zip

Footnote: If 'Night road' shader mod already compiles, this might seem a tad pedantic, however
if you (like me:) are in the habit of using past scenes to build new ones, its important imho not to
carry over any lil gremlins into future work.

Certains sont heureux de pouvoir utiliser à nouveau cette belle scène plein écran pour modèles à petits seins 😊
Existe t'il une scène qui serait dédiée aux filles à forte poitrine? Cela serait également apprécié. Merci 😍

https://www.istripper.com/forum/thread/29408/65?post=719828

Wszystko o iStripper / Share your FullScreen - Member Created Scenes here

https://drive.google.com/uc?export=download&id=1hxBEjSUa-F56d_ghIIvelJKQ8S8l-8e6 After a long, pandemic-induced hiatus, in-person meetings of the Itty Bitty Titty Committee have resumed at last! Time...

Some are happy to be able to use this beautiful full screen scene for models with small tits again 😊

Is there a scene dedicated to busty girls? It would also be appreciated. Thank you 😍

https://www.istripper.com/forum/thread/29408/65?post=720399

Wszystko o iStripper / Share your FullScreen - Member Created Scenes here

FG118 Celebrating the return of the velvet swing with 0799 Freya Mayer - Burlesque Bunny in several top clips including RFN/shoeless. Trivial Remix of shadertoy.com fragment shader as background 'Infi...

I'm not sure why it is happening, I am still using iS version 1.2.242
and I have noticed certain background shaders
appear to be affecting clipsprite iterations, like the clipsprites
are losing frames. This even happens when mounting .fsh on quads.

I have tried reducing mounting textures from .png to smaller .jpg
I tried other things in the shader code eg: with FG117 's shader
in line 21 have reduced the interrupt threshhold and so forth. It all seems to
be to little avail. Could it be the number of colors in textures I have used..?
I will experiment some more. I only use paint.net , hence color profiles
might be all messed up..

Perhaps if @EricTotem is looking at fullscreen allocation of resources
at the moment, he might find a conflict in iStripper in the fullscreen
memory sharing with OpenGL there. It is worth experimenting some more
with how to reduce stuttering of models in fullscreen scenes

I have tried reducing mounting textures from .png to smaller .jpg

The file format (.png. jpg, etc.) should have no effect on the behaviour. The file will be read and converted from the compressed form used in the file to a simple array of (red, green, blue, opacity) pixel values stored in the GPU's texture memory at the resolution of the original file (unless the size is explicitly changed while it is being loaded) - the work to do this is only done when the file is first read unlike the animations or fragment shader outputs where the work has to be done on each frame. What might make a difference is the size of the image any rescaling to the screen size will need to be done on every frame - there is little point in using an overly high resolution image if all you are doing with it is sescling it down to a lower resolution 50 or so times a second. However GPUs (typically) have hardware to do this rescaling efficiently.

https://www.istripper.com/forum/thread/29408/65?post=719909

Wszystko o iStripper / Share your FullScreen - Member Created Scenes here

Really nice work with the commit-teases @sh42n81 👍 FG117 Remix of GLSLSandbox.com e#73500.4 specifically for pole work. Code is adjusted to smooth iterations. The cage-like theme is adapted here to pe...

Update added FG117A
re-download required..
https://scenes.virtuastripper.net/ET_FractalGarden117.zip
zip size 14.0 Kb
@WA @EricTotem et al
@TheEmu following your comments about animations above, & in
a quest to restore a better frame rate for the model, we made
experiments further with FG117 calling it FG117A

• eliminated animations of the clipsprite and camera,
• made common the resolutions of camera, quad & clipsprite, .. then
• reverted the Sandbox735004Mod01 shader to its 'original' GLSLSandbox e#73500.4 speed via

#define time u_Elapsed*(-1.0)

This looks to have corrected the stilted movements of the model, seen in the first shader mod version.

https://www.istripper.com/forum/thread/29408/66?post=720950

Wszystko o iStripper / Share your FullScreen - Member Created Scenes here

FG119 Trivial Remix of shadertoy.com 'Mountain Path by Shane' showing an opaque shader mounted on a quad. Da scene suits both sitting & standing clips. https://scenes.virtuastripper.net/ET_FractalGard...

@DAN070 My rig doesn't crash like yours, and I only get the usual Network 'error' garbage
which happens at each new iStripper login...however that 'error' usually does not stop the show
on a second running of a scene AFTER the login. They look like failed java scripts on initial fs play...

2021-08-05T09:34:19 fullscreen: [NodeAnimation::set] WARNING[Unknown repeat mode "0" for node ""]
2021-08-05T09:35:01 fullscreen: [FsNode::setNodeProperty] WARNING[Unknown node property "resolution"]
2021-08-05T09:35:09 network: [NetworkAccessManager::dumpReply] WARNING[POST "https://www.istripper.com/cdn-cgi/bm/cv/result?req_id=679bc59c5ce83e75"; "Unknown error" 204]

@EricTotem might know if the iS Player fullscreen is playing up atm.. FG119 is running fine at my end, still
on iS version 1.2.242

Problem with ET_FractalGarden119.zip.

White background.

Thank you.

Ok , I found the code problem..wait a moment please ...Done
Re-download of ET_FractalGarden119.zip is required...sorry guys
FG119 devrait fonctionner correctement maintenant
FG119 should work ok now 😐

https://scenes.virtuastripper.net/ET_FractalGarden119.zip

Désolé @EtF, sur ma version 1;2;242, j'ai toujours un fond blanc 😒Sorry @EtF, on my version 1; 2; 242, I still have a white background 😒
Retéléchargé à l'instant. Instantly re-downloaded.