Distant Land: where to next?

Everything about development and the OpenMW source code.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Distant Land: where to next?

Post by CMAugust »

This year object Paging has been successfully implemented and is a major visual milestone for OpenMW. This thread is to lay out some of the discussion on how it could evolve in the future.

First, to make myself clear: Object Paging is amazing. This topic however is entirely focused on how it can be bettered in the future, and that means talking about weaknesses that exist as they are now, whether due to paging itself or other factors. Mostly, this relates to scalability. At default settings, the current distant terrain system performs well with x5 cells, and still ok with x10 cells. For the traditional Morrowind user base, this is more than enough. But if you want viewing distance comparable to Oblivion or Skyrim (about x40 Morrowind-sized cells), that's a different story. Initial loading time exponentially increases, and fps drops well below what would be acceptable. At the moment, aside from increasing the object paging min size setting to reduce the amount of objects being drawn, there's not much else that can be done by OpenMW itself.

The favored solution to this (spoken by psi29a and AnyOldName3) is for users to add NiLODNode to existing morrowind objects, which swaps the high-detail mesh with a low-detail one at greater distances. To test this, I created an experimental plugin adding these to a variety of the common medium and large-sized objects across morrowind. The initial results (1, 2), however, were mixed: while it dramatically reduced the triangle count in test scenes, the number of drawables (and hence the average framerate) was barely affected. On the face of it, it seemed that object paging had already done the best it could, with the introduction of simplified meshes a nearly superfluous extra step. Handy if you were GPU-limited, less so for any significant reduction in draw time. In addition, the use of NiLODNode does not address the issue of long load times.

The second limitation relates to user-authored LOD as well. If one is using a higher object paging min size to maintain decent performance at high viewing distance, they will see large sections of buildings or entire towns disappear - landmarks you'd want to make sure are visible from any distance. The trouble is that many of these structures are in fact a composite of smaller objects pieced together like Lego bricks, and the object paging has no inkling of which objects should be treated as part of a cohesive whole. The proposed solution (by AnyOldName3) again involves NiLODNode, this time by placing a .nif featuring a consolidated mesh (whether it's a castle, village, etc) as a distant LOD level, so that it vanishes when the player is close enough to load the real thing. Unfortunately, NiLODNode and object paging do not talk to each other in this way, and it's hard to see how the distant mesh could appear or vanish at the appropriate time.

I have my own ideas, in which a cell or any number of selected objects could be flagged in OpenMW-CS to be rendered regardless of the object paging min size, but so far this idea has been met with little enthusiasm.

That being said, what follows is a valuable pool of insights, collated from Discord (with minor edits for readibility), distilling a number of developer's thoughts on how they see distant terrain and where it could go in the future.

Bold text is myself unless otherwise noted.

How have others fared with this NiLODNode test plugin?
Spoiler: Show
What about generating separate, bespoke meshes to be used for distant objects?
Spoiler: Show
Any other interesting tech that could help?
Spoiler: Show
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

CMAugust wrote: 10 Dec 2020, 13:17 But if you want viewing distance comparable to Oblivion or Skyrim (about x40 Morrowind-sized cells), that's a different story.
It is 6561 loaded cells, which is much larger than whole Vvardenfell. Dynamic paging will take ages to build pages with such count of loaded cells, even with simplified meshes, so more likely you will need to switch to static paging, as in Skyrim or MGE. The main issue here - OpenMW has a NIF reader, but does not have a NIF writer. The same issue is the blocker for mesh simplification so far.
CMAugust wrote: 10 Dec 2020, 13:17 while it dramatically reduced the triangle count in test scenes, the number of drawables (and hence the average framerate) was barely affected
A fully expected behaviour, if your LOD nodes have the same amount of shapes as the common mesh.
Also remember that ObjectPaging can not merge objects with different states (e.g. with different materials or textures), so with large viewing distance you will end up with large amount of different shapes and textures, and it will cause a large amount of draw calls. You will need to use additional optimization techniques for pages generation, e.g. texture atlases.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: Distant Land: where to next?

Post by CMAugust »

The provided example .zip does indeed atlas some tree and rock sets, though it didn't make much of a difference, as you can see.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

CMAugust wrote: 10 Dec 2020, 14:20 The provided example .zip does indeed atlas some tree and rock sets, though it didn't make much of a difference, as you can see.
Well, it is enough to make that "barely" difference.
An every chunk is independent in ObjectPaging. For example, if you have a mean value - 2 chunks per cell - and have 6000 loaded cells (a 40 cells viewing distance), you will have 12000*count_of_unique_meshes draw calls, plus additional ones for shadows.
It is just an example, though, real numbers may be very different (due to different amount of chunks), but even with several hundreds of chunks and unlimited shadows distance profiler will show thousands of draw calls.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

Regarding saving/caching stuff to disk, there's no particular reason that should be done as a Nif. There used to be a couple of PRs open on GitHub despite no one touching them for years. One added and registered serialisers and deserialisers for all our custom OSG types so they could be saved to and loaded from osgt and osgb files, but that fizzled out because people realised that the osgt serialiser is significantly slower than a standard YAML/JSON one, and the osgb one's slower than a standard binary one. Someone came up with another that serialised things with an off-the-shelf binary serialisation library and it was faster, but it also fizzled out because then OpenMW would be adding to the huge mess of existing mesh formats. I think this was around the time that glTF and openGEX were appearing, so there was maybe some hope that they could be used.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

Regarding chunk size, I was under the impression object paging chunks were held in a quad tree, with four-cell chunks being used beyond a certain distance, and sixteen-cell chunks beyond that. That's how the chunks work for the terrain system.
CMAugust
Posts: 285
Joined: 10 Jan 2016, 00:13

Re: Distant Land: where to next?

Post by CMAugust »

AnyOldName3 wrote: 10 Dec 2020, 15:25 Regarding chunk size, I was under the impression object paging chunks were held in a quad tree, with four-cell chunks being used beyond a certain distance, and sixteen-cell chunks beyond that. That's how the chunks work for the terrain system.
That's exactly what I thought too; it doesn't make sense otherwise. I suppose that can be confirmed via Apitrace or something.
Unless I'm mistaken, if those four-cell and sixteen-cell chunks could be saved to disk and called when appropriate, that would hugely reduce the loading time.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Distant Land: where to next?

Post by akortunov »

AnyOldName3 wrote: 10 Dec 2020, 15:25 That's how the chunks work for the terrain system.
That's why I use the "mean value" term in example to explain why there are thousands of draw calls even with paging.
BTW, every 16-cells chunk more likely will contain meshes from different tilesets, so it still will consist of many drawables.
To avoid it, you will need to do not render most of objects on large distance (e.g. render statics at the less than 10 cells distance and render only terrain half-covered by fog at 11-50 cells distance).
AnyOldName3 wrote: 10 Dec 2020, 15:25 Regarding saving/caching stuff to disk, there's no particular reason that should be done as a Nif.
And we slowly come to static paging with different files in different data format, as in MGE...
User avatar
Capostrophic
Posts: 794
Joined: 22 Feb 2016, 20:32

Re: Distant Land: where to next?

Post by Capostrophic »

And we slowly come to static paging with different files in different data format, as in MGE...
You imply we should stick to one format, but this still doesn't mean NIF format should be used. It's not really a representation of OpenMW's scene graph.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Distant Land: where to next?

Post by AnyOldName3 »

The things we've said we don't like about MGE XE's system have always been that the user has to manually regenerate things after installing mods, and, even worse, there's no way for its distant land system to react to in-game changes without exiting the engine, downloading or editing a text file blacklisting things from the distant land system, and then regenerating. Caching the results of a system that does handle these situations gracefully doesn't mean it's become the same as MGE XE's.

Either way, I only mentioned loading and saving in response to the lack of a Nif writer being mentioned to point out that there's no actual point in a Nif writer.

In terms of improving object paging, several of Scrawl's ideas from the original forum post haven't been added and there's not any particular reason why they couldn't be. Some of them would improve chunk generation times and reduce draw calls and state switches without needing to cache stuff.
Post Reply