Compatibility OmniLight turns everything green, only for XRCamera

[Fire551]

Tested versions

reproducible in 4.2.1 and 4.3-dev6 at the least

System information

Windows 10, i5, Geforce 1070, as well as tested on quest3 (BUILD)

Issue description

do you guys know of a green-shifting error with omnilights in the compatability renderer, only caused with a xr camera?

• error disappears in other renderers.
• only with a xr camera, uses only a origin, a camera, and the given xrtools starter
• tested in different scenes, tested in different project but with the same assets and
• only with omnilights
• anything in its affecting range is shifted green (albedo wise. acts like any color, alpha and darkness affect it)
• only caused when it has a procedural skybox or fog (sky affect to 0 has no affect)
  (custom color and clear color is fine, but fog breaks it if enabled)
• i dont seem to notice any abnormal choices pertaining to rendering in settings
• havent tested cross-devices (but builds have been tested on a quest 3, no difference)
• seems to happen to all shaders in 3d-space atleast
• light doesnt actually emit when error. 😕
• disabled ambient and reflected light has no affect
• disabling fog in the MATERIAL, does not stop the issue in its respective edgecase

PICTURE NOTE : the directional light is fine, i had it turned off to notice the omnilight easier in these pictures. it doesnt seem to affect the bug. also if it was off for the skybox-only it would've been pitch black. the omnilight is on in all these pictures

Steps to reproduce

• use compatability renderer
• use monolight in a scene.
• have fog or procedural sky enabled
• have xrcamera rendering

thats the best i got for ya :/

Minimal reproduction project (MRP)

how the hell do i fit this in 10Mb???

https://drive.google.com/file/d/1CKaiCyspeKlmJxetN3smaXchhZn4tPtQ/view?usp=sharing

[BastiaanOlij]

Still no clue whats causing this, but was able to reproduce this without needing XR hardware:
StereoFogOmniBug.zip

[BastiaanOlij]

This took a lot of puzzling but I found it:

For sky we are using uniform location 4 and optionally 5 for respectively out directional light buffer and our multiview buffer.
In our scene shader we've reserved uniform location 4: SCENE_EMPTY, // Unused, put here to avoid conflicts with SKY_DIRECTIONAL_LIGHT_UNIFORM_LOCATION.
But uniform location 5 is our omni light buffer.

Ergo, in multiview we're using the wrong buffer

[Fire551]

opened the project on my end using 4.2, it was still green, checked again on 4.3, it was blue. downgraded to 4.1, it was green.

heres 4.1

how has this never been brought up in detail?? this is such a blatant visual error. wouldn't almost every quest3 dev run into this??

i noticed it doesnt cause a change on a albedo color of (0,0,255) like the grass, but when using a value of (255, 255, 0) it darkens the color?? what operation can cause this?? some kind of averaging?

this is light on

this is light off

back to 4.3
which seems to be different from yours, where it makes it glow.
also worthwhile noting that the grass still isnt affected

weirdly enough ive noticed something.
so apparently, the bug acts completely different depending if shadows are enabled, it seems to be an "additive" force only to anything with a blue hue. affects end result of albedo

[BastiaanOlij]

@Fire551 basically it was just getting junk data for Omni lights, using multiview data from the sky shader instead. So the output will be very unpredictable but definitely completely wrong.
I'm pretty sure this bug goes all the way back to Godot 4.0.