@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
}
}