Distant Lands and OpenMW

General discussion regarding the OpenMW project.
For technical support, please use the Support subforum.
Post Reply
Gimpylung
Posts: 4
Joined: 02 Mar 2020, 02:25

Distant Lands and OpenMW

Post by Gimpylung » 02 Mar 2020, 02:39

So I made this flyover video 10 odd years ago.

I figured, seeing as TR has practically all of Vvardenfel added at this point might be fun to do another.

I've spent 2 days now rebuilding my mods in OpenMW and its only now that I'm realizing that I may be wasting my time as distant land support seems to be non existant in OpenMW.

Have I missed something or was it foolish of me to assume that render distance would have been a priority for the OpenMW team?

To be fair, I know 64bit addressing and multi-threading(is it fully multithreaded?) was the initial goal of the OpenMW project and not necessarily graphical enhancement.

Should I just go back to vanilla Morrowind and mod it up with MGSO and Distant Lands like in times of yore as my single core speed is significantly better than it was 10 years ago?

The 10 year old flyover that I can't recreate with OpenMW... (New version was gonna be 1k or 4k... not eyfinity multimon.. moved on from that)

https://www.youtube.com/watch?v=_egQWfKEtAE

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

Re: Distant Lands and OpenMW

Post by CMAugust » 02 Mar 2020, 03:05

Distant land is in, and it works very nicely - dynamically generated terrain LOD over a practically infinite distance. What OpenMW doesn't have yet is distant statics. Not for lack of interest. Game engine development is extremely difficult. Right now there is only one person on board that is familiar enough with all the underlying systems to try it, but he's busy with unfinished business and real life. For what it's worth, there is a distant statics branch that was looking promising (and playable), but the developer In question left before resolving the underlying issues and hasn't returned. Some form of distant statics will happen one day, but there's only so much a small group of contributors can do.

Gimpylung
Posts: 4
Joined: 02 Mar 2020, 02:25

Re: Distant Lands and OpenMW

Post by Gimpylung » 02 Mar 2020, 03:15

Thanks for the reply man.

I tried the distant lands settings as per this ...
https://openmw.org/2017/distant-terrain/

But performance scaled really badly :(

Ah well, I'll revert to vanilla for now, whats another few years at this point lol.

Between SSD's and modern capture like Relive I should be able to make a significantly better version now even with vanila.

Won't be using that awful FPSOptimiser to set the crazy wide rez, or mechanical disks OR FRAPS(sheesh) this time round.

Anyways, keep up the good work, cya in a few years as I'm certain that ultimately OpenMW will be the future of Morrowind modding.

:)

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

Re: Distant Lands and OpenMW

Post by CMAugust » 02 Mar 2020, 03:48

Tweaking the exterior cell load distance as that 2017 article suggests is a lot less sensible now that shadows have been implemented- it's due to the amount of draw calls in the scene. Think of ECLD as functionally identical to Skyrim's ugridstoload, if you're familiar with that. The amount of objects loaded increases exponentially with each increment of the ECLD, and performance suffers to match. It's no substitute for a proper LOD system, which is way more performant in every respect. Still, some people crank it up anyway for nicer visuals. When a form of distant static LOD is finally merged, users will have no incentive to touch that setting at all. Anyway, happy to have helped.

Gimpylung
Posts: 4
Joined: 02 Mar 2020, 02:25

Re: Distant Lands and OpenMW

Post by Gimpylung » 02 Mar 2020, 04:05

Indeed, quite familiar with that god awful ugridstoload.

Thanks for the explanation.

Time4Tea
Posts: 109
Joined: 01 Jan 2020, 00:27

Re: Distant Lands and OpenMW

Post by Time4Tea » 02 Mar 2020, 04:13

I use a cell load of 4 as standard, with object shadows, on my budget-end desktop (with Nvidia GPU) and I find it works pretty well. FPS is usually over 20 and quite playable, even in busy areas like Sadrith Mora. With a cell load of 4, you can see a LOT - can easily see the ghostfence from Ald-Ruhn and I can see probably 3-4 nearby Telvanni towers from Sadrith Mora. It's nice! :D

What sort of system are you using?

Gimpylung
Posts: 4
Joined: 02 Mar 2020, 02:25

Re: Distant Lands and OpenMW

Post by Gimpylung » 02 Mar 2020, 12:40

I won't bore you with specifications but suffice to say I could run The Witcher 3 on max with the fps floating around 70ish. So highish midrange performance compared to what some folks can run the same title at.

The goal is to make a high speed flyover with as insane a framerate as I can and cover all of Vvardenfell, my older video was from a time when only parts of the east had been completed in TR, so more of a technical exercise for me than about actually playing the game(I've played thru the game numerous times)

Think I was hitting 15-20ish fps in this very old daft video with ridiculous view distance...

https://www.youtube.com/watch?v=3vnDz69QUNU&t=87s

I shall persevere :)

Time4Tea
Posts: 109
Joined: 01 Jan 2020, 00:27

Re: Distant Lands and OpenMW

Post by Time4Tea » 02 Mar 2020, 15:28

Ok, it sounds like you've got a better spec machine than me. I haven't played Witcher 3, but I doubt I'd be able to run it on max settings at that high an FPS.

Doing a high-speed flyover sounds quite challenging. It might sound obvious, but perhaps you could do the flyover more slowly and then speed up the video? Would take more of your time though, and might be more tedious. Unless you can script it so the flyover is automated?

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

Re: Distant Lands and OpenMW

Post by AnyOldName3 » 02 Mar 2020, 21:36

To get long view distances with statics in them, MGE XE requires you bake the statics into distant terrain files before running the game. When it does this, it makes a bunch of optimisations, such as skipping smaller meshes and combining several meshes into one (Morrowind's meshes tend to be less limited by triangle count than the number of individual meshes that the CPU needs to tell the GPU to draw), so it can get a higher framerate than just loading them normally would, but it means they can't respond to things like being moved, removed or added by scripts, which can happen for anything, as Morrowind doesn't distinguish between static meshes and ones that might move at some point.

It should be possible to build a system that has all of the nice features of MGE XE's distant land, but none of the disadvantages, and maybe even better performance. It's just something that'll take a lot of engineering work, and there aren't many people with the time and expertise.
AnyOldName3, Master of Shadows

User avatar
MajinCry
Posts: 51
Joined: 15 Oct 2014, 21:02

Re: Distant Lands and OpenMW

Post by MajinCry » 03 Mar 2020, 01:32

AnyOldName3 wrote:
02 Mar 2020, 21:36
To get long view distances with statics in them, MGE XE requires you bake the statics into distant terrain files before running the game. When it does this, it makes a bunch of optimisations, such as skipping smaller meshes and combining several meshes into one (Morrowind's meshes tend to be less limited by triangle count than the number of individual meshes that the CPU needs to tell the GPU to draw), so it can get a higher framerate than just loading them normally would, but it means they can't respond to things like being moved, removed or added by scripts, which can happen for anything, as Morrowind doesn't distinguish between static meshes and ones that might move at some point.

It should be possible to build a system that has all of the nice features of MGE XE's distant land, but none of the disadvantages, and maybe even better performance. It's just something that'll take a lot of engineering work, and there aren't many people with the time and expertise.
The batching of the meshes into one big object is a design error, rather than a software impossibility. That situation is caused by bog standard statc batching, which is done in an extremely dumb manner and has zero flexibility. The solution is to implement a more intelligent batching method, which Boris Vorontsov outlined here: http://enbseries.enbdev.com/forum/viewt ... 869#p69747
Pack meshes in few big vertex buffers and add data to each inside it or in external stream which identify individual mesh, for example one float value. Use that value to index to any data, for example matrices for transformation, which will be selected in shader similar to matrices of bones. Works fine with dynamic objects and all you need is to remove deleted meshes or add new to large buffers. Can be done on hardware too via other tricks (don't ask that please).
The devs already implemented static batching back in the days of OGRE, so implementing a more intelligent version shouldn't be that much of a stretch.
CPU - i7 6700k @ 4.0Ghz
GPU - Vega 56
RAM - 2x16GB DDR4 3000MHz
Mobo - Asus Z170 Pro Gaming
Soundcard - Creative Soundblaster X-Fi Titanium Fatal1ty Pro
OS - Win. 10 LTSC 2019 x64

Post Reply