0.47 lighting issue

Support for running, installing or compiling OpenMW

Before you submit a bug report for the first time, please read: Bug reporting guidelines
User avatar
wazabear
Posts: 96
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: 0.47 lighting issue

Post by wazabear »

Oh well, I should have known.
akortunov wrote: 17 Jun 2021, 17:34 As for me, it looks similar to red objects when using shadows on ARM (due to bug in GPU driver), which we had in the past.
So this was fixed, any relevant MRs? If errors are so similar might put me on right track at least.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: 0.47 lighting issue

Post by akortunov »

It was this merge request, mentioned in this thread (there is a screenshot with red sky in this thread).
As I understood, the issue is that ARM can store data components in a different order, what can cause such kind of issues. Despite that issue was on Linux arm, not on a Mac one, there can be something similar which causes this bug.
User avatar
Bessarion
Posts: 12
Joined: 08 Nov 2016, 20:02

Re: 0.47 lighting issue

Post by Bessarion »

I just found that on unmodded OpenMW RC5 + MacOS 11.4 + MacBook Pro M1, if I set the Lighting Method setting to "Legacy", that resolves this issue. Not sure if anyone changed something between RC1 and RC5, since I think another user already tried this setting... but anyway it works for me!
User avatar
wazabear
Posts: 96
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: 0.47 lighting issue

Post by wazabear »

An API trace would be *extremely* helpful, if it's possible.
User avatar
Bessarion
Posts: 12
Joined: 08 Nov 2016, 20:02

Re: 0.47 lighting issue

Post by Bessarion »

OK. The only instructions I can find for that when searching here look Windows-specific. Any idea how I would go about doing it on MacOS?
Kflip101
Posts: 1
Joined: 06 Nov 2021, 20:21

Re: 0.47 lighting issue

Post by Kflip101 »

Started OpenMW for first time and got this issue. Have 2020 MacBook Pro M1 for reference. Issue happened on water textures and other random textures like doors, people, etc. First thing i did was activated water shaders, that fixed the water but nothing else. Then changed lighting method to legacy and that fixed everything. For sanity i swapped the water shaders back off and issue did not return with legacy lighting mode.

I hope the dev team doesn't put this bug aside simply because its a non-intel based mac seeing how Apple is heavily invested in M1 CPUs now. But in the meantime theres a temp fix for this! :)
User avatar
wazabear
Posts: 96
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: 0.47 lighting issue

Post by wazabear »

If you'd like to use the other lighting mode you can enable per pixel lighting, which should fix the red tint.
User avatar
AnyOldName3
Posts: 2667
Joined: 26 Nov 2015, 03:25

Re: 0.47 lighting issue

Post by AnyOldName3 »

The gist of the situation is that it's Apple's OpenGL implementation that's buggy, not OpenMW. Because Apple aren't very heavily invested into making OpenGL work properly on their M1 devices (even less so than all their other devices for the last decade) there are some features that are totally absent, and some that do the wrong thing. We do our best to avoid using those features on Macs, but sometimes that's a massive pain or we don't have an alternative available. If Apple fixed their drivers, we wouldn't need to change anything on our end.
darkbasic
Posts: 153
Joined: 18 Apr 2016, 15:45
Contact:

Re: 0.47 lighting issue

Post by darkbasic »

Why not Zink over MoltenVK? It's should be way better than Apple's OpenGL implementation.
User avatar
AnyOldName3
Posts: 2667
Joined: 26 Nov 2015, 03:25

Re: 0.47 lighting issue

Post by AnyOldName3 »

Zink isn't perfect yet (not all features work yet, although a lot more than a year or two ago, and it's still slow in some situations), so it might end up being worse than what we get now. The big hurdle, though, is that none of our devs with access to a Mac and the relevant experience see it as a particular priority. E.g. I've got access to a work Mac, but it's so slow it can't even run its own OS, so I avoid using it as much as possible.
Post Reply