Hello Nick,
In the meanwhile, we’ve kicked out more tests, getting closer but no cigars.
const float HalfFov = 2.19686294f / 4.f;
const float InWidth = 960
const float InHeight = 1080
const float XS = 0.5f / tan(HalFov) / InHeight;
The combination of changing the ratio from (nearly) 1:1 to 1:2 in the FOV and halving the XS value, we’ve now matched the FOV in -emulatestereo to the 2D build, the anamorphic raster returning to square pixels on a 1080p 3D display in SxS.
Viewing the L and R imagery in overlay I note that the point closest to the camera in both L and R views converges, thus defining screen plane. All other points diverge into positive parallax, as you said, “we use infinite far plane projection”. The issue is the amount of parallax is way aggressive, expressed as a percentage of screen width comes to roughly 15%. The film industry follows super conservative rules for 3D for total stereo budget being 3%, with only 2% being for rear projection. This 15% figure looks suspiciously close to the default ProjectionCenterOffset, 0.151976421f; . You had recommended we use a value 0 for that, but suggesting this had only to do with HMDs, not the interaxial of the virtual cameras, which you say falls to CalculateStereoViewOffset(). I don’t see a value for that in the script, but here’s what we’ll try (in lieu of your weighing in earlier);
const float ProjectionCenterOffset = 0.0f;
const float CalculateStereoViewOffset = 0.5f;
I’m leaving out other code here, but is this generally the format to use? Also, how to shift the convergence point? I see the line for GNearClippingPlane and that whole FMatrix grid of values, confused how to bring the convergence point forward to the camera (desire about 10% forward projection, our lighting in the cave supports it, screen violations minimal).
Okay, so unless I hear from you earlier, we’ll test this and report results. Even if we succeed, I greatly appreciate your filling in the other details, we’re so close!
Benjy