Crystal Super Ultrawide — severe geometric distortion introduced in SBoYS3 1.3.0-beta 2 and final version when using iRacing OpenVR

[Yakumo60]

Crystal Super Ultrawide — severe geometric distortion in SBoYS3 1.3.0-beta 2 and final version with iRacing OpenVR

Hardware / Software

• Headset: Pimax Crystal Super Ultrawide
• GPU: NVIDIA RTX 5080
• CPU: AMD Ryzen 7 7800X3D
• OS: Windows 11 Pro
• VR runtime: SteamVR
• Driver: SBoYS3 CustomHeadsetOpenVR
• Affected version: 1.3.0
• Tested application: iRacing using OpenVR

Problem

With SBoYS3 1.3.0, I get severe geometric distortion when running iRacing through OpenVR.

This is not simply an incorrect FOV, scaling, or resolution issue. The geometry itself appears to deform dynamically when I move my head.

For example, during slow horizontal or vertical head movements:

• the center of the image can appear strongly convex/concave;
• straight lines bend and change shape;
• rigid objects such as the dashboard and windshield frame appear to stretch or shift;
• track edges and distant geometry visibly "swim" or warp;
• the deformation changes continuously with head position.

The effect is severe enough to make iRacing difficult to use.

Head tracking itself appears to work correctly, so this looks more like a projection/distortion correction problem than a tracking problem.

The normal SteamVR environment does not show this distortion. So far I have reproduced it only in iRacing using OpenVR; I have not yet tested other OpenVR games.

Version comparison

I tested the following versions with the same headset and system:

Version	Result
1.3.0-beta.0	No severe distortion
1.3.0-beta.1	No severe distortion
1.3.0-beta.2	Severe distortion
1.3.0	Severe distortion

The problem therefore appears between beta.1 and beta.2.

I do not have the beta.2 source code, so I cannot identify the exact change that introduced it.

Important profile A/B test

There is an additional result that seems to rule out the Crystal Super Ultrawide profile parameters themselves as the main cause.

Beta.1 did not yet use the final dedicated Ultrawide profile. I copied the exact same Crystal Super Ultrawide profile used by 1.3.0 into the beta.1 driver:

"distortionProfile": "Crystal Super Ultrawide Default",
"distortionProfileDeviceType": "CrystalSuperUltrawide",
"resolutionX": 3840,
"resolutionY": 3744,
"displayRotation": 2,
"maxFovX": 111.0,
"maxFovY": 107.0,
"fovClamping": true,
"eyeRotation": 9.0,
"parallelProjection": true,
"enableEyeTracking": true

Results:

• beta.1 + its original profile: no distortion
• beta.1 + exact 1.3.0 Ultrawide profile: no distortion
• 1.3.0 + the exact same Ultrawide profile: severe distortion

The final Ultrawide profile gives a much larger FOV when used with beta.1, but the severe geometric warping does not appear.

This suggests that the profile parameters alone are not responsible and that a change in the distortion implementation may be involved.

Other tests

• Disabling DFR / eye tracking: no change
• SPS enabled or disabled: no noticeable change
• beta.0 driver: no severe distortion
• Normal SteamVR environment: no visible distortion

Potentially relevant source change

I noticed the following change between the available 1.3.0-beta source and the 1.3.0 source in:

CustomHeadsetOpenVR/src/Distortion/RadialBezierDistortionProfile.cpp

The beta source contains:

distortion.y -= (topTan - bottomTan) / (topTan + bottomTan);

while 1.3.0 contains:

distortion.y += (topTan - bottomTan) / (topTan + bottomTan);

This change is present in commit:

c7a30ee7bb1d06f5f985917d0df4f5721549b384

[PATCH 26/32] Improved Crystal Super 50PPD distortion

I cannot confirm that this is the cause because I do not have the beta.2 source. However, the version behavior is consistent with a distortion-related change introduced around beta.2.

Could you please check whether this vertical distortion sign change, or another distortion-related change introduced between beta.1 and beta.2, could explain the behavior of the Crystal Super Ultrawide when running iRacing through OpenVR?

I can provide screenshots or a video showing the deformation if needed.

[Yakumo60]

Additional A/B testing and current conclusion

I performed five controlled tests on the 1.3.0 final version, changing the relevant parameters individually.

The baseline configuration was:

offsetX = -6.38;
offsetY = 6.38;
eyeRotationOffset = -3.0;

Results

Test	Change	Result
Test 1	distortion.y += ... → distortion.y -= ...	❌ Distortion still present
Test 2	eyeRotationOffset = -3.0 → 0.0	❌ Distortion still present
Test 3	offsetX = -6.38 → 0.0	❌ Distortion still present
Test 4	offsetY = 6.38 → 0.0	✅ No visible geometric distortion
Test 5	Beta-style offsetX = -4.0, eyeRotationOffset = -2.0, with offsetY = 0.0	✅ No visible geometric distortion

The important result is that the only parameter common to the two configurations without distortion is offsetY = 0.0.

With:

offsetY = 6.38;

the severe geometric distortion is present.

With:

offsetY = 0.0;

the geometric distortion disappears.

Changing offsetX, eyeRotationOffset, or simply reversing the sign of the vertical distortion term did not solve the problem.

Additional investigation of the mathematical formulas

After these tests, I also performed additional experiments directly on the mathematical formulas used by the distortion implementation, trying to determine whether the problem could be corrected at the formula level.

Unfortunately, these experiments did not produce a correct result. The different modifications either retained the geometric distortion or introduced other geometric errors.

Therefore, I do not currently have a reliable mathematical correction for the new distortion implementation.

Current workaround

For the moment, I am using a locally compiled DLL with:

offsetY = 0.0;

This removes the severe dynamic geometric distortion in iRacing/OpenVR and makes the headset usable again.

However, this is only a workaround. It is not intended as a final distortion profile, because changing offsetY to zero means that the intended optical geometry of the Crystal Super Ultrawide profile is no longer being applied as originally designed.

I will therefore keep using this modified DLL temporarily while waiting for a proper distortion-correction profile or fix from the developer.

Current conclusion

Based on all the tests so far, the regression appears to have been introduced between 1.3.0-beta.1 and beta.2, and the strongest reproducible trigger I have identified is the interaction between the new distortion implementation and:

offsetY = 6.38;

The fact that the exact 1.3.0 Ultrawide profile works correctly with beta.1 but produces severe dynamic geometric distortion with 1.3.0 also suggests that the profile parameters alone are not the root cause.

At this point, I believe the issue requires investigation in the distortion implementation itself rather than further manual tuning of the Ultrawide profile.

The offsetY = 0.0 DLL is currently my temporary workaround until a proper distortion-correction profile/fix is available.

[Yakumo60]

Update: Root cause identified and working code fix (Symmetry Bypass) found!

After further investigation and compiling a few more custom DLLs, I found out that the new math introduced in v1.3.0 is actually 100% correct. The real culprit here is iRacing's legacy OpenVR renderer.

As noted in my first post, the normal SteamVR environment has absolutely no distortion. I also verified that iRacing runs perfectly without distortion when using OpenXR.

The issue only happens in iRacing via OpenVR because its engine is historically incapable of correctly processing vertical asymmetric projections (where topTan != bottomTan). When SBoYS3 v1.3.0 feeds iRacing the asymmetric vertical frustum caused by offsetY = 6.38, iRacing incorrectly computes the camera projection center, resulting in the severe dynamic "pupil swim" effect.

(The older beta.1 likely worked in iRacing only because it used a different Y-axis math that accidentally masked or bypassed this iRacing bug).

The Solution: "Vertical Symmetry Bypass"

To retain the perfect math of v1.3.0 while fixing iRacing OpenVR, I implemented a "Symmetry Bypass" in a custom DLL.

(Note: To test this fix, I reverted my JSON profile back to your original v1.3.0 settings. This means offsetY = 6.38 is fully restored and active, and the offsetY = 0.0 workaround I mentioned previously is no longer used).

The logic is simple: we feed iRacing a perfectly symmetrical vertical projection so its engine doesn't break, and then we adapt the Y-axis distortion to sample from this symmetrically rendered image.

Here are the exact changes applied to RadialBezierDistortionProfile.cpp from the clean 1.3.0 source that perfectly fixed the issue:

1. Force vertical symmetry for the application (GetProjectionRaw, around line 610):

    const float hFovHalfOuter = halfFovOuterX * kPi / 180.0f;
    const float hFovHalfInner = halfFovInnerX * kPi / 180.0f; 
    const float vFovHalfTop = halfFovTopY * kPi / 180.0f;
    const float vFovHalfBottom = halfFovBottomY * kPi / 180.0f;
    
    if(eEye == vr::Eye_Left){
        *pfLeft = std::tan(-hFovHalfOuter);
        *pfRight = std::tan(hFovHalfInner);
    }else{
        *pfLeft = std::tan(-hFovHalfInner);
        *pfRight = std::tan(hFovHalfOuter);
    }
    
    // BYPASS: Force a perfectly symmetrical vertical projection for iRacing
    float maxVFovHalf = std::max(vFovHalfTop, vFovHalfBottom);
    *pfTop = std::tan(maxVFovHalf);
    *pfBottom = std::tan(-maxVFovHalf);

2. Adapt the Y-axis normalization (ComputeDistortion, around line 560):
Keep the X-axis logic totally intact (to preserve perfect 3D scale and convergence), but replace the new Y-axis logic with a symmetric normalization:

    float outerTan = std::tan(halfFovOuterX * kPi / 180.0f);
    float innerTan = std::tan(halfFovInnerX * kPi / 180.0f);
    
    // --- HORIZONTAL AXIS (Intact from 1.3.0) ---
    distortion.x /= (outerTan + innerTan) / 2;
    if(eEye == vr::Eye_Left){
        distortion.x += (outerTan - innerTan) / (outerTan + innerTan);
    }else{
        distortion.x -= (outerTan - innerTan) / (outerTan + innerTan);
    }
    
    // --- VERTICAL AXIS (Adapted for Symmetry Bypass) ---
    // Use the same maximum symmetric tangent sent to GetProjectionRaw
    float maxVTan = std::max(std::tan(halfFovTopY * kPi / 180.0f), std::tan(halfFovBottomY * kPi / 180.0f));
    distortion.y /= maxVTan; 
    
    // No translation (distortion.y += ...) is needed here since the source image is now symmetrical.
    
    return distortion;

Result: With this custom DLL, the dynamic geometric distortion in iRacing OpenVR is completely eliminated. The optical center perfectly aligns with the lenses (offsetY = 6.38 does its job correctly early in the function), and the 3D depth/convergence remains flawless.

Proposed Implementation: Automatic Detection or Profile Toggle

To implement this without breaking the correct math for other games (like SteamVR Home) that handle asymmetric projections perfectly, here are two potential approaches:

1. Automatic Process Detection (Ideal UX): SBoYS3 could check the name of the executable querying the API. If iRacingSim64DX11.exe is detected, the driver automatically applies the vertical symmetry bypass.
2. A New JSON Profile Toggle (More Flexible): Adding a specific flag like "forceVerticalSymmetry": true in the profile. This allows users to manually enable the bypass for any game that might share iRacing's legacy rendering bugs with asymmetric frustums.

Thank you again for the amazing work on this driver!

Temporary Workaround Download:
For anyone facing the exact same issue in the meantime, I have attached my locally compiled DLL containing this Symmetry Bypass (compiled from the clean 1.3.0 source). Just extract the ZIP and replace your original driver_CustomHeadsetOpenVR.dll in "SteamVR\drivers\CustomHeadsetOpenVR\bin\win64" folder:
driver_CustomHeadsetOpenVR_1.3_UW.zip

[sboys3]

I plan to improve the distortion profile code and as part of the improvements it will eliminate the vertically asymmetric rendering for better performance and compatibility.