Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

最後の投稿 - ページ#274

  掲示板

Z22
Joined in Aug 2017
1776 投稿

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

iStripperに関する全て
January 24, 2023, 5054 アンサー
having some trouble and maybe its a new bug
outp.rgb = texture2D(texture1, vec2(0.0, 0.0)).rgb;
should only return whatever texel is at 0,0 but instead it is behaving like vTexcoords.xy, even if
vec4 vTexCoord = gl_TexCoord[0];
is commented out of the shader.

I can work around it but this shouldnt happen, i have use dexplicit coords before and they worked fine. Maybe its just early and i have fubared something elsewhere

scene code
clip
{
id: Clip
allow: pole
}


texture
{
id: Feedback
size: 1920, 1080
source: Empty/
//this is what causes the undocumented feature.
//normal behaviour is to grab a random texture from the directory but if the directory is empty
//it grabs the last sprite in previous frames camera node regardless of opacity or position.
}

texture
{
id: ST01
size: 1920, 1080
source: StartingTex/
}

texture
{
id: ST02
size: 1920, 1080
source: StartingTex2/
}
////////////////////////////////////////////////////////////////////////////////
framebuffer
{
id: StaticBuffer
size: 1920, 1080
pos: 960, 540

sprite
{
source: Feedback
}
}


framebuffer
{
id: RandomNumber
size: 1920, 1080
pos: 960, 540

sprite
{
source: ST01, 0
source: ST02, 1
source: StaticBuffer, 2
shader: Rnd.fsh
}
}

///////////////////////////////////
camera
{
type: 2D
size: 1920, 1080
pos: 960, 540



sprite
{
pos: 0,0
source: RandomNumber
}



sprite
{
opacity: 0.0
source: RandomNumber
}

}
The use of 2 texture directories for the ST01, ST02 was an attempt to fix the problem (in case it was fighting)


Rnd.fsh code
#version 120

uniform sampler2D texture0; //random picture starting point 1
uniform sampler2D texture1; //random picture starting point 2
uniform sampler2D texture2; //static buffer
vec4 vTexCoord = gl_TexCoord[0];
vec3 outp;


void main(void)
{
//vec4 Pc1 = texture2D(texture0, vec2(0.0, 0.0));
//vec4 Rn = texture2D(texture2, vTexCoord.xy);

// if (Rn.r == 1.0 && Rn.g == 1.0 && Rn.b == 1.0 && Rn.a == 1.0)
// {
outp.rgb = texture2D(texture1, vec2(0.0, 0.0)).rgb;
// }


gl_FragColor = vec4(outp.rgb , 1.0);

}

when its all not commented out the vec2 for outp should vec2(Pc1.r, Pc1.g) which should give you an offset between 0-1 for th elookup, just to add some more randomness really.

All the textures and framebuffers can be set to size: 1,1 and it kinds fixes it. How random it is will depend on how many textures are in the ST directory(prob dont need two as it was just an attempted fix which doesnt work)


This works but is limited by the number of textures you have in the source for ST

clip
{
id: Clip
//deny: top
allow: pole
}


texture
{
id: Feedback //this is what causes the undocumented feature.
//normal behaviour is to grab a random texture from the directory but if the directory is empty
//it grabs the last sprite in last frames camera node
size: 1, 1
source: Empty/
}

texture
{
id: ST
source: StartingTex/
}
////////////////////////////////////////////////////////////////////////////////
framebuffer
{
id: StaticBuffer
size: 1, 1
sprite
{
source: Feedback
}
}


framebuffer
{
id: RandomNumber
size: 1, 1

sprite
{
source: ST, 0
source: StaticBuffer, 1
shader: Rnd.fsh
}
}

///////////////////////////////////
camera {

type: 2D
size: 1920, 1080
pos: 960, 540



sprite
{
pos: 0,0
scale: 1000,1000
source: RandomNumber
}



sprite
{
opacity:0.0
source: RandomNumber
}

}


#version 120

uniform sampler2D texture0; //random picture starting point 1
uniform sampler2D texture1; //random picture starting point 2

vec4 vTexCoord = gl_TexCoord[0];
uniform float u_Elapsed;

vec3 rgn (vec2 c)
{
vec4 Pc2 = texture2D(texture0, vec2(c.r,c.g));
return Pc2.rgb;
}


void main(void)
{
vec4 Pc1 = texture2D(texture0, vTexCoord.xy);
vec4 Rn = texture2D(texture1, vTexCoord.xy);

if (Rn.r == 1.0 && Rn.g == 1.0 && Rn.b == 1.0 && Rn.a == 1.0)
{
Rn.rgb = rgn(Pc1.rg);
}


gl_FragColor = vec4(Rn.rgb , 1.0);

}

somewhat messy but you should get the idea
TheEmu
Joined in Jul 2012
7424 投稿

Discussions for Scenes for Version 1.2.X Fullscreen Mode here

iStripperに関する全て
January 24, 2023, 5054 アンサー
Won't that change on every frame/pixel ?

Yes it will.

There is no easy solution available in iStripper other than one based on selecting a random texture from a folder of textures.

What is really needed for this sort of things is a "compute shader". The GLSL graphics pipe line comprises roughly the following series of "shader" stages executed in the following order

    Initialise
    Compute
    Geometry
    Vertex
    Fragment

where each acts on the output of the previous stage and handles it in increasing detail.

The .scn file is handled at the Initialise and Compute stages (Animate clauses need actions after the initialise stage) providing data that is then used to compute the scene's geometry. The scene is then divided into a set of triangles each with three vertexes and each triangle divided into pixels each of which is handled as a fragment.

iStripper allows us to provide our own shaders for the vertex and fragment stages, but only allows us to provide limited data inputs to the compute and geometry stages.

It would be nice if iStripper provided more standard data via uniform variables - such as the date, time of day and mouse position etc. For example I have a set of clocks I would like to use as screen savers and it would be nice if they showed the correct time.

Another thing I would really like to see (but which I doubt will ever be implemented) is to be able to do simple calculations in the .scn file - with these calculations having access to such data as the date and time and to a few functions like sin(), cos() and rand().

ADDENDUM:

I suppose you could use one of Z22's feedback buffers to cache a calculation. A shader could be used to generate a copy of this "cache" for use next time or to generate its value if that old value was 0.0. But this would be far from a simple solution.
Previous ページ#274