I still do not get how we want to "handle it automatically at run-time". If we will generate LODs automatically every launch, cells loading speed will be awful.

I don't necessarily mean generating the mesh LODs at run-time (except for the terrain LOD mesh, which we already do). But setting up and displaying LODs dynamically. IIRC, MGE XE generates a static mesh LOD for each cell (pre-baking distant statics) using an external tool, and displays that at run-time. This means if the object is enabled, disabled, or moved by scripts, the LOD mesh will not show anything different. Similarly, if you add or remove a mod that affects the exterior terrain or objects on the terrain, the LOD won't be different until you rerun the tool with the new mod setup. For OpenMW, the individual object LODs would be loaded from disk, but the terrain and knowing when and where to use the LOD meshes would be handled at run-time.

Even without LODs, we could display statics an extra cell or two away just so that it's not so jarring when nearby cells unload. The gameplay impact would be smaller than actually loading extra cells, which is what we have to do right now for the same effect.

Even without LODs, we could display statics an extra cell or two away just so that it's not so jarring when nearby cells unload. The gameplay impact would be smaller than actually loading extra cells, which is what we have to do right now for the same effect.

Sounds like some kind of LOD bias option could be implemented for this. 0 being the default, but if you lower it to be negative the full LOD mesh remains in use farther into the distance (e.g. for an extra cell or two), before it would switch to a lower LOD (i.e. nothing when there's no LOD mesh to load). Could even turn up the LOD bias to have it use a lower LOD within the loaded cells' area, in cases where using lots of complex meshes is putting a strain on the GPU. The terrain LOD can also be similarly biased, either with the same setting or a separate one.

But, you do monthly updates to see how it is going or what you've done more or less past month?

I tend to write an explanation of nearly everything on the GitHub Shadows PR page whenever I commit any changes, and sometimes when I'm actually investigating stuff I'll post there as I go, too. That's the place to go to keep track of things.

Sounds like some kind of LOD bias option could be implemented for this. 0 being the default, but if you lower it to be negative the full LOD mesh remains in use farther into the distance (e.g. for an extra cell or two), before it would switch to a lower LOD (i.e. nothing when there's no LOD mesh to load). Could even turn up the LOD bias to have it use a lower LOD within the loaded cells' area, in cases where using lots of complex meshes is putting a strain on the GPU. The terrain LOD can also be similarly biased, either with the same setting or a separate one.

But also the LOD system isn't a blocker for having non-LOD'd statics an extra cell or two away.

I've made progress trying to fix an issue I couldn't solve back in January with Scrawl's help (although I'm not entirely sure why it's started working now, as I can't get the fix to work when I apply it to the branch from January). In order to verify that it's actually working, can people please test the https://github.com/AnyOldName3/openmw/t ... ers-2-test branch?

If my change is working, all shadows will be stripey. If it is not, then shadows should appear normal. I need to know if anyone has non-stripey shadows.

Don’t know the logistics for this, but if you’re trying to get a larger user base to try out shadows, it might be handy to have it compiled for a few OSs. I would love to try it out and give my thoughts but I’m not going to set up a dev environment just for that. Perhaps it’s not at that stage yet, but just a thought.

Normally, AppVeyor handles Windows builds, no one cares about OSX, and Linux users are willing to build just about anything. AppVeyor isn't handling Windows builds for the stripe test as I've obviously not made a PR for it. For this specific test, I just require confirmation from a few systems as there was some weirdness in the past where a certain solution worked on some machines but not others, seemingly without any pattern, but for other tests, everything should behave identically for everyone, so if it works, it works.