@Z22

The problem arises because the same user defined "uniform" is used for all shaders - they are implemented (in the code processing the .scn files) as global variables and have the problems that always accompany shared global variables. If you change it for one instance it is changed for all of them.

Each instance of a shader will get its own copy of the global used by iStripper so at the GLSL level the uniforms are not global variables, but they will be in the layer above that (unlike gl_Color which, I think, is an output from a vertex shader whch selects it from gl_FrontColor and gl_BackColor).

@TheEmu ,
So I suppose we could use gl_FrontFacing as a replacement for gl_Color. I have not tried this as I have hardware problems at the moment.

if I run a shader with say equal to or less than #version 130 header and

gl_FragColor = vec4(cc) * gl_FrontFacing;

I get a compile (implicit cast) error however there appears to be no 'gl_FrontFacing is deprecated' error

2022-10-22T16:39:03[] WARNING[QOpenGLShader::compile(Fragment): 0(233) : error C7011: implicit cast from "bool" to "float"]
2022-10-22T16:39:03[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-22T16:39:03[] WARNING[#version 110

If I try to run

gl_FragColor = vec4(cc) * gl_FrontFacing;

with a #version header greater than 130 I get a 'gl_FragColor is deprecated' error
which to me looks way worse , so no joy either way there.

So, for the time being until this can be resolved, I may stick to just using #version 130 headers
and

gl_FragColor = vec4(cc) * gl_Color;

@theemu

my post does not use a user created uniform.
it uses the built in system Variables.

https://www.istripper.com/forum/thread/27449/137?post=750406

Tout sur iStripper / Discussions for Scenes for Version 1.2.X Fullscreen Mode here

Its a shame we cannot find a workaround for @TheEmu 's * gl_Color; reference to suit higher OpenGL versions. the Alph and Color is passed to the shader when the sampler2D texture is input. instead of...

but you are correct in one thing.

setting a variable to

vec4 RGBA0 = gl_TexCoord[0].rgba;

will not Vary with the scene animation,

but using

gl_TexCoord[0].rgba;

Will vary with the scene animation.

So as a shader creator, you just have to decide if it is important to allow the passed Color and Opacity to vary or not.

I discovered an error in my shader
caused by a misplaced cursor when I typed in a vec4

this casued the shader to Not run,
Once I fixed the errant vec4

I was able to find a better system variable to use as a replacement for gl_color.

this fully supports animations.

I will go back and edit my two prior posts to show the use of this new system variable

////////////////////////////////////////////////////////
vec4 RGBA0 = texture2D(texture0).rgba; // color and alpha of Texture0
vec3 RGB0 = texture2D(texture0).rgb; // color only of Texture0
float A0 = texture2D(texture0).a; // alpha only of Texture0
////////////////////////////////////////////////////////

Sorry for the bad information caused by an errant typo.
But It's all corrected.
Edit...

just tested on my other pc and it DOES NOT work with my Nvida GPU
so forget all of this...


turns out my intel cpu wasn't generating any errors,
but the shader wasn't even running.

I'll do more testing and let you all know what I find..

So I suppose we could use gl_FrontFacing as a replacement for gl_Color.

As @EverthangForever found I was completely wrong when making that suggestion. It serves me right for Googling for information at 5:00 in the morning and quickly making a post based on that information while in a hurry to leave home in order to catch a train.

@Wyldanimal

gl_TexCoord[0].rgba;

seems to me to be a very strange usage.

gl_TexCoord is an array of vec2 elements and its components would normally be accessed as gl_TexCoord[0].xy or gl_TexCoord[0].st etc.

@EverthangForever

Can you please try

gl_FragColor = vec4(cc) * gl_FrontColor;

i.e. try gl_FrontColor in place of gl_Color.

And if it compiles and runs is the result affected by a Color: or Opacity: clause in the .scn file.

@TheEmu
using a test edited version of Wicked isometryMod01.fsh by illus0r (FG700)
Sorry to say..No compile with either #version header for using gl_FrontColor in place of gl_Color

2022-10-23T06:42:25[] WARNING[QOpenGLShader::compile(Fragment): 0(234) : error C5052: gl_FrontColor is not accessible in this profile]
2022-10-23T06:42:25[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-23T06:42:25[] WARNING[#version 120
---------------------------------------------
2022-10-23T06:46:51[] WARNING[QOpenGLShader::compile(Fragment): 0(234) : warning C7533: global variable gl_FragColor is deprecated after version 120
0(234) : error C5052: gl_FrontColor is not accessible in this profile
0(234) : warning C7533: global variable gl_FrontColor is deprecated after version 120]
2022-10-23T06:46:51[] WARNING[*** Problematic Fragment shader source code ***]
2022-10-23T06:46:51[] WARNING[#version 330

gl_FrontColor + gl_BackColor are for vertex are they not? So are only used if you are using a frag with a vetex shader.

you need the line

gl_FrontColor = gl_Color

in the vertex shader
What are you guys trying to do?

@Z22

The problem arises because the same user defined "uniform" is used for all shaders - they are implemented (in the code processing the .scn files) as global variables and have the problems that always accompany shared global variables. If you change it for one instance it is changed for all of them.

Each instance of a shader will get its own copy of the global used by iStripper so at the GLSL level the uniforms are not global variables, but they will be in the layer above that (unlike gl_Color which, I think, is an output from a vertex shader whch selects it from gl_FrontColor and gl_BackColor).

framebuffer {
id: err
sprite{
source: dunno
Shader dont care.fsh
uniform: some cak, float, 0.1
}
}

framebuffer {
id: woo
sprite{
source: dunno
Shader dont care.fsh
uniform: some cak, float, 1.0
}
}

is valid and works as intended. Iv'e used multiple instances of shaders like this so it must just be weird with animate. so you should be able to animate(colour cycle ect) in shader with uniforms.

@Z22

Sure, that works as intended.

But if you omit "uniform: some cak, float, 1.0" from the second then it will be as if you had specified "uniform: some cak, float, 0.1" rather than "uniform: some cak, float, 0.0" (its default vaue) which is what you would get if you had omitted both of the uniform: causes.

Not much of a problem if you always fully define all inputs to each instance of a shader, but even then it complicates maintenance and incremental development both of .scn files and of shaders because changing something in one place may need to have a different modification made elsewhere.

As a simple case consider your example as a starting point. Now modify the shader to optionally use a second uniform which could properly default to a value of zero but which you want to have a non-zero value for one of your uses. You will have to specify the uniform in both of the scene nodes in which you use the shader. Not much of a problem for this simple case, but much more of a nuisance in complex scenes where the two instances may be hundreds of lines apart in the .scn file.

In complex scenes altering the order in which the nodes are declared can, and often does, affect the values of uniforms seen by the shaders unless every uniform used by each shader is explicitly declared in each node that the shader is used in. Some of my shaders use a significant number of uniforms to provide optional parameters and having to reset them after using one with a non-default value is a ***** - especially if I am only doing so for debugging purposes.

It also means that you can test two pieces of the .scn file in isolation, find that they both work as expected, but that when combined one of them is no longer producing the expected result.

The problems arise because in the code processing the ,scn file (not in the code running the shaders) there is effectively a global variable for the uniform. This means that local changes have ramifications outside their natural scope and need to be "corrected" somewhere else in the source.

Note, this also results in user defined uniforms behaving differently to system defined ones such as gl_Color. For the latter any changes made to them in the .scn file (via color: or Opactity: clauses) are local to the node in which the change is made.

Note also, for me all of this is no more than a nuisance. I know what the potential problems are and how to avoid them (and I can recognise them when I make a mistake). But for others, particularly those with little or no programming background, there can be real difficulties in understanding why changing one thing in a scene can have a large effect on something else that is apparently unconnected with it. This will be especially so if two different shaders, doing completely different things, just happen to have an input parameter provided by a uniform with the same name.

@TheEmu ahh i see. i have always left adding uniforms till after i have completed the shader which usually avoids the missing uniform problem as i copy paste the framebuffer code then adjust to suit.

https://www.istripper.com/forum/thread/29408/75?post=750653

Tout sur iStripper / Share your FullScreen - Member Created Scenes here

FG703-FG714 Twelve selected WebGL shaders converted to OpenGL to run &/or remix on iStripper's Fullscreen OpenGL platform Standing or floor work randomly applies to all scenes. https://scenes.virtuast...

The shaders in scenes >FG700 all use @WA 's .fsh construction style with the
void main (void) like a footer and @TheEmu 's addition of '* gl_Color;'
Although there are a few exceptions, I've resisted the temptation to render
the feature shaders here in framebuffers due to previous experience of more
model stuttering sometimes doing that. The conversions here are set to run as
OpenGL #version 130 or less, unless some workaround to this can be found.

Thanks @EverthangForever.

I see an improvement in the last scenes. Even the ones that use 100% of the CPU, and also with the 4K cards. 😊

Merci @EverthangForever.

Je vois une amélioration dans les dernières scènes. Même celles qui utilisent 100% du CPU, et aussi avec les cartes en 4K. 😊

Merci @ComteDracula c'est un très bon résultat à connaître.

Thanks @ComteDracula that is a really good result to know. 👍

@EverthangForever

All of the scenes run just fine. 👍 😎

Thanks @Socialhazard. Good to hear that 👍

https://www.istripper.com/forum/thread/29408/75?post=750896

Tout sur iStripper / Share your FullScreen - Member Created Scenes here

FG715-FG725 Eleven selected WebGL shaders converted to OpenGL to run &/or remix on iStripper's Fullscreen OpenGL platform Standing or floor work randomly applies to all scenes. https://scenes.virtuast...

Thanks a lot @EverthangForever.

A nice improvement in the scenes. They work well with all resolutions of the cards. 😊

I was wondering if some of the more problematic scenes before would benefit from being redone with the information that has been given lately by @TheEmu, @Wyldanimal and @Z22 among others, to see if they would perform better with the different cards resolutions?

Thanks again.


Merci beaucoup @EverthangForever.

Une belle amélioration au niveaux des scènes. Elles fonctionnent bien avec toutes les résolutions des cartes. 😊

Je me demandais si certaines certaines scènes plus problématiques auparavant, n'auraient pas avantage à être refaite avec les informations qui ont été données dernièrement par @TheEmu, @Wyldanimal et @Z22 entre autres, pour voir si elles auraient une meilleure performance avec les différentes résolutions de cartes ?

Encore merci.

Merci @ComteDracula, je pensais de la même façon.
Une sorte de comparaison existe déjà. FG717 est presque une réécriture de FG642
Nous ne pouvons qu'essayer de voir. Peut-être pourriez-vous me donner
une liste de une dizaine de scènes, que vous aimeriez voir réécrites
et je peux les poster à nouveau pour voir s'ils fonctionnent mieux
sur votre système. Nous pouvons l'appeler des mises à jour dans le zip

Thanks @ComteDracula , I was thinking the same way.
A comparison of sorts already exists. FG717 is almost a rewrite of FG642
We can only try and see. Perhaps you can give me a list of
a dozen or so scenes, that you would like to see re written
and I can post them up again to see if they work better
on your system. We can call it updates in the zip

I just edited the default whisper club multi screen file as it was putting the primary model off the monitor. That was easy and is done, but in doing so I realized that clips I would expect to work did not. I noticed the the deny in the script included table, which I removed as the clips I was expecting seem to be of that type. In so doing, some started playing and others not. For example, "Georgia, unforgettable in black" has a number of clips that are named "Table...", but even though I've edited the scn file to say:

deny: top, cage, pole // Existing types: table, behindtable, fronttable, pole, inout, cage, top.

if I run that sceen with only that card enabled, no clips play and a message is shown saying "No clip available for this scene". I presume I'm missing something, but can't for the life of me figure out what. Any help would be appreciated.

@yokomoto

I just edited ...etc

Check you have all levels of eroticism ticked

@EverthangForever Thanks, that did it. I was absolutely sure I had turned all that back on, whoops.

Also, any idea why the Bare Elegance one doesn't display names? The script looks right for it (and i double checked, names are set to show always).

I have one scene (from Totem ?) called Bare Elegance.scn
In this two girl scene the clipnamesprites are misplaced
Just change the pos of each clipnamesprite to the same
as their respective clipsprite pos in order to see it

//////////////////////////////// names
clipNameSprite {
pos: 855, 760 //pos: -100, -470, 20
scale: 0.5
hotspot: 0.5, 1
source: LeftGirl
}

clipNameSprite {
pos: 1620, 652 //pos: +670, -470, 20
scale: 0.5
hotspot: 0.5, 1
source: RightGirl
}

And that did it, ty.

@EverthangForever

I did a comparison between the FG642 and FG717 scenes, which you quoted above, which you say is almost a rewrite.

The FG717 scene works much better at all resolutions, including 4K, even though both use 100 % of my GPU.

For the comparison

The FG642 scene

FPS 34-40
99% FPS 29-32
Render Latency 68-80 ms
CPU 12 %
GPU 100 %


The FG717 scene

FPS 50-56
99% FPS 40-50
Render Latency 44-67 ms
CPU 7-18 %
GPU 100 %

So in the FG717 scene, there are more FPS and the Render Latency is lower in ms.

Hopefully this can help.


For the scenes to be improved I had already mentioned some of the more problematic ones before in my previous posts. I'll have to check again. Especially the ones that used 100% of my GPU.

I went to the Bare Elegance folder.

I also made the corrections in "Bare Elegance.scn", and the names now appear. I also had the scene "Bare Elegance 2.scn", which had the same problem and which I also corrected according to your instructions.

There is a scene "Bare Elegance Main Room Stage.scn", which does not seem to have a "clipNameSprite", so names appear. Is it possible to fix this too?

Thank you.



@EverthangForever

J'ai fait une comparaison entre les scènes FG642 et FG717, que vous avez cité plus haut, dont vous dites que c'est presqu'une réécriture.

La scène FG717 fonctionne beucoup mieux avec toutes les définitions, incluant le 4K, et ce même si les 2 utilisent 100% de mon GPU.

Pour la comparaison

La scène FG642

FPS 34-40
99% FPS 29-32
Render Latency 68-80 ms
CPU 12 %
GPU 100 %


La scène FG717

FPS 50-56
99% FPS 40-50
Render Latency 44-67 ms
CPU 7-18 %
GPU 100 %

Donc dans la scène FG717, il y a plus de FPS et le Render Latency est plus faible en ms.

En espérant que cela peut aider.


Pour les scènes à améliorer j'an avais déjà cité quelques une plus problématiques auparavant dans mes messages précédents. Il faudrait que je revvérifie. Surtout celles qui utilisaient 100 % de mon GPU.

J'ai été dans le dossier Bare Elegance.

J'ai fait aussi les corrections dans "Bare Elegance.scn", et les noms apparaissent maintenant. J'avais aussi la scène "Bare Elegance 2.scn", qui avait le même problème et qui j'ai corrigé également selon vos instructions.

Il y a une scène "Bare Elegance Main Room Stage.scn", qui ne semble pas avoir de "clipNameSprite", donc de noms qui apparaît. Est-il possible de régler cela aussi ?

Merci.

@ComteDracula
I struggled to keep placement of model names in
Bare Elegance Main Room Stage.scn in a way that they
remained at least aesthetic without names crossing over.

Here is a Mod that places the names as they arise
to the left of the screen. The depth order key is..
Red name -- closest model
Blue name -- mid depth model
Green name -- deepest model ( most distant model )

Copy & paste the below code to notepad and save as
Bare Elegance Main RoomN Stage3.scn

Paste the above .scn file you have made into your
scenes/Bare Elegance folder. Good Luck !😉

logo: multi/small_logo_bare_elegance.png
splash: multi/large_logo_bare_elegance.png
text: address.txt
// Modified to show model names @ ET
clip {
id: LeftGirl
deny: inout, top, table, accessories, cage, pole, glass
nameGlowColor: 1, 1, 1
}

clip {
id: SecondGirl
deny: inout, top, table, accessories, pole, cage, glass
nameGlowColor: 1, 1, 1
}

clip {
id: ThirdGirl
deny: inout, top, table, accessories, glass
nameGlowColor: 1, 1, 1
}

framebuffer {
id: Clip1A
source: LeftGirl
shader: antiAlias.fsh
nameGlowColor: 1, 0, 1
}

framebuffer {
id: Clip2A
source: ThirdGirl
shader: antiAlias.fsh
nameGlowColor: 1, 0, 1
}

framebuffer {
id: Clip3A
source: SecondGirl
shader: antiAlias.fsh
nameGlowColor: 1, 0, 1
}

framebuffer {
id: Clip4A
source: FrontGirl
shader: antiAlias.fsh
nameGlowColor: 1, 0, 1
}

framebuffer {
id: Clip5A
source: FrontGirlRight
shader: antiAlias.fsh
nameGlowColor: 1, 0, 1
}

texture {
id: back
source: multi/bare_elegance_fond_dark.png
}

texture {
id: MyMask
source: multi/bare_elegance_stagefront.png
}

texture {
id: MyMask2
source: multi/bare_elegance_fond_dark_stools.png
}

////////////// smoke
framebuffer {

id: smoke
size: 500, 500
quad {
size: 500, 500
hotspot: 0,0
shader: smoke.fsh
}
}

////////////// lights on the floor
framebuffer {
id: lights
size: 450, 550
quad {
size: 450, 350
hotspot: 0,0
shader: lights.fsh
}
}

camera {
type: 3D
angle: 15.5
pos: 0, 250, 4450
target: -450, 420, 0
ambient: 0.1,0.1,0.1
animate: 10 , Linear, easeInoutsine, angle, -1.5
animate: 20 , Pingpong, Inoutsine, pos, 600, -1200, 0
animate: 20 , Pingpong, easeInoutsine, target, 0, -1125, 0
animate: 25 , Pingpong, Inoutsine, target, 200, 0, 0

sprite {
size: 7700, 3700
rot: 0,0,0
source: back
blend: true
}

sprite {
scale: 25.9, 25.9
pos: -600, 2602
hotspot: 0.5, 0.5
source: lights
color: 0.,1.5.,1.0
animate: 10 , Pingpong, Inoutsine, rot, 0, 0, 0
animate: 10 , Pingpong, Inoutsine, pos, 800, -600, -550
blend: SRC_ALPHA,DST_ALPHA
}

sprite {
scale: 35.9, 25.9
pos: 1200, -702
rot: 0,0,0
hotspot: 0.5, 0.5
source: lights
color: 0,0,5.5
animate: 10 , Pingpong, Inoutsine, pos, 400, -200, -550
blend: SRC_ALPHA,DST_ALPHA
}

sprite {
scale: 45.9, 35.9
pos: 1200, -802
rot: 0,0,20
hotspot: 0.5, 0.5
source: lights
color: 0.,5.45,0.5
animate: 10 , Pingpong, Inoutsine, color, 0, 5.0, 00
animate: 10 , Pingpong, Inoutsine, pos, 1500, -2200, -550
blend: SRC_ALPHA,DST_ALPHA
}

//------------------------------ model shadow
//------------------------------ smoke left
//////////////////////////////// right girl

light { // will be blue Spot Light
pos: 1275, -545, -600
rot: 0, 0, 0 // rotate around Y 180 degrees. Flip Left to Right
ambient: 0.0, 1.0, 0.0
color: -5.0, -5.0, -5.0
blend: SRC_ALPHA,DST_ALPHA
animate: 5, PingPong, InOutSine, pos, 0, -500, 500 // motion in Z
}

//------------------------------ smoke right
sprite {
scale: 2.7,2.45
pos: 1220, 362
hotspot: 0.5, 0.5
source: smoke
color: 1.5,1.2,1.2
blend: SRC_ALPHA,DST_ALPHA
}
//////////////////////////////// foreground mask
//////////////////////////////// yellow lights

clipSprite {
hotspot: 0,0
pos: -255, 680
rot: 0, 180, -1
source: Clip2A //deepest model
standingHeight: 1515
sittingheight: 950
//----color: 0.1, 0.7, 0.1 //green
material: true
animate: 15, PingPong, InOutSine, rot, 0, 0, 2
}

clipSprite {
hotspot: 0,0
pos: -455, 740
rot: 0, 180, -1
source: Clip1A //mid depth model
standingHeight: 1615 //1610
sittingheight: 1050 //950
//----color: 0.0, 0.35, 0.9 //blue
material: true
animate: 30, PingPong, InOutSine, rot, 0, 0, 3
}


light { // will be blue Spot Light
pos: -105, 145, 600
rot: 0, 0, 0 // rotate around Y 180 degrees. Flip Left to Right
ambient: 0.0, 0.0, 5.5
color: -5.0, -5.0, -5.0
blend: SRC_ALPHA,DST_ALPHA
animate: 10, PingPong, InOutSine, pos, 0, 200, 500 // motion in Z
}

clipSprite {
hotspot: 0,0
pos: 355, 780
rot: 0, 180, -1
source: Clip3A //front model
standingHeight: 1715
sittingheight: 1060
//---color: 0.7, 0.2, 0.0 //orange
material: true
animate: 30, PingPong, InOutSine, rot, 0, 0, 3
}
clipNameSprite {
pos: -1055, 280
scale: 0.8, 0.8
hotspot: 0.5, 1
source: ThirdGirl //rear
animate: 20 , Pingpong, Inoutsine, pos, 0, -1200, 0
color: 0.1, 0.7, 0.1 //green
}

clipNameSprite {
pos: -1055, 440
scale: 0.8, 0.8
hotspot: 0.5, 1
source: LeftGirl //middle
color: 0.0, 0.35, 0.9 //blue
animate: 20 , Pingpong, Inoutsine, pos, 0, -1200, 0
}