openmw.org

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.

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.

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!

An API trace would be *extremely* helpful, if it's possible.

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?

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!

If you'd like to use the other lighting mode you can enable per pixel lighting, which should fix the red tint.

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.

Why not Zink over MoltenVK? It's should be way better than Apple's OpenGL implementation.

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.