Shader variables and VR Single Pass rendering

[truthknown]

Hey Guys,

I had been troubleshooting a problem I was having with ENVSHADE and Single-Pass VR as it was not rendering the scene with ENVSHADE installed. Digging into the shader files, I found that the cb_View variables were not working in Single Pass mode, either just failing or freezing in the code. Worked fine in Stereo mode. However, the cb_mView variables did work just fine in Single Pass. I am not sure the difference between them and I believe them to be exactly the same, however changing the code from cb_View to cb_mView solved that specific problem.

So I am wondering if this issue could be causing other rendering issues in single pass mode. Looking through numerous shader files, it seems cb_View and cb_mView are both used randomly. Maybe this explains some of the floating scenery issues.

Any thoughts?

Thanks,
Chris

[truthknown]

Beau, I don't know if this is in the right forum section. Can move if needed, just advise.

Thanks,
Chris

[YoYo]

Good find!

[YoYo]

Maybe this explains some of the floating scenery issues.

So.... hmmm, any news about this issue of the effect of "floating scenery" in VR mode? This is especially noticeable on grass / landclass (on apron its ok but only on apron and hard airfields but if you look behind the hard surface of airfield, you will see it already and it looks really strange).

It wasnt present in 4.5, with v5 its present and it isnt solved yet. Pls to fix it in incoming 5.2 patch.

[truthknown]

I found that this is causing it. If I were to change all of the variables to cb_mView, it resolves the floating issue. Unfortunately it brings additional issues that are worse. I am unable to figure it out without putting in the time which I don't have.

Chris

[YoYo]

I forgot, this effect of "floating scenery" concerns also water BELOW Ultra settings. Seaplanes on the water level looks like in the air still :( .

[Beau Hollis]

cb_View and cb_mView should map to the same data in Stereo and in view 0 of a single pass group (which for VR is the main app window's view which is the left eye). cb_View in singlepass uses a macro expansion to grab view data from an array using an InstanceID variable. cb_mView is used explicitly in some places to indicate that we want data from the primary view.

The macro expansion relies on a uint variable named InstanceID. My guess is ENVSHADE is trying to use cb_View from inside a function where InstanceID is not defined and pas not passed as a paramater. This would cause the shader to fail to compile. swapping out cb_mView will fix the compile error, but the right eye will be using data from the left. The correct way to fix it would be to add new function param for instanceID and pass it in from the calling shader function.

[truthknown]

Thanks Beau. I will pass this info onto the the TOGA team.

Could issues similar to this be causing the floating scenery effect and the mismatched lighting in the eyes? Well I guess you guys have fixed the latter already correct?

How goes it with the VR Singlepass fixes? Anxiously awaiting the next hotfix/version...

Thanks,
Chris

[YoYo]

cb_View and cb_mView should map to the same data in Stereo and in view 0 of a single pass group (which for VR is the main app window's view which is the left eye). cb_View in singlepass uses a macro expansion to grab view data from an array using an InstanceID variable. cb_mView is used explicitly in some places to indicate that we want data from the primary view.

The macro expansion relies on a uint variable named InstanceID. My guess is ENVSHADE is trying to use cb_View from inside a function where InstanceID is not defined and pas not passed as a paramater. This would cause the shader to fail to compile. swapping out cb_mView will fix the compile error, but the right eye will be using data from the left. The correct way to fix it would be to add new function param for instanceID and pass it in from the calling shader function.

Thank You for explanations however for me its difficult to say something. To big technical speech for me :D.
BUT what is important - this floating effect in P3Dv5 (near border of apron/runway and water below Ultra settings) is present also in default and clear P3Dv5 without addons. So its not TOGA issue I suppose. Without this its very visible too. It wasnt present in v4.5 too. I never noticed this, only in v5.
Is it possible to fix it in incoming 5.2? I use few other simulators also and this 3D effect mismatch is present only in P3Dv5.

[Beau Hollis]

What's the best location you have found for viewing the floating effect with default content?

Feel free to disregard the source code discussion :). The main takeaway there is that anyone modifying our shaders may run into trouble with SinglePass.

[MPO910]

What's the best location you have found for viewing the floating effect with default content?

Feel free to disregard the source code discussion :). The main takeaway there is that anyone modifying our shaders may run into trouble with SinglePass.

Beau. I reported this also with a list of airports all add-ons.
But @yoyo should also report some... a default one @YoYo?

[Beau Hollis]

The floating/disappearing models should be fixed in the next release. It looks like we missed updating a fallback transform type used by fs9 models. In the meantime, if you're up for a shader modification, you can fix it by modifying P3DInstallDir\ShadersHLSL\general.fx as follows:

Find this line (somewhere around line 352)

Code: Select all

#else
    float4x4 worldMatrix = GetInstanceTransform(In.mInstanceIndex);
#endif

And add this new line directly below it like this:

Code: Select all

#else
    float4x4 worldMatrix = GetInstanceTransform(In.mInstanceIndex);
    worldMatrix[3].xyz += cb_View.mViewInstanceOffset.xyz;
#endif

Then restart P3D or if you have shader reload bound to a key, you can use that at runtime. Thanks all for the reporting this. While fs9 models haven't been officially supported since v2, we still try to keep 3rd party content working as best we can.

[truthknown]

Hot Damn that worked!!! Thanks Beau!

So we know now that like every DD scenery is using fs9 models... LOL!

Any quick shader modifications we can manually make ourselves to fix the lighting issues in the right eye?

[MPO910]

Hot Damn that worked!!! Thanks Beau!

So we know now that like every DD scenery is using fs9 models... LOL!

Any quick shader modifications we can manually make ourselves to fix the lighting issues in the right eye?

THIS is so true!

Now you guys can see how many effort LM puts in to keep your hard earned money, spent on addons, from higher value!

Something not everyone sees it like this! Thanks to LM for finding this FIX!

Marcus

[MPO910]

..............

Any quick shader modifications we can manually make ourselves to fix the lighting issues in the right eye?

This I reported to the DEVS. As far as I know this is something in the core engine and can not be fixed with a "quick" shader mod. I recall this information came from Beau Hollis earlier at a related topic here at the support forum about this issue. He mentioned there, they will investigate an have a look at it.

Marcus