[BUG] Shader code 'viewdir' and shadow/light rendering are inconsistent on right eye

Build Version # when you first started experiencing this issue:

This is a bug exists since the first version with VR.

Brief description of the issue:

TL;DR: there seems to be a bug involving the viewdir (directly or indirectly at least) in the Shader code, which impacts the rendering of lights and shadows in VR. I suspect the same bug, or something related to this bug, is influential to the other 2D and VR visual bugs which I’ve reported (see refs below).

NB: This bug is observable in VR easily because it shows a discrepancy between both eyes and makes the comparison easier. Even tough I’ll be using VR screenshots to highlight the problem, it also manifests itself in 2D.

Provide Screenshot(s)/video(s) of the issue encountered:
Detail steps to reproduce the issue encountered:

Context

There exist a number of bugs with the rendering which all seem unrelated but might have the same root cause (maybe):

  • I’ve reported 3D objects and Lights disappearing when looked at, but reappearing at 45 deg.
  • I’ve also reported the same phenomenon with LOD (straight vs 45 deg).
  • I’ve also commented on another bug where aircraft tail light is not visible in one eye in VR.
  • I’ve also reported this is also very easy to repro with the 787

In the past, I’ve also sent a PM to an Asobo developer a while back, about another bug showing up easily in the CJ4 (see “Opaque quads protruding from the cabin window depending on view angle” below). When looking back the cabin from the cockpit at night, where you can see semi-transparent dark quads protruding from the cabin windows

Yesterday I’ve seen these bugs are still present but I came to realizing they might all be rooted to the Shader code handling and use of the viewdir vector (directly or indirectly) and I’m further documenting it here.

Problems

There exists visual bugs which are solely dependent on the view dir vector and nothing else, and they most often than not exhibit themselves on the right eye only in VR.

The same visual bug can also be dependent on the combination of view dir and sun dir, and this shows especially well when looking at thin bright features in VR, like windmill poles. When lit by the sun, there are different view dir angle which are revealing (light) or masking (shadow) the pole in such a way they sometimes disappear from view or they are too faint.

Illustrations

When circling around the aircraft

Observe the shadow / light separation on the fuselage near the tail on the right eye view

  1. The shadow / light separation is rendering correctly:

  2. The shadow / light separation starts to hardening:

  3. The shadow / light separation is here completely sharp (but it is still located where it was before):

  4. The sharp edged shadow is now taking over the light area as we move around further:

  5. Here is has completely taken over and there is no light anymore on the tail:

When just turning the head to the right 45 deg

Observe the shadow / light separation on the fuselage near the tail on the right eye view

  1. Looking straight ahead:


    Looking to the right (this restores the proper shadow / light separation):

  2. Looking straight ahead:


    Looking to the right (this restores the proper shadow / light separation):

The Shader code in VR has a bug which doesn’t show in 3D!

Read the complete post for description and screenshots:

Repeating cycle of Shimmering pattern

Read the complete post for description and videos:

Other references

Opaque quads protruding from the cabin window depending on view angle

Airliner exterior lighting bug - #6 by CptLucky8

Distance based Object LOD selection wrong by 45 degrees (pictures)

LOD Problems - Distances revisited - #32 by CptLucky8

Distance based Lights visibility wrong by 45 degrees (pictures)

LOD Problems - Distances revisited - #38 by CptLucky8

Light visibility and size unexpectedly cut with zoom and angle

[no public link for this one]

Multiple items only render on one eye - Reflections on Windshield for example

[no public link for this one]


Do you have any add-ons in your Community folder? If yes, please remove and retest before posting.
Are you using Developer Mode or made changes in it?
PC specs for those who want to assist (if not entered in your profile)
Are you on the Steam or Microsoft Store version?
Did you submit this to Zendesk? If so, what is your ticket #?
n/a

Yeah this is really anoying this needs fixed ASAP

Here is a second series of screenshot illustrating another directly related problem:

The Shader code in VR has a bug which doesn’t show in 3D!

Look closely to the shadow as the view dir changes in 3D:





As you can see, regardless of the view direction, the shadow displays the same.

Now look closely to the same shadow but in VR this time:

NB: just look at the right eye picture, I’ve taken the screenshots so the the shadow is displaying around the edge.











As you can see, the shadow is completely dark when on the left edge of the view, and nearly completely transparent when on the right side of the view.

This is plain wrong and this is the reason I’ve been seeing a discrepency between both eyes for the last 6 months in clouds, in trees, and I suspect it is also the reason why for example thin masts are flickering and disappearing depending on the angle.

1 Like

false viewports

1 Like

To be honest, it also shows in the non vr view. It definitely is a bug imho, no doubt there. The difference i’m noticing it’s the effect is amplified in VR.

It definitely has to do with angle, as it looks like these shadows shaders are possibly getting the angle as an input var, as like you stated with other items (cloud, masts)?

It looks like to be an overall thing where there are possibly wrong (or intended) angle input parameters used because:

In the TBM when i zoom out in the cockpit like this:

in which i normally fly, i notice that at certain angles activated buttons are not lit anymore (autopilot, but also parking break). I’ve also seen papi lights change color when panning up or down from an apron.

So it looks like a general input somewhere in the code hierarchy already been passed on before it reaches any light/shadow shaders.

Edit: Will try to reproduce my TBM case and add it to this post. Give me couple of minutes.

Edit, watch the autopilot lights:

Straight:

Angle:

larger angle:

2 Likes

This is another bug to me, that I’ve documented here:

I have a fairly good idea about what is happening with this bug though, and like I told Jayne, I’d be very glad to discuss this directly with Asobo because I’ll probably lack the words in English and this will be easier and faster than writing this down anyhow.

1 Like

You are thinking of z-index fighting? (i know i do have these issues once in a while when calculated wrong :rofl:)

Cause that could also cause this if overlaying (possibly in this case a self emitting?) plane on top of an other object is not exactly placed.

I don’t think this has anything to do with Z fighting.

It is instead the consequences of they way they’re handling a certain engine logic which manifests the same here:

And which manifests itself for the same reasons to me, here:

I might be 100% wrong in my assumptions, but just from the visible effects, it all points in the same direction to me.

This example is from my experience when working with objects and planes. So, i could be completely wrong as i do not know how asobo has modelled this.

Well, what i see happening while moving, is that the light gets removed partly from top to bottom from my “sitting” angle

Quick example (don’t judge my gimp skills :smiley: ):

Looking at this from the side.
Red = object
Green = Emitting plane (object whatever :wink: ).

This is really overdone (especially the emitting plane’s angle), but hence by example. The distance between object and plane is (let’s do it in pixels for fun and keep it easy) on the top is 0.009 pixels and bottom is 0.010 (yes, below a whole pixel)
Top to bottom view angles horizontally (aprox):

top: 90°
middle: 40°
bottom: 45°

image

With every camera movement the position get’s a bit “adjusted” in this case it shifted let’s say 0.002 pixels, that’s with all objects. But if the spacing is so close, a small adjustment can make it appear/disappear. It needs to stay within the camera view, hence the camera is not ortho, so there are angles (sin/cosin with perspective camera, hence it comes back at bigger angles). This also happens when you zoom:

at 90 degrees (ish):

Do you notice the BC label disapeared? It “fell” back inside the BC button object.

But again. This is from my experience when layering planes on objects or having two objects placed exactly at the same spot (what do you show when they are exact placed?).

Now i think of it, z-index fighting feels like a plausible cause. because i did not notice before the BC label had dissapeared in previous views. It’s easily reproducible, just zoom out.

Edit:
When watched closely, you can see the plane/object when it’s emitting properties are turned off:

image

In below example i circled the self emitting plane/object

Zoomed in when lights present

Zoomed in when lights gone:

The plane/object, is gone/fell backwards/etc…

My appologies for hijacking because of my earlier brainfart.

It could be Z fighting but I doubt it, and this is why:

NB: following the sequence of images here: LOD Problems - Distances revisited - post #38

  1. The Anti-Ice panel lights hides when looking straight to them:
  2. Unless you’re leaning forward and getting much closer:
  3. However, should you look 45deg away the lights show up (lights near the view edge):
  4. And they still show up even if leaning backward farther away:
  5. when I look at the the ground texture distances problem I’ve documented, the building windows problem, and the trees problems

Therefore I believe it is a more general problem in the way distances vs visibility is computed in the simulator, and actually it was a recent comment from Sebastian’s in a Q&A which is confirming me exactly what the problem is, and because of its nature, Asobo might not see this as a bug per-se. To me it is just the side effect of a design decision which nonetheless shows up as a rendering bug in practice.

1 Like

Just tested, LOD 9. Exact same behaviour.

I checked the other post and understand the logarithmic calculation.

There is one thing, all items bound to the logarithmic value are still in relation to eachother. Which means the relation between object sizes, distances and calculations all stay in equal relation as it’s al based on that one single factor.

If i have objects within a group, and i change the lod of that group, all objects inherrit the same lod properties. An airplane is a group of objects. Even when it’s all bigger, everything grows equal within that group. When scaled down to respect the viewport/distance from eye in relation to world placement (albeit with more detail because of higher LOD), everything is exactly the same size/distance etc as if it would had lod 1.

But again, it’s my experience when doing 3D views. So i can still be utterly wrong here :smiley: as i do not know asobo’s approach.

P.S. which part of the interview are you refering to?

Edit: I think we are talking about the same thing, z-index fighting is a result of object placement :woozy_face:

This is confusing me and I think I’ll confuse the reader of this topic too if I try :rofl: But from what I can understand you’re pointing to something which is not working as you’d expect here. I believe I’d probably explain this better in French on the phone with Sebastian, than trying to write it down in the forum too.

1 Like

I’ve posted the following in another topic today, but I’m posting it here as well because although these are illustrating the shimmering introduced with SU5, these are also illustrative of this topic because this shimmering is showing up with a different phase between both eyes and this is really altering the VR experience.

NB: these are shots with a camera on the unscaled VR view displaying on the monitor (they are not screen captures) and they are exactly representing what I can see through the lenses.

First case: shimmering on buildings:

You can clearly see in this video the shimmering on small buildings. What you can’t see much, because I had to cut the video for posting, is that the shimmering is showing a pattern repeating in a cycle.

Also worth noting, near the group of buildings located 1/4th of the frame from the left, and 1/2 of the frame from the top, is that only the smallest buildings edges are shimmering but not so much on the larger buildings.

Second case: shimmering specular/reflections:

NB: Please pay attention to these two specific locations:

Besides the same shimmering on the buildings like in the previous video, you can also clearly see how the specular and/or reflection is showing a pattern repeating in a cycle too.

Hope this helps!

1 Like

Thank you for noticing this. This probably explains the AA downgrade people are claiming. TAA wasn’t touched in SU5, it was actually this other issue causing problems. I’ve also noticed the odd behaviors you describe in VR since it was first released. Perhaps it also explains why turning you head to look at a parked plane sitting next to you shows the windows of the parked plane changing appearance (as if you can partly see the plane interior and then you can’t) or seeing part of a tree disappear and reappear out of the corner of your eye while you turn your head. Would this also be responsible for landing gear not appearing on autogen parked airplanes until you’re almost on top of them? Or is that a separate issue with LOD distance switching? I don’t notice the phenomenon in 2D, only in VR. It’s things like these that ruin the suspension of disbelief in VR (photogrammetry popping in and out constantly under your plane is another one).

1 Like

I’ve noticed that light pollution rendering is totally messed up in the right eye. Light pollution changes depending on the angle of your headset, maybe my post should be merged :

1 Like