@Z22

I use the 3D camera for two reasons

1) It automatically resizes clips (and other scene elements) that I want to appear to be at different distances from the camera making it easier to produce a scene that features girls at different distances. This only works if you have first matched the camera position, distance and view angle to the background and foreground elements, but if you do that then the result is well worth it - especially if you are moving clips about in the scene.

2) If you have scene with separate foreground, background and various middle ground elements then moving the camera (or zooming it by changing it angle of view) will cause these to apparently move relative to each other - i.e. there will be a visible parallax effect - which can greatly enhance the feeling of a there being a 3D scene even though it is just a set of 2D flats at different distances from the camera.

Note, there is little or no difference in efficiency in using a 2D or 3D scenes. In both cases there is a final stage that reduced to a mutlipliction of a matrix by a vector to do the projection onto the 2D surface of the screen. The difference being that in the 2D case the matrixand vector have some zeros in them that are not there in the 3D case. Furthermore, this projection matrix muliplication should, in any reasonable system have been combined with the other matrix multiplications required for scaling and rotations so it is essentlially free.

@TheEMU yeh, i can see the point with making paralax easy to do but for scenes that don't it just seems to ***** more people.

Is it still using the zbuffer when using the 2d camera? I thought it just slapped them down in script order to the back buffer overwriting anything that was there from previous (in the current frame) sprites. So it draws the entire background then overwrites it with a girl or some such?

@Z22 - I don't think that it is using the Z buffer even for a 3D camera, or if it is it is not using it in a way that is correlated to 3D space. Even in 3D scenes it just "slaps down" the scene elements in script order without taking any notice of their Z co-ordinates You can see this very easily by giving the "front" layer a Z co-ordinate that is further way from the camera than a "back" layer, or by defining two sprites that are angled such as to intersect each other in which case you will see all of the front sprite even though half of it has a Z co-ordinate that is further away from the camera than the sprite that it intersects.

The 3D camera not olny helps with parallax but also with getting perspective right which is important if you are moving things about in a scene (such as with my carousels), or are zooming in or out by animating the camera's angle of view (effectively changing its focal length) rather than moving it in and out, or want something to be at an angle to the view direction (such as the shadow of a performer on the floor she is dancing on)

Yeh, i see there are cases where the 3d camera is useful but for the vast majority of scenes (flat background with some girls overlayed) we see on here the 2d camera is fine. The 3d cam just seems to ***** people.

@TheEmu
Well, thanks for the additional explanation.
Perhaps I am just ***** up on the word "camera", expecting negative x to move "camera" to the left, when it is actally the "scene" which moves.
I can live with it I suppose! One has to.

@TheEmu
Thank you for your response in the other post. Very helpful :)

I tried to use the WhiteCatwalk scene in DrD = Fashion Show v1. It used to work, but it doens't work anymore. After I copied and pasted the folder into scene folder. It doen't show up in the app. Can anyone help me?

@LZH11 Have a look at the .scn files code to see that it is located only one directory level down from /scenes level & that the paths for textures in the code are correct

@Z22

https://www.istripper.com/forum/thread/29408/35?post=661876

Alles über iStripper / Share your FullScreen - Member Created Scenes here

https://drive.google.com/open?id=1rhUh0T1fqlD0Wa3-tKrkYmlmVM8FwluY Hue Glass Seems to look best with naked duo clips.

What I'm getting when I download & iSplay the .rar. is a lot of noise
The last time I saw such a diagonal ***** was when a path was wrong in the code.

Weird. the only path in there is to the empty dir (which should be empty).

I checked it with the files from the rar on my machine and it works.

What gpu are you using? maybe i have done something it doesn't like.

may be something specific to your directory rights or somesuch
or maybe its how you setup the rar :(
lets see if anyone else can install it & report it working

Maybe, but it's the same way i have done for all i released yesterday.

Most of it is code that works in those with some minimal changes. Just this one has 3 getnormal shaders and the refract. The glass ones used to work on yours before didn't they?

Noticed something which may or may not make a differance. open the GetNormalR .. G .. B files and change the first line

(#version 130) to #version 120

It looks like one or more of the shaders not compiling.
Im using NVIDIA GTX1050
what build of iStripper are you using 1.2.242 ?

yeh, 1.2.242

did you try the version thing?

Yes edited them to 120. No change..

what is the log file saying is the problem?

Its mainly repeatedly saying.. 'WARNING [QNetworkDiskCache: couldn't remove the cache file '

think thats just a normal istripper error. clear your log then try to run it

Have you got the 2gb ram version of the 1050? it may be a memory issue as there are a lot of 4k framebuffers.

clip {
id: Clip
//deny: top
deny: top, table, cage, pole, inout
}


texture
{
id: Feedback
size: 1920, 1080
source: empty/
}

////////////////////////////////////////////////////////////////////////////////


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

sprite
{
//scale: 1.002, 1.002
source: Feedback
}
}


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

clipSprite
{
pos: 0, 540
source: Clip
scale: -1.0, 1.0
standingHeight: 896
sittingHeight: 752
}

}

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

sprite
{
source: Girl, 0
source: FeedbackBuffer, 1
shader: Hue2.fsh
uniform: invert, float, 0.0 // 0.0 normal 1.0 inverted (Girl)
uniform: invert2, float, 1.0 // tend towards black or white ( feedback colour addition or subtraction )
uniform: speed, float, 0.00195 // rate of change
uniform: resdiv, float, 4.0 //size of sample area
}
}

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

sprite
{
source: Girl, 0
shader: GetNormalR.fsh
uniform: resmul, float, 1.0
}
}

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

sprite
{
source: Girl, 0
shader: GetNormalG.fsh
uniform: resmul, float, 1.0
}
}

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

sprite
{
source: Girl, 0
shader: GetNormalB.fsh
uniform: resmul, float, 1.0
}
}

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

sprite
{
source: Hue, 0
shader: Invert2.fsh
uniform: cycle, float, 1.0 //colour cycle 0.0 off 1.0 on
uniform: invert, float, 1.0 // 0.0 normal 1.0 inverted
}
}

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

sprite
{
source: Invert, 0
source: NormalR, 1
source: NormalG, 2
source: NormalB, 3
shader: Refraction.fsh
}
}

////////////////////////////////////////////////////////////////////////////////

camera {

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

sprite
{
source: Invert
}

sprite
{
pos: 0, 0
source: Refract
}

// Last sprite will be the input to the Feedbackbuffer next frame.

sprite
{
opacity: 0.0 // If only using for feedback you can set to 0.0.
source: Hue
}

}

1080p version

yes I have the 2gb version..thats possibly the problem.
I had to deactivate Hue2.fsh to see noise abate

source: FeedbackBuffer, 1
// shader: Hue2.fsh
uniform: invert, float, 0.0 // 0.0 normal 1.0 inverted (Girl)

could you try swapping it with the hue.fsh (original one from the other hue's) to see if it's the changes i made in hue2.fsh.

My gpu ram usage goes from 2gb(desktop) to >4gb (in scene) so ram limit could well be the problem.

I should refactor it into a supershader with functions rather than a bunch of frambuffers.

ahh thats better :)

source: FeedbackBuffer, 1
//shader: Hue2.fsh
shader: Hue.fsh
uniform: invert, float, 0.0 // 0.0 normal 1.0 inverted (Girl)

Hmm. that is odd.

the changes to hue2 are offset2 and how it modifies the position of F01. Maybe it doesn't like it because i'm messing with it in the cordinate vec2 rather than just the y of the offset.


as typing i think i see the problem

in hue2.fsh, change

vec4 F01 = texture2D ( texture1, vec2(vTexCoord.x, vTexCoord.y-Offset2) + Offset *vec2( xy01.x, xy01.y) ) ;

to

vec4 F01 = texture2D ( texture1, vec2(vTexCoord.x, vTexCoord.y-Offset2.y) + Offset *vec2( xy01.x, xy01.y) ) ;

hopefully it's just that i'm a spaz and not that the nvidia compler is being a git.

retried both strings separately in lieu of existing declaration of F01..in hue2.fsh
back to noise again..arrgh

did the 1080p version bork(noise) as well?