search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.21k stars 21.04k forks source link

Lights do not work correctly in Compatibility renderer #85567

Open jhocking opened 10 months ago

jhocking commented 10 months ago

Godot version

4.2 (today's release)

System information

macOS 10.13.6 on 2017 Macbook Air

Issue description

Both directional and omni lights behave oddly for me. I am using an older computer that requires Compatibility mode. I made a simple scene with a character for testing.

To start with, I put in a directional light pointed at the character. When I only rotate the light on the X axis, no light appears in the play scene direct1 direct2

Now I rotate the light on all axes, and light suddenly appears in the scene. direct3 direct4

The light is still pretty dim though, considering it's facing the front of the character. I set the material to Unlit for comparison. unlit1 unlit2

Anyway that's all with a directional light. Now I turned that off to test an omni light instead. Here it is with the default range value: omni1 omni2

Perhaps I'm misunderstanding that value, but here it is after increasing the range. Note the lighting looks exactly the same: omni3 omni4

Given that I require Compatibility renderer on this computer, I'm certainly looking forward to lighting improvements, plus the addition of shadows!

Steps to reproduce

Reproduction steps are part of the issue description. In summary, with the Compatibility renderer active I tested out both directional and omni lights, and they did not behave correctly.

Minimal reproduction project

FirstTest.zip

clayjohn commented 10 months ago

Can you post the errors you get when running the scene? Its very strange that the DirectionLight3D appears to work in the editor, but not at runtime.

Also note, shadows are already supported in the compatibility renderer.

jhocking commented 10 months ago

@clayjohn Awesome that shadows are now supported in this renderer, although they aren't working for me (presumably because lights in general aren't working). The errors I see:

E 0:00:00:0092 _get_gldisplay_id: Can't create an EGL display. <C++ Error> Condition "new_gldisplay.egl_display == (static_cast(0))" is true. Returning: -1 <C++ Source> drivers/egl/egl_manager.cpp:65 @ _get_gldisplay_id() W 0:00:00:0092 DisplayServerMacOS: Your video card drivers seem not to support the required Metal version, switching to native OpenGL. <C++ Source> platform/macos/display_server_macos.mm:4528 @ DisplayServerMacOS() lighting-error

clayjohn commented 10 months ago

Can you try switching your rendering backend from gl_angle to OpenGL?

It seems like your device is too old to support using Metal (Apple's graphics API), so you need to be using OpenGL (which is deprecated on newer Apple devices)

jhocking commented 10 months ago

How do I switch that? Would it be under System Preferences or something?

That this device is so old Apple considers it deprecated is not surprising (it's from 2017 after all) but I can use other game dev tools on this so I figured Godot would be fine. Perhaps I should downgrade to using version 3...

EDIT: I'm no expert on graphics APIs, but the warning looks like it's switching to OpenGL already. It's just that it hits the error first, so perhaps some compatibility check needs to happen earlier?

Calinou commented 10 months ago

Perhaps I'm misunderstanding that value, but here it is after increasing the range. Note the lighting looks exactly the same:

Light range is only part of the equation. The amount of light received by a surface also depends on its angle (normal) relative to the light. Try moving the OmniLight further up from the ground while increasing its range, or increase its energy.

jhocking commented 10 months ago

@Calinou thanks for the suggestion, but it looks like this issue is more fundamental than that, since there is an error with creating a display surface.

Incidentally, this whole issue is making me think "y'know, maybe I should just buy a new computer". I mean, this one is pretty old, older than I really realized until I started gathering specs for this report.

On the other hand, I don't have issues with other 3D apps I use on this computer, and I'm not going to buy a whole new computer for just one app. Like, I'm investigating switching to Godot from Unity, and that works fine. I also use Blender just fine.

jhocking commented 10 months ago

Update: just noticed 4.2.1 is out so I installed that to test this. Those error messages don't display anymore, but lighting still doesn't work (still behaves like the original report)

jhocking commented 10 months ago

@clayjohn hm I just tried a web build to test on itch.io, and it looks like lighting wasn't working there either. Has anyone else tested a web build from 4.2? Maybe I'm just missing some crucial setting that others know about...

fyi for it to work on itch.io: I had to rename the html file to index.html, and I had to turn on SharedArrayBuffer

This may mean this issue is more significant than I realized. When I assumed it was because of my old computer, well it'd be nice to fix but not really affecting anyone else. However if the web builds don't work on itch (or at all) that's a problem many people would hit.

If you want to see it live, it's at https://jhocking.itch.io/godot-test (pw godot-test) What I see is just like the 4th screenshot above, but perhaps it looks different in different browers.

Calinou commented 10 months ago

This may mean this issue is more significant than I realized. When I assumed it was because of my old computer, well it'd be nice to fix but not really affecting anyone else. However if the web builds don't work on itch (or at all) that's a problem many people would hit.

Threads are currently a hard requirement for web exports to work. They won't work on macOS Safari on itch.io because Safari doesn't support coep:credentialless, which is required for the SharedArrayBuffer headers to be taken into account there.

https://github.com/godotengine/godot/pull/85939 adds an option to lift the threads requirement for web exports (like in 3.x), but it will be slower and suffer from high audio latency.

jhocking commented 10 months ago

ah that's good to know, explains why it isn't working in Safari. However it does work in Chrome, with the busted lighting.

clayjohn commented 10 months ago

@clayjohn hm I just tried a web build to test on itch.io, and it looks like lighting wasn't working there either. Has anyone else tested a web build from 4.2? Maybe I'm just missing some crucial setting that others know about...

fyi for it to work on itch.io: I had to rename the html file to index.html, and I had to turn on SharedArrayBuffer

This may mean this issue is more significant than I realized. When I assumed it was because of my old computer, well it'd be nice to fix but not really affecting anyone else. However if the web builds don't work on itch (or at all) that's a problem many people would hit.

If you want to see it live, it's at https://jhocking.itch.io/godot-test (pw godot-test) What I see is just like the 4th screenshot above, but perhaps it looks different in different browers.

I tested the web build and the local build and I can't reproduce the issue. The DirectionalLight works fine in both cases.

Of course that isn't a surprise as this is most likely an issue only on Mac devices and likely only on your specific driver version (as users on newer devices aren't experiencing the same issue).

It would be helpful for us to have more mac users test this out so we can hopefully begin to narrow down what is causing the issue. Mac OpenGL drivers have been broken for years now (they were deprecated a long time ago). So the trick for us is figuring out workarounds to avoid driver bugs. Which can be really hard as most of us don't have Apple devices.

ANGLE is a nice workaround, but it is only viable for slightly newer mac devices that support Metal. Apple is, of course, no help. They only want to support Metal going forward and have totally abandoned OpenGL (to the point that they are even getting rid of the only tools that we can use to debug OpenGL on Macs)

jhocking commented 10 months ago

Well I got a newer computer and the lighting looks good now (correct brightness, shadows work) so as far as I'm concerned this issue is done. If you want me to test more on my older machine well I still have it, but otherwise feel free to close this as Won't Fix.

For reference, this computer is still not super new (2020 13" Apple MacBook Air M1 Sonoma, but I saw a great deal) so a nice reference for how old of a computer will work.

clayjohn commented 10 months ago

Well I got a newer computer and the lighting looks good now (correct brightness, shadows work) so as far as I'm concerned this issue is done. If you want me to test more on my older machine well I still have it, but otherwise feel free to close this as Won't Fix.

For reference, this computer is still not super new (2020 13" Apple MacBook Air M1 Sonoma, but I saw a great deal) so a nice reference for how old of a computer will work.

Thanks for updating. I'd appreciate if you still kept the computer around for testing when we have relevant changes. Much older MacBooks are working quite well, so it's not simply that this one is too old.

Right now I have no good theory for what is causing this issue, but we might figure something out as we improve MacOS support