@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

Everything about 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 ?