Hello Nick,
Steps forward and one backward. We downloaded the source code for the Engine from GIT Hub, edited the HalfFov value and InWidth/InHeight, compiled and tested on a SxS monitor. I’ll describe results, but first our settings:
(default) const float HalfFov = 2.19686294f / 2.f;
(This looks like a ratio, is it? If so,it’s almost 1:1, thanks for clarifying)
We changed this to:
const float HalfFov = 2.19686294f / 4.f; (which seemed logical, based on the super wide FOV we were seeing)
Also we changed the InWidth/InHeight values from 640/480 to 960/1080. Had we only changed that, would you expect the default FOV and other default values to be acceptable 3D? I ask that because of what I see with this change combined with changing HalfFov. That is, before setting the 3D monitor to SxS, I see the L and R rasters side-by-side as expected, but two things are out: The FOV is now half of that in the same build, but omitting the -emulatestereo command line (the desired FOV independent of 2D or 3D). That’s why I’m tempted to believe the default value for HalfFov is actually correct. The second issue is before setting the monitor to SxS I notice that both L and R rasters aren’t anamorphic, the perspective is correct for 2D (per eye), and so predictably when I set the monitor to SxS these rasters are not unstretched back to a normal raster, but from normal to stretched.
So, I need to return the correct FOV and the normal pixel aspect ratio, question being if the solution is either to simply change the InWidth/InHeight for 1080p monitors?, or some other combination? As you say, the ProjectionCenterOffset isn’t relevant here, the GNearClippingPlane also not relevant, that leaves Projection Matrix. If you can shed light on how that box works, which could save tons of time arbitrarily populating values to observe a pattern, etc. Fingers crossed this is simply about InWidth/InHeight needing the update to HD.
Many thanks for all your help!
Benjy