Yep the glasses work fine playing movies in TriDef. Will let you know re iSfullscreen..when/if happens :-)

Can you run the player and set it going with a film so it triggers SBS then start the scene?

No it works well for any 2D movies into 3D however DDD doesn't work the way ur thinking. Nothing gets triggered for general use in TriDef. All the SBS and 2D-3D config is adjustable only in their TriDef player console on screen. Thats where it works and thats the only place it works. ~ I tried . When they do it for Games, they release their own branded overlays like a codec or whatever peculiar to each game, and you select it from their Ignition GUI to launch the game. So, no joy getting your iSFullscreen as SBS here with my rig at this stage unless I record them. We need someone (like @WA ?) with a generic 3D headset/120Hz TV system for SBS,. to pipe up and let us know what they can see in iSfullscreen.
I'll press on with Nvidia 3DTVPlay option, and see where it leads, however Nvidia specify minimum of GTX 760 series GPU and mine is a lowly 660Ti and TV is 100Hz not 120Hz, so probably a lot of peeps like me will need to upgrade their rigs before can play 3D that way here.

I will see how it looks when I get a chance to set it up again.
many things going on, so I've not had time to play...

I finally got round to properly working on a modified version of @Z22's twenty layer 3D shader. A zip file of a directory containing it and a set of basic scenes using it can be downloaded using the link

http://www.theemusnest.eu/scenes/Zips/=%20Z22+TE%20=%203D.zip

This version uses the same algorithm as Z22's shader but

a) I have optimised the use of ifs which are inefficient on GPUs because they prevent evaluating things in parallel.

b) I have generaly arranged things to maximise the available parallism

c) It does everything in one shader invokation rather than separately for the left and right eyes' images.

d) It is controllable via uniform: clauses in the scene file.

e) It is not limited to purely horizontal displacements of the images or slices.

f) It contains some debugging code that when enabled shows the contributions of individual slices.

Because of the optimisation this version of the shader runs smoothly on my system whereas the version it was based on slightly overloaded the GPU which caused a small slowdown.

The scenes just show a single clip with different scenes being provided for Cage, Glass, Pole, Standing, Table and Top clips. In each case there is a scene for cross eyed viewing and one for SBS capable equipment. I do not have an SBS system so I may have made a mistake there.

I have seen two problems.

Firstly the way I generate both images in a single shader means that if the girl moves too far left or right such that the two images overlap results in the intruding part of the image being dropped even if it only intrudes on a transparent background area. I think that I can improve on this without doubling the work done by the shader.

Secondly, if the overall shift beyween the top and bottom layer is larger than the default used in the shader then strange things happen - as you will see if you increase it to 30 or more (which you can do using a Max_Parallax uniform in the scene file - see comments in the shader for the exact syntax to use). I do not yet understand why this happens,

It is heavily commented both to describe how to use the various control parameters and how the shader itself works.

Fair few changes there.

Can you shorten the filenames as i am having trouble finding which is which(having to delete all others atm)

What is the purpose of the double numbers in " S_01 *= SLICE ( 0.90, 0.95 ); //" if that is too cut a band rather than just cull darker(as mine does with the alpha zeroing) could that be the source of some of the glitchyness i can see(mose evident on mouth and fingers)?

Reducing MAX_Paralax to 10 helps resolve that glitch, i get the same on mine if it's too high and linear, i changed mine to be a curve rather than linear and that fixed some of the glitchyness and allowed me to increase the maximum paralax to 15 pixels per eye. See previous post for my values.

The strange things happen "bug" is inherent to the way we are doing this. Basing the shift on the colour. a possible fix it is to do a posterize pass as i did for the prysmatic glass shader, but in this case only to be used for the layer offset not the content of the layer. Will give that a try in mine in a bit to see if it's worth it.

Posterization may fix the super small version too.

Edit:- hmm, the layering is kind of posterizing it anyway...hmm

It's cool how much you have managed to pack it down.
:D

Maybe if we were to smear the layer across rather than a clean paste it would hide the double image we get if the paralax is high. I think the reason why we get the double image is if the offset is larger than the width of the layer, if you see what i mean.
In areas where there is a sharp contrast that can mean that very different layers are ajacent.

The file names for the scene adhere to my standard naming system for scenes which worked well with the way scenes were listed in older versions of the program when it was called VGHD.

The names impose a heirarchy and a grouping so that I can find the scenes easily when using the iStripper GUI. I really need to be able to do that with a collection of 5358 currently active (and I have a lot more inactive ones). Or rather I could until the program stopped being called VGHD and completely changed the way the scenes are listed because it now has the habit of chopping off the end of the filenames.

However, for this set of scenes the filenames are short enough that the whole of each off them is visible in the GUI when the preview images are set to be at their maximum size. Feel free to shorten them, but if I do it myself I will "loose" them.

The two numbers used as arguments for the SLICE macro are the minimum and maximum brightness thresholds for the slice, If I only used one threshold then more than one of the S_nn's would end up with non-zero values and I would have to use a set of ifs to determine which S_nn to use for the output of the shader, by using the two thresholds I get at most one S_nn that has a non-zero value for any of its R,G,B or A components so I can simply add them all rather than using ifs to select one. Any selection using ifs would be slow because they would have to be executed in sequence whereas the way I do it everything proceeds in big blocks in which each of the 20 slices is acted on in parallel and can therfore run much faster.

I can see what is causing the "bug" with large parallax shifts - it occurs when the shift of one slice relative to its neighbours is more than one pixel - but as yet I do not understand why it has the effect it does.

Where did you get the values for you curve? You mentioned graphing something and reading off the values, do you have an equation for it?

Ahh... i had made them smaller so thats why it truncated the filename..

I kind of figured out what the double numbers were for after i posted...

Yeh, i remember that gpu's don't really like a bunch of if's, atm the moment thats how my brain thinks of it all though... But now you have posted your version i can start picking at it to see how you have done it, hopefuilly it will sink in and i can use the faster way in future.

Couldn't edit my previous post... I was adding that if we could resolve the high contrast causing a double image the whole thing would look better.

Yeah, it takes some time to get used to thinking in terms of expressing things so that they can run in parallel rather than a sequence of steps. it's not just ifs and the like but you need to try to avoid chains of actions where the result of one step is used as an input to another and instead break them down wherever possible into blocks of thinks that can be done in parallel.

I had realised that high contrasts cause problems - it is very obvious for cage clips - but as yet have given no serious thought about it other than avoiding the cages.

In your first response you said "Fair few changes there", which is true but nevertheless I got there by purely by progressive transformations of your original.

The only way i have thus far thought of it to smear the layer rather than clean paste it.

layer A offset 5
layer B offset 8

so layer B would be offset by 5 then smeared over by 3.

rather B offset by 6, 7 and 8. So it would be 3 layers rather than 1.

Thats only going to work for paralax greater than 20 though.

maybe a way of adding additional pixels if the layers have a high contrast

so layer 5(offset 6) and layer 9(offset 10) are 1 pixel appart in the original but when offset they will create a double image so add a pixel or 2 to the top layer between both colours. no idea how to do that though or to check if thats the case.

@Z22 -I woke up this morning understanding why the "bug" with large parallax shifts has the effect it does.

If a layer is shifted by more than one pixel relative to the "base" layer then this can move a fully transparent pixel into the image, but because I do not blend transparent pixels with whatever in in the slice below them this get seen as a black area. When the shift is less than a pixel then the texture2D function interpolates and can return a partially transparent pixel (which might explain your the grey fringe you had in some of your scenes) which is less of a problem and as I effectively treat such pixels as fully opaque all that would happen is loss of anti-aliasing within the image where it would be hardly noticeable anyway.

Unfortunately my ***** brain did not provide a way round the problem that does not entail using some purely sequential code (a block of ifs) so I will think about it a bit more before doing anything to avoid the problem in the hope that I can come up with something more efficient. I also have to go back to work tomorrow so it may be a few days before I can get back to implementing anything.

Making the shifts non-linear as you have done would reduce the problem because the slices near the bottom of the stack would be shifted less than those further up the stack and it is only the bottom layer or two that are likely to shift in a transparent pixel because they are the only ones that include anything near the edge of the image.

@Theemu, while we are eagerly waiting for these solution/s.....
Made some slight changes to my last mods ET_FractalGarden026.zip
~incl.the overlooked clipnamesprites
~FG007 changed the camera target to lower, as legs were looking too large
~FG026 adjusted opacity of logo (green on greenish was poor contrast).

http://www.istripper.com/forum/thread/29408/21?post=566660

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

Jan 07 Time to once more get ~ up and close and personal ~ ..Woohoo.!! Incl. update/repl. of FractalGarden007.scn easings and masking reflections. Also a .scn of maybe how Totem could help centering t...

Yeh, that sounds like what i was thinking and trying to explain in the posts above, kind of. But it looks to be more of a non concurent layer problem. It only happens where there is a sharp transition in brightness and as such there are layers between that have no data to paste so you get a double image. My version builds the result from the brightest layer to the darkest so is the opposite way round to yours and yet has the same glitch.

You could do a 256 layer version and that may eliminate most of the glitchyness. Increasing the resolution of the buffer to the maximum your gpu can handle will help too as totems scaling(standing/sitting height blurs the image so will result in smoother transitions. Post shader processing back down to normal size after will return some of the sharpness lost in the scaling.

Edit: saying that though our "infinate" versions are glitchy too.

The grey edge pixels are due to totems post processing. This grey line can be seen on most girls on the desktop if you have a white background.

I still think the best way would be to turn the girl into a hi res quad. but can gl/istripper handle millions of vectors on screen at once?

perhaps if we treated the clip as vectors anyway we could interpolate the missing pixels that are causing the glitch.

origin

ABCDEFGHI (pixels not layers)

current result

ABCD.BCDEFGHI ( 2 non concurent layers where top layer is 3 pixels offset more than the other layer)

Desired result

A (a75% b25%) (a50% b50%) (a25% b75%) BCDEFGH (interpolated pixels fill the gap)

if you see what i am getting at.

@Z22 - although it looks like I build up the stack in a particular direction in fact all the slices are processed in parallel so there is no "direction" involved. Just one of the oddities of parallel execution which makes no difference to the final result.

I have created a temporary version that uses a sequential block using "mix" functions rather than ifs but I hope to improve it further - mostly for my own satisfaction as the shader performance is good enough anyway. I will probably upload the modified version later today after I have tested it a bit longer. It looks a bit better than the previous version and definately handles bigger slice shifts better, thoug still not perfectly.

Oh yeh, forgot about it being parallel.

Just tried the scaling way i mentioned. Still glitchy but not as bad but it tanks the fps, which given my buffer sizes were 30720 x 17280 isn't surprising.

I have just updated the shader to apply the fixup for transparent pixels being shifted into the main image area. The link to the zip file is the same as before

http://www.theemusnest.eu/scenes/Zips/=%20Z22+TE%20=%203D.zip

As mentioned in my last post the fixup resorts to a sequential block, of 19 statements, which is a pity but does not slow things down on my system. This part can probably not be made fully parallel but I think I can do something about it. In any case it probably is not as "bad" in this respect as it first looks because statements from the following block can start executing while this block is still active, they may only be held up until their particular slice has been processed by the new block though that may depend on your GPU hardware.

In the new version you are getting the smearing(most obvious on legs) i used to get before i changed to a curve(because the legs/torso are more like cylinders than even slopes and the edge AA is a mid gray so it gets picked up by the first third/half of the layers) rather than linear progression and there is some nostril doubling which may go away if you swap to a curve too.

The depth looks good though.

I think you should seperate the left and right views back into 2 shaders really. It's neat that it can be one shader but it causes the overlap problem in cross eye mode and positioning could be a problem for others if they want several girls in scene with different "apparent" x,y,z positions(in that case it would be 2 shaders per girl though).

@Z22 - thanks for the comments. For the moment i will stick with a single shader because it is easier to experiment that way, but will probably eventualy switch back to two, or rather to using one shader twice with but with a uniform: clause in the scene file to control which side of the stereo pair to generate. A single shader invocation can be significantly more efficient than two because each pixel is only processed once rather than twice (actualy three times - once for the left image, once for the right and once to blend the two but the blend will be a low overhead compared to generating the image pair). The single shader invocation works well for cage and glass clips because with them there is essentially no chance of running into the overlap problem - it should also work well for more complex scenes in which the clip is seen through a frame such as a doorway or a window.

I will probably switch to using a curve for the layers. I asked earlier if you had a formula for what you use and if so can you please let me know what it is rather than as a table of values because that way I can accomodate different numbers of slices more easily.

I didn't use a formula for the curve i just plotted it out manually in fooplot and messed with the values till it looked right. It is just a quater of an oval, 15 pixel max offset spread over 19 layers.

Why are you blending the 2 images?

@Z22 - I don't blend the two images myself, but it happens when two sprites or clipSprites overlap unless you explicitly use blend: false on the front one - and if you do that the transparent pixels in the front one become opaque so you cant see what is behind it.

I have just tried a very simple experiment - applying a slight blurring before calculating the "depth" to use when slicing. Not bluring the slices themselves, just averaging over a small horizontal range befoer calculating D in my version of the shader. This simply entails replacing the calculation of D with

float D = 1.0 - dot(S_00.rgb+S_01.rgb+S_02.rgb,vec3(0.1111111111111111) );

This seems to improve the overall look, though it has the side effect of making the pole and the bars of cages look slightly transparent almost as if they were made from glass rather than metal. So far I have only done the one experiment so maybe a better blur function could give better results - but for now I am off to bed and will be too busy in the next few days to do anything more with the shader.

@Z22 - I have done a little more experimenting. I now have a version of the shader in which I can change the number of slices just by changing a value specified by a #define statement so it is now very easy to fiddle about with things. At the moment it is limited to a maximum of 64 slices but as my laptop can only just manage 32 without slowing down the display I will leave it at that for now. However it would be a matter of minutes to raise the limit to 128 or even 256 slices because everything is now driven by the #define statement.

As mentioned in my previous post blurring before calculating the depth used for slicing seems to help, though I need to tune it for best results, and increasing the number of slices certainly helps. I have not yrt got round to using a non-linear function for the slice shift but I think that it should help in the way you have described.

As yet the latest version is not quite ready to publish, but I will probably do so at the weekend if not before.

@Nasashie I don't recall many scenes with specific window washing use. Nice to see somemore included. I think @Number6 did a few a while back not sure though. As @Emu said welcome and thanks for shareing.

Edit: Emu did those washing scenes my mistake.

http://www.istripper.com/forum/thread/29408/21?post=567586

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

Hello I made a scene for me and I share it : Inside. I made it from the Whisper Club source and it probably requires corrections. By default the main clip is only for the duo and the secondary clip fo...

Nice to see a new share author. Welcome @Nasashie 👍

@DANO70 - you were right the first time. @Number6 was the first to post any window washing scenes and I later updated my Houses scenes after I saw his and after that I added a Fairy In A Glass scene.