Hello everyone and sorry for the lack of updates lately.

The lack of updates has nothing to do with lack of development. It’s been quite the contrary; a lot has happened since last time. Blame me, Lysol, for the silence.

While there are a ton of things we could talk about in this post, you’ll have to wait until the upcoming 0.47.0 release and the included change log for most of that. Instead, let us talk about three major features: Lua, groundcover and "The Enlightenment".

1. Lua scripting

As we’ve discussed already before, the plan is for OpenMW and TES3MP to eventually merge into one project. This means that OpenMW will require a scripting system that is compatible with, and benefits, both projects.

For quite a while now, TES3MP has been using a server-side scripting system that uses the Lua scripting language. The consensus has for the most part been to continue upon this foundation and implement both a single- and multiplayer friendly Lua-based scripting system for OpenMW. A system that will give massive power to modders making mods for both singleplayer and multiplayer gameplay. Discussions have come and gone regarding the subject, but there was never any real work done.

Our productive developer Petr Mikheev (ptmikheev) therefore decided to take the matters in his own hands. Petr and David C, the mind behind TES3MP’s scripting system, discussed the matter and have sketched out a plan for the ideal scripting system for our needs. It resulted in this merge request which is frequently updated by Petr. Although it is still in early stages (i.e. do not expect it for the next release), people can experiment with basic scripts already to see how it works.

Getting this implemented is crucial for us to be able to get on with the de-hardcoding phase planned once OpenMW 1.0.0 has been released. It is also crucial to be able to make OpenMW the great moddable engine we want it to be. All the impressive mods made for vanilla Morrowind’s MWSE-Lua system gives us a glimpse of what we could see in the future for OpenMW.

2. Groundcover

Ever since OpenMW implemented object paging, we have been enjoying long viewing distances with distant objects and playable performance. Some have even been able to run grass mods without much issue. With emphasis on the word "some". Object paging was not implemented with groundcover mods in mind, even though it might provide increased performance for them too.

Enter instancing. Our veteran Andrei Kortunov (akortunov) has, together with Master of Shadows Chris Djali (AnyOldName3), been working on supporting groundcover through a system much more suitable for it. You see, supporting grass and other groundcover require some special tweaking before you can get acceptable performance with it. Otherwise, each and every piece of grass will have to be sent to the CPU before the GPU can render it, and this takes a very long time. This is called a "draw call". Draw calls are slow. So slow that you don’t want too many of them in one scene. Reducing draw calls was actually the main reason we implemented Active Grid Object Paging, which merges many smaller objects into fewer larger objects (thus reducing draw calls), not only in the distance, but also in the active cell. Read more about Object Paging and Active Grid Object Paging here.

So while Object Paging worked out great for buildings and similar, grass can get handled better, especially since you want grass to sway with the wind and to get bent under your feet when you step on it. The new groundcover system enables grass and other groundcover with better performance and with full support for animation and reaction to you stepping on it.

So far, work has been focused on supporting legacy mods, previously made for MGE XE. This puts some limitations on what can be done. In the future, we plan to implement an even better system to handle groundcover. Such a system will, however, not be compatible with current mods made for MGE XE.

Try the groundcover system today in an unreleased build of OpenMW, or wait for the next release. You can read on how to enable groundcover mods here and here.

3. The Enlightenment

Did you know that OpenMW only supports up to eight lights for each object? You might have noticed lights turning on and off while walking around in a few specific places in Morrowind. If you use Active Grid Object Paging, you might have noticed this quite a lot.

The issue lies with our support for old style Fixed Function Pipeline (FFP). Every object in the game can only receive up to eight light sources at the same time. This was actually the case with vanilla Morrowind too, but the game is designed in a way that you almost never see it. To be fair, all Bethesda games until Fallout 4 had very limited maximum lights per object and worked around the issue in the design of the game. However, the way Morrowind is designed, with many small objects everywhere, is also very inefficient since it creates a lot of draw calls. And while draw calls are reduced if we merge many of the smaller objects into fewer larger object with Active Grid Object Paging, we will instead get issues with lights, since the light limit per object will get reached much earlier. There have been attempts at solving this issue previously, but it proved to be quite the tricky task.

This is where Cody Glassman (wazabear/wazabear_notabear) comes in. You might have come across him earlier from his fork of OpenMW that implements more advanced UI features, which by the way can get re-implemented in a much lighter more mod-like way once Lua is merged. Anyway, Cody decided to have a look at this light limit issue, which resulted in this merge request. It is not quite finished yet, but he already gave us a sweet example of it working here:

A scene like this would be impossible with the current version of OpenMW. Although getting this crazy with lights is a pretty bad idea in a real-world case, this case at least proves modders will have less issues with lights in the future. End-users will also be able to get the sweet performance increase of Active Grid Object Paging without the annoying light pop-in and pop-out issues.

The next release

Yes, we plan on releasing 0.47.0 in a not too distant future! Stay tuned, we will let you know when it is out.

Until next time, thanks for reading.

Unless you live close to the equator or are located in the southern hemisphere, you might have had to rake the leaves from your lawn once or twice now. Our developers don’t seem to have lawns however, because they’ve been adding code like they have nothing else to do. Let’s dig into what has happened in the last two months:

• Petr Mikheev, aka ptmikheev, is a fairly new developer in the community. He has made himself very well known, though, with all his hard work. You might remember him being mentioned in the previous post regarding his implementation of a new, more modern 3rd-person camera view. More recently, he has added optional first-person head-bobbing to the game as well as a "smooth movement" feature which makes movement animations, well, smoother. But let’s not forget one very important thing: Lua scripting. Petr has been talking with David C, the main developer of tes3mp, about how Lua should be implemented into OpenMW. The resulting ideas were presented in a thread here. Check it out if you are interested in these things!

• Frederic Chardon, aka fr3dz10, is another fairly new developer. Actually, he did submit a few merge requests about a year ago, but now he’s dropped the mic by submitting his "Async physics" merge request. Physics and collision detection has been a big performance bottleneck in OpenMW for a long time. While the issue is not completely solved yet, this MR still improves performance by moving the game’s physics from the main thread to one or more other threads, making OpenMW even better at using multiple cores. The setting is optional and you can configure the number of additional threads in the OpenMW launcher. fr3dz10 has worked on several other issues in the last weeks, but this is the most noticeable one for end users.

• Our hammer-wielding penguin akortunov (Andrei Kortunov) has continued his quest of making OpenMW support groundcover with better performance. The big question is whether groundcover should be supported using paging or instancing. But what does paging and instancing even mean? Andrei explained it like this:

  With paging, you merge different grass instances on the fly to large shapes and cache them. So your CPU needs some time to merge all instances and some additional RAM to store data. With instancing, you tell GPU to render the same mesh in the same place many times, and then move every instance via shader.

  We are currently measuring the differences between the two methods. Stay tuned for future updates on this topic.

• The great Capostrophic (Alexei Dobrohotov), who had been developing in the top gear for quite a while now, switched down to a lower gear for a while due to important matters in real life. He has, however, returned lately with some really cool stuff regarding his work to make OpenMW support assets of later Bethesda games. For example, the compressed archive format Bethesda started using in Skyrim Special Edition (SSE), called LZ4, is now supported in OpenMW. This is not only a prerequisite for running SSE using our engine in the future — the format itself is more modern and decompresses much faster than the older BSA format, which could turn out to be very interesting for Morrowind modders and asset creators in general, too. Capostrophic has recently pushed many more changes to improve OpenMW’s handling of the NIF file format, but these are rather abstract in nature and will be discussed in detail when there are new features available that make use of them.

• Assumeru or "Evil Eye" has implemented a lot of under-the-hood changes which most of you won’t even notice. However, they are still very important! So what has been done, then? Region sounds now use settings imported from Morrowind.ini to determine the interval at which they need to be played. Levelled items in untouched containers are now randomly generated from their respective lists when the game is loaded, mimicking the original engine. Scripts can now manipulate base records in containers, i.e., it is possible to add and remove items from all untouched containers. To support these changes, scripts can now add levelled item lists to actors and containers. Finally, vanilla-style overstocking has been implemented as well.

• Thanks to the joint forces consisting of psi29a (Bret Curtis), AnyOldName3 (Chris Djali), and johnnyhostile (Hristos Triantafillou), we now have automatic builds for Windows, Linux, Mac, and even Android on GitLab for every merge request that is opened. This means you can go to any merge request on GitLab and get a fresh build for your OS of choice to test any not-yet-implemented feature you like or hunt down any freshly hatched bug.

• Unelsson (Uoti Huotari) has been working on the hard task of getting the dae/Collada 3D model format to work correctly in OpenSceneGraph, the backbone behind OpenMW’s rendering. Lately, he has been making really good progress, and the basics of animation support are already covered. There is still a lot of work left to be done, but he is slowly getting there!

Okay, this post is getting way longer than planned, so let’s stop it here. There are still plenty of other things we could have talked about since this autumn has been a real blast for OpenMW’s development.

See you next time and have a great winter (or, again, summer if you are located in the southern hemisphere :)).