OpenMW 0.48.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
mikeprichard
Posts: 113
Joined: 16 Dec 2018, 19:42

Re: OpenMW 0.48.0

Post by mikeprichard »

Amgarrak wrote: 13 Nov 2021, 08:39 No it's not a Lua mod that's what's on the second screenshot https://www.nexusmods.com/morrowind/mod ... posts&BH=9
It's understood that MCP itself is not a Lua mod - it was built for vanilla Morrowind. What the developers are saying is that for OpenMW specifically, they will prefer to separate MCP-type features into Lua mod(s) when such are able to be developed, rather than include MCP-type features in core OpenMW. I myself look forward to the day I can play OpenMW with a full suite of MCP features (through Lua modding)!
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

We also need to have a heart to heart talk with those on macOS and the future of OpenMW.

It's getting more difficult to develop new features and improve existing ones because of the sad state of OpenGL on macOS. With that sad, we have literally no one developing on macOS; it's purely through testers that we know if something is broken or doesn't work. Example: "shader compatibility" mode for Lighting on macOS and the workaround to have shadows working which isn't as performant as on Linux or Windows.

The future of OpenMW on macOS is in jeopardy because: opengl is deprecated (no long being worked on/improved) and no official vulkan support with no real FOSS alternative we can use to bridge this.

The last things we can try are:
* GLESv3 support
* Zink OpenGL over MoltenVK
* native VSG renderer over MoltenVK

In progressive levels of difficulty. So while we continue forward, we'll do our best but it would be nice if we had someone to really champion macOS and help guide development there.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: OpenMW 0.48.0

Post by AnyOldName3 »

Specifically with GLES, it'd need to go via ANGLE, so it'd still be via a compatibility layer. Anything would require a compatibility layer except a direct Metal backend, and that's way out of reach considering how few people actually care about OpenMW working on MacOS.

The other option is to make lots of noise so Apple start taking driver bugs seriously. They bothered writing OpenGL drivers for their M1 hardware, which shows that they do recognise that they can't totally get rid of it yet. I'm not sure we can actually make enough noise to talk them into fixing a single bug, though.

If Zink actually works for the OpenGL features we use, then theoretically it's the only solution that requires no work on our end (except paying to licence MoltenGL). Someone (even if they're not a team member and just own a Mac) could perhaps try that, and if they hit issues, report them to Zink as Zink's developers will be at least a little bit interested in fixing them.
User avatar
wazabear
Posts: 96
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: OpenMW 0.48.0

Post by wazabear »

Just so it's clear, UBOs aren't usable on Macs right now because of a missing extension. The feature is core in OpenGL 3.1, so if we can run such a context we can use any feature that utilizes UBOs. Right now it's only the one lighting mode, but we'll likely be using a lot more of them for other things such as uploading materials, common matrices, etc.... This becomes more relevant when we talk about being able to run a core 3.x context with lots of OpenGL FFP state unavailable to us.

As for a native Vulkan rendering backend, is that realistic in any relevant timeframe? Even though I'm not a fan of VSG it's likely only way forward with this, especially since we don't have any developers familiar with Vulkan. I've heard it should be releasing within 2022 but I don't know how true that is. If VSG has a stable release within the next years, is OpenMW willing to move forward with the switch, is it too early to say anything? I am writing this under the assumption that if we moved to Vulkan then this would mean ditching the OpenGL renderer, what would this mean for the devices we support right now?
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

I was under the impression by people who know OSG and VSG pretty well that if we can put more trust into those systems doing the things we want instead of bypassing them; that we can abstract enough away that we can have have both OSG and VSG support in OpenMW.

That being said, I do not see that anywhere in our immediately future: 0.48 nor 0.49
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: OpenMW 0.48.0

Post by AnyOldName3 »

In some respects, the porting work between OGRE and OSG is smaller than it would be between OSG and VSG. If we put OSG in charge of everything, it would be relatively simple to port it, but kind of in the same way as if you make a job so simple a two-year-old can do it, you can swap out the two-year-old - most jobs are too complicated for a toddler, so it's a moot discussion. OSG gives you object-oriented ways to manage the lifetime of OpenGL state and a more intuitive way of representing that state and ensuring it gets set up correctly when you need it, but it doesn't magically decide what state you actually need for anything particularly complicated (OGRE actually did, at least a bit, which is part of why we had to stop using it - it would pick nearly what we needed and then offered very little scope for customising further, so we needed a library that let us do everything ourselves). The hard parts are all going to be wildly different for OSG and VSG.
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

Quite true, but many of the features that have been added, like Shadows, Lighting, etc are probably not in scope of any initial work on having a 2nd renderer. It's feasible to get enough things abstracted that both the current OSG renderer can keep working and a basic (no feature, no frills) VSG renderer can be added. At least that would be the path of least resistance.

I'm strongly against dropping OSG wholesale.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: OpenMW 0.48.0

Post by akortunov »

I am not sure if it is a good idea to support different rendering backends - it will require a lot of manpower to implement and will make rendering subsystem more complex and less maintainable. OpenMW is a quite specific project with relatively small amount of users and contributors, so it more likely will be just a waste of time.
User avatar
wazabear
Posts: 96
Joined: 13 May 2020, 19:31
Gitlab profile: https://gitlab.com/glassmancody.info

Re: OpenMW 0.48.0

Post by wazabear »

Of course you can add heavy abstractions to our interfaces, but that doesn't change the fact you'll need to be maintaining literally double implementations for every feature. A quick look at the VSG interface and examples confirm that VSG is far from a drop in replacement for OSG (which is to be expected).
User avatar
psi29a
Posts: 5355
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.48.0

Post by psi29a »

Sooner or later we'll need to switch over to Vulkan, Apple already had the balls drop 32-bit support which cut support for old games. It's only a matter of time before they cut OpenGL support as well.

That being said, Linux distros are usually pretty stubborn so OpenGL will be around for another decade at least.
Post Reply