OpenMW 0.47.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
Post Reply
User avatar
psi29a
Posts: 4857
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

OpenMW 0.47.0

Post by psi29a » 16 Jun 2020, 14:23

The new discussion thread for OpenMW 0.47.0, I've listed some topics worth discussing below. People are going to work on what they think is important and what they like. I'm going to try my best to single out things that get OpenMW closer to 1.0.

General:
* Shorting our dev/release cycle to either 4 to 6 months.
* De-coupling OpenMW-CS from OpenMW; we shouldn't unnecessarily delay release of OpenMW 1.0 in waiting for OpenMW-CS to 'catch-up' in terms of usability.
* Roadmapping future; path to 1.0

Below are things currently talked about are:

OpenMW:
* Working through existing 1.0 related issues https://gitlab.com/OpenMW/openmw/-/issu ... name[]=1.0
* Lighting issues has become more noticeable; there is a WIP branch that needs love
* Fading of assets instead of popping for Object Paging
* Further work on NIF support
* Collada support either native or via osgAnimation (perhaps worked on in 0.47 but won't be ready until 0.48)
* Basic Lua support (perhaps worked on in 0.47, but won't' be ready until 0.48)
* ...

OpenMW-CS:
* UI/UX fixes
* (need to hear back form those working on this)
* ...

I've recently had talk with TR people about their 'wishlist' and they pointed to this little bit here:
https://www.tamriel-rebuilt.org/about/f ... goalopenmw
Q: Will Tamriel Rebuilt become OpenMW-exclusive?
Possibly, but not anytime soon.
Several possible scenarios exist when such a move would be seriously considered:
  • The file size of our mod becomes too large for the Morrowind executable to handle, when even splitting it into several files no longer works,
  • OpenMW becomes the overwhelming standard engine to play Morrowind in,
  • OpenMW reaches features parity with MWSE-Lua and adds additional killer features (such as per-cell water levels in exteriors)
Perhaps we can't do much about #1, but perhaps things such as per-cell water levels in exteriors, that we can cover ground there.

CMAugust
Posts: 242
Joined: 10 Jan 2016, 00:13

Re: OpenMW 0.47.0

Post by CMAugust » 16 Jun 2020, 14:33

Per-cell water levels make a lot more sense in Oblivion, Fallout and Skyrim, where cells are 4096x4096 in size. It's impossible to recreate the same landscape with 8192x8192 cells. Perhaps something more sophisticated is needed, like water volumes independent from cells, so that landscaping is not hamstrung by cell size.

User avatar
psi29a
Posts: 4857
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.47.0

Post by psi29a » 16 Jun 2020, 14:57

Would resampling 8192x8192 cells in such a ways that we get to 4096x4096? That would normalise terrain to be consistent with later games.

I'm curious how it is handled in cc9cii fork.

User avatar
AnyOldName3
Posts: 1854
Joined: 26 Nov 2015, 03:25

Re: OpenMW 0.47.0

Post by AnyOldName3 » 16 Jun 2020, 15:26

I think it's reasonably likely a lot of our water shader would have to go or be changed significantly to support per-cell water levels. Later games use the cell's environment map and (just for the nearest cell(s)) a cubemap RTT (updated two faces per frame) with basic contents of the game world blended together, so their reflections are a lot less accurate than ours. We don't even have environment maps with enough frequency, so we'd be completely without anything to reflect for most of the water. Also, their refraction is done completely differently to ours.
AnyOldName3, Master of Shadows

CMAugust
Posts: 242
Joined: 10 Jan 2016, 00:13

Re: OpenMW 0.47.0

Post by CMAugust » 17 Jun 2020, 04:10

Aside from doing what Bethesda did (which is as likely as not), if someone knows any relevant alternatives in the wild that allow multiple water heights in the worldspace, post it here. :)

User avatar
heilkitty
Posts: 143
Joined: 11 Aug 2011, 07:57
Location: Vivec City, MW
Contact:

Re: OpenMW 0.47.0

Post by heilkitty » 17 Jun 2020, 04:55

To the east of Ald Mirathi there's a multiple level waterfall, which don't look like a waterfall at all to me (at least, in OpenMW, haven't tried vanilla MW), and I don't think, that "water level per cell" would be suitable for this use-case, "water volumes independent from cells" would be better, IMHO.
Also, in any case, that would require "omwmod" format change, so it wouldn't be compatible with vanilla no more.
In Soviet MoЯЯowind, Almalexia kills YOU!!

CMAugust
Posts: 242
Joined: 10 Jan 2016, 00:13

Re: OpenMW 0.47.0

Post by CMAugust » 17 Jun 2020, 05:32

Yes, this is something TR listed as a "killer feature" that may compel them to become OpenMW-exclusive, because the benefits are so great. But whether it could, or should, work as in later Bethesda games is uncertain.
psi29a wrote:
16 Jun 2020, 14:57
Would resampling 8192x8192 cells in such a ways that we get to 4096x4096? That would normalise terrain to be consistent with later games.

I'm curious how it is handled in cc9cii fork.
As for why Bethesda changed cell sizes in the first place and whether OpenMW should do the same, I'll let scrawl do the talking:
They've probably changed it because there are more objects in those games compared to Morrowind's sparsely populated landscape, and they tested the number that actually works best for each game. Smaller cells doesn't necessarily mean better performance, because you'll have more overhead traversing each cell, figuring out which cells are active, finding which cell an object is in, etc. Another variable is the culling granularity, which is currently tied to a cell (i.e. if an entire cell's bounds aren't in the view frustum, the culling stage can skip it).

It's difficult to change the cell size after the fact, because the data files are organised according to it. To get the full benefit (if there is one) we'd have to re-save Morrowind.esm according to the new structure. And that is problematic, because we know there are some shoddy scripts/quests/other situations that will break if a cell is loaded sooner or later than it would normally be.
We might add water level granularity as another possible reason they shrank the cell sizes. And scrawl, too, was only guessing. Maybe things will become a bit more clear, now that its potentially relevant for future water height support.

User avatar
Baler
Posts: 1
Joined: 18 Jun 2020, 12:12

Re: OpenMW 0.47.0

Post by Baler » 18 Jun 2020, 12:20

Just rediscovered this project today. Really blown away that it's still being developed and in such rapid form.
Thanks to all the devs and contributors who have made this possible. Please excuse me I need to explore some openmw :)

User avatar
Greendogo
Posts: 1436
Joined: 26 Aug 2011, 02:04

Re: OpenMW 0.47.0

Post by Greendogo » 26 Jun 2020, 07:19

From the other 0.47.0 thread
Is any work on the Gamepad UI likely to be worked on for 0.47?

onionland
Posts: 68
Joined: 29 Jul 2014, 00:43

Re: OpenMW 0.47.0

Post by onionland » 27 Jun 2020, 22:13

Greendogo wrote:
26 Jun 2020, 07:19
From the other 0.47.0 thread
I think it was mentioned in another thread about it (that or the github) that to get it to work nicely some de-hardcoding of the UI needed to be done first

Post Reply