@Calgon
OIC...you have the Left eye, right eye ray based &
accomodated in the mainVR code already. Ok :)

You have conversion software for this with existing
OpenGL shader based 2D scenes ..
or would you need to rewrite them all ?

The main obstacle to SBS is the reduced screen width.
Peeps are used to wide screen fullscreen encompassing
all the movement and freedom a model offers in her
performance the same way they watch their movies or TV.

If I want 3D I have old shutter glasses & 100 Hz screen that
will do that if I can put up with the slight ghosting that occurs
however it will still remain as a performance in wide screen.

The main obstacle to SBS is the reduced screen width.

if you are designing your SBS scene for a 16:9 screen size in Landscape Orientation.
There is no loss of screen width.
you create two full width full size Scenes, then Scale each eye view by 50 in width. and place them Side by Side
So you are taking the Full Width, and just Squishing the width , Not Crop it, nothing gets cut away.

it's like taking two sponges, you squish the sides together so the two fit in the same width as One, and then you can later stretch it back out and both are the full width again.
Nothing was cut away or removed from either sponge, it was just Squished to fit a smaller width.

in the VR headset or 3D TV or 3D Projector
Each eye view is then Stretched back out to Fit the Full Width.

This is why @Calgon wanted to use an 8K screen.
then Each 8K eye, is Squeezed down to a 4K width.
you get two 4K scenes Side by Side

you can do the same and Design for a 4K screen, then you get two squeezed 4K screens squeezed down to 1080p Screens Side by Side


When I did my Scene for the Portrait Orientation, then Yes, the Sides of the Scene are Sacrificed.

3D SBS Scene
Design 2 Full Width Scenes and Place them Side by Side
for 1920 x 1080 you then end up with a 3840 x 1080 scene

now you scale the Width by 50%
and the Scene is Squeezed down in Width to 1920 x 1080

When it is Viewed in the VR Headset, or on a 3D TV or a 3D Projected
Each Half is the Stretched to be full width for each eyes view.

design phase 2 full width Scenes Side by Side making the Image 3840 x 1080
https://www.istripper.com/customdata/forum/2025-02-23/Q98K3DqW.png

then you scale the width by 50% so that each eye view is Squished to 960 x 1080 to fit Side by Side in a single 1920 x 1080 packaged size.
https://www.istripper.com/customdata/forum/2025-02-23/MQWPE8sk.png

The Playback device, then takes the Left Half and stretches it back out to a 1920 x1080 size
and Does the Same with the Right Half, it is stretch out to 1920 x 1080

you now have two Full Width Scenes again, one for each eye.

use a Frame Buffer
you make a full width Frame buffer for the Left Eye
Build the entire full width scene

then you make a full width Frame Buffer for the Right Eye
Build a Duplicate Full width scene with the Objects shifted left or right
to Create Depth
Shift an Object to the Left = Out in Front of the Screen
Shift an Object to the Right = In back of the Screen
No Shift to an Object = on the face of the Screen

Place the Items that you shift to the right 1st,
with the Items having the most right shift the 1st item.
then stack the Items based on their shift amount from most right to most left
This Keeps the Items out in front, actually in front of the items further back

Takes a bit of planning...

each Pixel of Shift will look like about 1 foot of Distance
A Max of 20 Pixels to the left or 20 pixels to the right
provide about 40 feet of Distance perception

Now you create a 2D camera
set the Size to the full Screen dimensions
Scale the Left Eye frame buffer by .5 in X and place it to the left in the camera view
Scale the right Eye frame buffer by .5 in X and place it to the right in the camera view

That is the basics

Movement horizontally or vertically at the same depth
Items further away will appear to move slower than items closer to the viewer

in both frame buffers use the same value for time and x and y distance
this will keep the item movement the same for both eye views.

Movement Front to Back or Back to Front

as an items moves from the back to the front two things happen
the Shift distance between the items changes in the Negative offset amount
and the Size or Scale of the item increases

always use the same time
for the Position in X, one or both must change at a different distance
The right eye item moves less in X then the Left eye item
for the scaling, scale in X and Y the same amount such as 1.1, 1.1

as an items moves from the Front to the Back the same two things happen
but just the opposite of what is described above
the Shift distance between the items changes in the Positive offset amount
and the Size or Scale of the item decreases.

always use the same time
for the Position in X, one or both must change at a different distance
The right eye item moves More in X then the Left eye item
for the scaling, scale in X and Y the same amount such as 0.909, 0.909

note if you scaled the items while moving Back to Front by 1.1
then you use the Inverse of that when you send them from Front to Back
1/1.1 = 0.909
That will return the items to the same size again.

I try to Avoid Two Items crossing over the other while move front to back.
it can create eye strain, till they are no longer in the same place on the screen.
or Plan Ahead, so the Item moving from Front to the Back is placed in the Scene 1st, so that after it's move is done, it is in the proper scene order of items.
items back 1st, Items front last.

@WA
I had a go at the above..using FGA480 as a base scn ..tis a tad rough ofc..
I had to abandon using a demanding shader like mrange's Mandelbox slice.fsh
because way too stuttery/congested so substituted a simple .fsh like clouds.fsh

I guess this could be tweeked a lot better by a Quest owner

I had trouble using scaling like 0.5, 1.0 maybe because my native screen
resolution is way down at 1670 x 768 .. not sure exactly why the scaling did not apply
plus the original shader did not like any re-scaling at all so could/did
not apply it.
At this stage I'm giving away the pursuit of 3D. I've been watching 3Ds ups &
downs for 20 years & each tech surge always seems to be made redundant in the end.

text: Info/infoFractalGarden084f.txt
logo: Info/small_logoFractalgardenA480A.png
minVersion: 1.2.0.80

clip {
id: Clip
deny: top, inout
nameGlowColor: 0, 1, 1
}

texture {
id: Sweet
source: Textures/Beige01.png
}

texture {
id: ppcstage
source: ETImages/Plaftexrot01/PPstageMini.png
}

framebuffer {
id: Clipx
size: 960, 540 //reduced to half size for clip from 1920, 1080
source: Clip
}

framebuffer {
id: Sweet01
size: 1920, 1080
source: Sweet
//shader: fragment, Shaders/TheEmu - Null.fsh
}

framebuffer {
id: Sweet02
size: 1920, 1080
source: Sweet
//shader: fragment, Shaders/TheEmu - Null.fsh
}

framebuffer {
id: Sweet01a
size: 1920, 1080
//pos: 0, 0, 0
source: Sweet01
shader: fragment, Shaders/clouds.fsh //mrange/Mandelbox slicesMod01.fsh
}

framebuffer {
id: Sweet02a
size: 1920, 1080
//pos: 1920, 0, 0 //960, 0, 0
source: Sweet02
shader: fragment, Shaders/clouds.fsh //mrange/Mandelbox slicesMod01.fsh
}

camera {
type: 3D
angle: 45
pos: 0, 0, 1272 //1368



sprite {
id: Sweet01b
size: 1920, 1080
pos: 0, 0, 0
source: Sweet01a
//scale: 0.5, 1.0, 1.0
}

sprite {
id: Sweet02b
pos: 960, 0, 0
size: 1920, 1080
source: Sweet02a
//scale: 0.5, 1.0, 1.0
}


sprite {
pos: -240, 210, 685
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}

sprite {
pos: 200, 210, 685
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}

//model left
clipSprite {
pos: -240, 205, 700
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0
source: Clipx
}

//model right
clipSprite {
pos: 200, 205, 700
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0
source: Clipx
}

clipNameSprite {
source: Clip
pos: 360, 224, 565
scale: 0.32, 0.32
}
}

https://www.istripper.com/forum/thread/29408/89?post=795122

关于iStripper的一切 / Share your FullScreen - Member Created Scenes here

just a couple updates some ***** changes to the Starz4 3D SBS scenes with the logo and clip names https://virtuastripper.net/@WA-Starz4-3D-SBS-b.zip Also added a new 3D Scene to my Caught in the Rainb...

@ET

I think the scene pretty much looked / worked ok.
I did make some fine adjustments - so it should work as a basic template for future works.

I guess this could be tweeked a lot better by a Quest owner

I had trouble using scaling like 0.5, 1.0 maybe because my native screen
resolution is way down at 1670 x 768 .. not sure exactly why the scaling did not apply
plus the original shader did not like any re-scaling at all so could/did
not apply it.
At this stage I'm giving away the pursuit of 3D. I've been watching 3Ds ups &
downs for 20 years & each tech surge always seems to be made redundant in the end.

EDIT:
Works for my 16:9 aspect ratio screen in 1080p
sent to my Quest Headset using VR Desktop.

text: Info/infoFractalGarden084f.txt
logo: Info/small_logoFractalgardenA480A.png
minVersion: 1.2.0.80

clip {
id: Clip
deny: top, inout
nameGlowColor: 0, 1, 1
}

texture {
id: Sweet
source: Textures/Beige01.png
}

texture {
id: ppcstage
source: ETImages/Plaftexrot01/PPstageMini.png
}

framebuffer {
id: Clipx
size: 960, 540 //reduced to half size for clip from 1920, 1080
source: Clip
}

framebuffer {
id: Sweet01
size: 1920, 1080
source: Sweet
//shader: fragment, Shaders/TheEmu - Null.fsh
}

framebuffer {
id: Sweet02
size: 1920, 1080
source: Sweet
//shader: fragment, Shaders/TheEmu - Null.fsh
}

framebuffer {
id: Sweet01a
size: 1920, 1080
//pos: 0, 0, 0
source: Sweet01
shader: fragment, Shaders/clouds.fsh //mrange/Mandelbox slicesMod01.fsh
}

framebuffer {
id: Sweet02a
size: 1920, 1080
//pos: 1920, 0, 0 //960, 0, 0
source: Sweet02
shader: fragment, Shaders/clouds.fsh //mrange/Mandelbox slicesMod01.fsh
}

camera {
type: 3D
angle: 45
pos: 0, 0, 1272 //1368



sprite {
id: Sweet01b
size: 1920, 1080
pos: -20, 0, 0 // slide left to move it back in to the screen
source: Sweet01a
//scale: 0.5, 1.0, 1.0
}

sprite {
id: Sweet02b
size: 1920, 1080
pos: 960, 0, 0 // at the half screen location
source: Sweet02a
//scale: 0.5, 1.0, 1.0
}


sprite {
pos: -220, 210, 685 // left eye of the stage
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}

sprite {
pos: 220, 210, 685 // right eye of the stage
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}

//model left
clipSprite { // centered on left stage
pos: -220, 205, 700 // X same as Stage
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0
source: Clipx
}
clipNameSprite { // left side clip name
source: Clip
pos: -170, 224, 565 // Manual adjustment
scale: 0.32, 0.32
}
//model right
clipSprite { // right side clip offset to the left by 10
pos: 210, 205, 700 // X is 10 less than the stage
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0
source: Clipx
}

clipNameSprite { //Right side clip name
source: Clip
pos: 360, 224, 565 // kept same X adjust left eye X above
scale: 0.32, 0.32
}
}

I placed my edited versions on my site here:
the Cloud shader based 3d Scene
https://virtuastripper.net/ET_FractalGardenA480-Clouds-3D.scn
https://virtuastripper.net/SceneImages/ET_FractalGardenA480-Clouds-3D.jpg

and the A480 scene in 3D with the mrange/Mandelbox slicesMod01.fsh shader
https://virtuastripper.net/ET_FractalGardenA480-3D.scn
https://virtuastripper.net/SceneImages/ET_FractalGardenA480-Clouds-3D.jpg

This one is GPU hungry

Thanks @WA for the template..👍
I was waiting for your tweeks to study them in detail
Much appreciated.😊

@EverthangForever

You have conversion software for this with existing OpenGL shader based 2D scenes ..or would you need to rewrite them all ?

My script takes a JSON file of the shader from shadertoy and converts it to the format we use on iStripper. It can't convert 2D to 3D, that's a manual process of digging out what variables the original writer had used to define their coordinates and the ray-origin. Some time since I did one so, I'm very rusty. I convert them on Shadertoy first as it's easier to debug but here's a version of the one you were looking at:
https://www.shadertoy.com/view/wfjGRd

I think @WA has already covered lots of other bits and my move to 8K to get 4k per eye etc.

I have a different approach to @WA on the last scenes I publised (both approaches work). I put the LHS scene in a framebuffer with the camera offset and then the same code in the RHS framebuffer with the camera offset in the opposite direction. Because each eye is running in its own framebuffer a model can't wander off over the other eye instead of leaving the screen and also if I want a scene element to appear further back - I just move it further back on the z-axis and the camera placement does the rest.

I have a different approach to @WA on the last scenes I publised (both approaches work). I put the LHS scene in a framebuffer with the camera offset and then the same code in the RHS framebuffer with the camera offset in the opposite direction. Because each eye is running in its own framebuffer a model can't wander off over the other eye instead of leaving the screen and also if I want a scene element to appear further back - I just move it further back on the z-axis and the camera placement does the rest.

Interesting, I'll have to play around with that.
need to use a 3D frame buffer, so you can make use of the Z depth control..

Oh thats brilliant @Calgon. I can't wait to see your next work.

I notice a curious 3D effect I am getting in cross-eyed with that clouds shader.
Now that the settings have been corrected, the model seems to be 'enveloped' by the clouds. I suspect it has something to do with the fact they are moving ever so slowly sideways in the scene causing a slight variation in the pattern presented to each eye. Some interesting things happening here with depth perception & movement, because the model is not behind the shader..
Do you have similar 'enveloping' effects using your Quest Headset with any moving backgrounds ?

@WA

Interesting, I'll have to play around with that.
need to use a 3D frame buffer, so you can make use of the Z depth control..

It was you that introduced me to having multiple camera's !

There's sample code for achieving this in this gallery I posted recently:

https://www.istripper.com/forum/thread/56540/1?post=794682

关于iStripper的一切 / 8K VR SBS - Scene Shares

So here's the result of my first real foray into creating 8K backgrounds for viewing with a VR headset. Feel free to develop further.... https://bit.ly/4i0R491 I'll add some technical commentary into...

@ET
@Calgon

I had some time to play with converting the ET scene to using the Camera method.
I also simplified the background shader, only needing 1 buffer, because both eye camera views will use the same background

Doing that gave a huge performance boost.

ET - FractalGardenA480-Camera-3D.scn
https://virtuastripper.net/ET_FractalGardenA480-Camera-3D.scn
https://virtuastripper.net/SceneImages/ET_FractalGardenA480-Camera-3D.jpg

text: Info/infoFractalGarden084f.txt
logo: Info/small_logoFractalgardenA480A.png
minVersion: 1.2.0.80

clip {
id: Clip
deny: top, inout
nameGlowColor: 0, 1, 1
}
texture {
id: Sweet
source: Textures/Beige01.png
}
texture {
id: ppcstage
source: ETImages/Plaftexrot01/PPstageMini.png
}
// end of Textures
framebuffer {
id: Clipx
size: 960, 540 //reduced to half size for clip from 1920, 1080
source: Clip
}
framebuffer { // create a blank canvas only need one
id: blank_canvas
size: 1920, 1080
source: Sweet
}
framebuffer{ // Paint the background from the shader on the canvas
id: background
size: 1920, 1080
pos: 960, 540
sprite{
size: 1920, 1080
hotspot: 0.5, 0.5
pos: 0, 0, 0
rot: 0, 0, 0
opacity: 1
source: blank_canvas // use the blank canvas
shader: fragment, Shaders/mrange/Mandelbox slicesMod01.fsh
//shader: fragment, Shaders/clouds.fsh //mrange/Mandelbox slicesMod01.fsh
}
} // end of background
// same background will be used in both eye views

// most of the comments will be in the left eye frame buffer
// the right eye frame buffer will be the same except for the camera position
// create the left eye view frame buffer
framebuffer { // Left eye buffer
id: left_eye_buffer
size: 1920, 1080
camera { //Left eye camera view shifted to the left
type: 3D
angle: 45
pos: -20, 0, 1368 // camera positioned to the left
//pos: -20, 0, 1272 //1368
target: 0, 0, 0 // target is centered
Sprite{ // insert the background
size: 1920, 1080
pos: 0, 0, -200 // set the depth of the background
scale: 1.5, 1.5 // scale the background to fill the view
source: background
}
// other scene items here
sprite { // insert the stage
pos: -240, 210, 685 // place it in the Center of the camera view
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}
clipSprite { // centered on stage
pos: -240, 195, 710 // X same as Stage
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0 // scale 50% in X it will be stretched in the VR headset
source: Clipx
}
clipNameSprite { // clip name
source: Clip
pos: -130, 135, 700 // offset to the right of the model
scale: 0.32, 0.32
}
}// end of Left eye Camera view
}//end of Left Eye buffer

// the right eye frame buffer is exactly the same as the left eye
// Except for the camera position
framebuffer {
id: right_eye_buffer
size: 1920, 1080
camera { //Right eye view
type: 3D
angle: 45
// only the camera pos is different
// the rest of the scene is exactly the same
pos: 20, 0, 1368 // shift the camera to the right
//pos: 20, 0, 1272 //1368
target: 0, 0, 0 // the target is the center
Sprite{ //insert the background
size: 1920, 1080
pos: 0, 0, -200
scale: 1.5, 1.5
source: background
}
// other scene items here
sprite { // insert the stage
pos: -240, 210, 685 // Center of the camera view
size: 448, 64 //440
hotspot: 0.5, 0.5
source: ppcstage
scale: 0.925, 1.0 //1.85, 1
}
clipSprite { // centered on stage
pos: -240, 195, 710 // X same as Stage
sittingHeight: 290
standingheight: 370
resolution: 20
scale: -0.5, 1.0
source: Clipx
}
clipNameSprite { // clip name
source: Clip
pos: -130, 135, 700 // offset to the right of the model
scale: 0.32, 0.32
}
}// end of Right eye Camera view
}//end of Right Eye buffer


// this is where you build the SBS scene
//16:9 1920 x 1080
camera { // Compose the SBS Scene
type: 3D
angle: 45
pos: 0, 0, 1272
sprite { // insert the Left eye buffer
size: 1920, 1080
pos: 0, 0, 0 // at the left of the screen
source: left_eye_buffer
scale: 1.0, -1.0 // Flip the buffer over
}
sprite { // insert the Right eye buffer
size: 1920, 1080
pos: 960, 0, 0 // at the half screen location
source: right_eye_buffer
scale: 1.0, -1.0 // // Flip the buffer over
}
// end of SBS scene creation
} // close the SBS Camera

@WA
@ET

@ET - You could try a higher resolution using the Virtual Monitor setup that @WA detailed on Discord, maybe not 8k to get 4k but 4k to get 2k ??

Probably asked this before but is it possible to filter shows in a fullscreen scene in any way other than clip type (top, table etc) and category (bikini, cop etc) Can you filter by ethnicity or hair colour or anything else ?

Probably asked this before but is it possible to filter shows in a fullscreen scene in any way other than clip type (top, table etc) and category (bikini, cop etc) Can you filter by ethnicity or hair colour or anything else ?

I don't think this is possible - but @Wyldanimal @EverthangForever may know better.

A work around if you want specific filter types for a peaticular scene could be to create a playlist for the scene.

In iStripper V2.0 the filters in the "Collection" are now "AND"ed and therefore by applying the required filters you can end up with a group of cards that you can then add to a playlist, or even just add them directly to the queue.

@Number6

I thought not but thanks for the reply.

I can turn a playlist into a selection of cards to activate but would have preffered to just build it into the scene.

in my ideal scene
we would have the ability to add a playlist

playlist: random, scene2.txt <-- would chose the card or clip randomly from the playlist
playlist: scene2.txt <-- would play the cards or clips in sequence from the playlist

where the external scene2.txt file is a plain text file of card names and or clip file names
a0001
a0002
a0003\a0003_4201.vghd
a0004\a0004_4402.vghd

This would be ideal but could cause issues when shared, it the member does not have the cards included
in the playlist text file.

then the scene would have to use either cards on the queue or enabled cards form the collection.

I can dream can't I?
Put on the wish list...