S3ctor is a core developer of OpenMW, and has, like most of us to be fair, odd interests. This is the incredible story how he mixed two immensely cool things: Quake, and Morrowind, narrated by our hero himself!

Possibly the first thing anybody who has met me in person will say about me is that I am obsessed with game engines – and while OpenMW is my baby, my first love was idTech. At eight years old, I picked up a steel-book copy of Doom 3. Surprisingly, I ended up spending more time with the extras than the game itself. The developer documentary and Carmack’s E3 talk about the render pipeline and engine design captivated me completely. I have distinct memories of my young self barely understanding Carmack’s Reverse. I tried to explain it to other kids, to absolutely no reaction. Nobody else really understood, but it was the coolest thing in the world to me. All of this is to say that I have been interested in this technology since before I could read.

What we’re going to explore today is the history and process through which I developed a brand-new workflow for the OpenMW engine that allows modders to utilize arguably the most powerful component of old idTech – the brush-based level editor.

In order to fully grasp what we’re about to discuss, you’ll need some background on both early idTech and OpenMW/Morrowind. First things first: many modern game engines use a mesh-based workflow. This is somewhat like building a house. The artists are carpenters, creating individual pieces (3D models) independently. Then, level designers – the general contractors in this analogy – take these pieces into the engine’s toolbox and construct the game world around them.

In the modern era, studios have mastered the mesh-based workflow, building their entire operations around it. However, no individual can match the output of a full studio. Take Blender, for instance. It’s an incredible tool, but its complexity matches its capabilities. Learning Blender, or any game engine for that matter, is no small feat.

The mesh-based workflow is intentionally designed to separate level designers and artists. While this isn’t necessarily bad, it does add a layer of complexity that brush-based games simply don’t have. Blender won’t light a scene the same way your engine will, nor will it handle post-processing, interactivity, or your game’s unique features. It’s an amazingly flexible tool – but it’s not tailor made for the experience your game is meant to provide. Nor are Max, Maya, Crocotile, or whatever your preferred modeling tool is.

In contrast, brush-based workflows blur these lines. Here, the level designer wears multiple hats, acting as both a formal designer and a modeler. This approach, inherited by Half-Life through its modified Quake engine, persists in Valve’s design philosophy even today, driving their continued innovation and industry-redefining success.

This was a very difficult concept for me to come to grips with, having always modded and developed OpenMW – it didn’t even occur to me that it was possible to go outside the mesh-based workflow. So let us now demonstrate the difference.

Here’s an image of a house in OpenCS, OpenMW’s native game development tool. You can see the frame of the room is made up of four static pieces which I’ve been glued together. This type of prefabbing makes it impossible to add little details or variations into the structure of an existing asset, you need to change the one, or make a new one. Let’s now attempt to reproduce this in my favorite Quake editor – Trenchbroom!

In just a couple of moments, we’ve got the frame for a brand-new one. Here, there are six “brushes” – I really dislike this term as it can be extremely confusing. Brushes are simply individual polyhedron – cubes, pyramids, anything that could be expressed as a single convex shape is considered a brush. Notice I mentioned convex explicitly – this is a key detail, as the mathematics behind brush-based workflows necessitate that all shaped be convex. More on this later.

And here’s an entire room! It’s not a very good one, though, so let’s make a variant with a door.

Now let’s iterate a bit, bring the wall trim out some, change a few textures here and there…

We’ve now got three brand new template sets of our own to work with. Just like in real life construction, we can expand and tweak these as we build each unique house or area. No two homes need to be identical – we’ve got the freedom to customize! While these assets were whipped up quickly for this article, there’s plenty of room for improvements and personal touches. The key takeaway here is the accessibility and rapid iteration of our tooling. We’ve streamlined the level design process by eliminating the need for separate 3D modeling tools. Naturally, you won’t be animating here, but you’re not meant to – Quake editors are level editors, not entire replacements for modeling software.

But wait, now I’m back to talking about idTech stuff again – this is supposed to be about Morrowind, isn’t it? Well, I’ve been modding OpenMW for a couple of years and in that time used the engine itself as a springboard to get further into game development, netcode, and C++ in general! In that time I’ve made a decent few friends whom I’m proud to call that. Epoch was the first person who’d turned me onto the concept of Trenchbroom in general – we’d discussed it offhandedly a few times while probing for features we could implement into OpenMW’s rendering pipeline.

Later, at some point, a mutual acquaintance of ours challenged me to a match of Fortnite. Insulted, I did what any old-school gamer like myself would do: I rolled a Quake 3 server at https://s3kshun8.games and challenged him to a match instead. As it turns out, our mutual friend was also a fan of Quake and within minutes was mopping the floor with me. But, nevertheless, Epoch and I continued diving into the depths of modding idTech to see what we could come up with.

Our first idea was to port Morrowind assets into Quake. Everything goes downhill from here. First came Stroggvarine:

Then Crassius Curio.

Then Epoch had an even worse idea:

Okay, so, now we’ve got characters in, what about structures? How could we recreate Balmora, Vivec, or Sadrith Mora in Quake 3? (Tell me you wouldn’t play FFA in Sadrith Mora, I dare you) There seemed to be a solution to this according to some old research I dug up from katsbits.com. I found their discord and joined, looking to figure out how to integrate 3d models into a Quake 3 map using patches. I got all the details, but, it just seemed like too much work at the time and the process was so… raw, and based on old tools – I never did give it much of a chance to get fleshed out.

Because along the way, I had another, much better idea. I’d started playing with Quake editors like JACK and NetRadiant-Custom, trying to learn how the level design flow worked – and I immediately fell in love. Having tried and failed (not particularly seriously) to use Blender many times, having a way to make my own assets felt as though I’d unlocked the missing piece to being able to ship an entire game on my own. I wondered, idly, if we could apply this to Morrowind somehow. And then I noticed an export to .obj file button in Trenchbroom. The tool itself did this, to some degree, so I knew it had to be possible, beyond all shadow of a doubt – it was doable. So I sidled on over to the Trenchbroom GitHub and opened a discussion about it.

What you see above is the first attempt at getting a Quake map into Morrowind. We exported a map out of Trenchbroom, imported the OBJ into blender, and re-exported the NIF. Textures got lost and the scale is all wrong – it’s actually a lot smaller here than it should’ve been. At the time, we had no idea what the scaling ratio would be between Morrowind and Quake 1. As it turns out, this was really simple – there’s no fancy asset-level scaling happening in either engine with regard to assets. The only scaling difference between the two engines is that a Quake 1 player is almost exactly half the height in units of the default male Dunmer in Morrowind.

You might be curious about how we figured that out. Well, Quake editors define the player as some or another kind of game object, whose bounding box is displayed in the editor. Like this:

The player themselves is represented in Morrowind.fgd file like this:

@baseclass size(-16 -16 -34, 16 16 33) color(0 255 0) = PlayerClass []

The same line exists in Quake.fgd, there the player is 56 units tall:

@baseclass base(Appearflags) size(-16 -16 -24, 16 16 32) color(0 255 0) = PlayerClass []

All we actually had to do was launch OpenMW and check the player’s bounding box like so:

self:getBoundingBox().halfSize.z

and there we go. We prefer building at smaller scale, so, we just based the Morrowind.fgd off the halfsize instead of the player’s true height and build at half scale by convention. It’s just easier.

Having figured the basics out, the real work could now begin. What we needed at this point, was a compiler – except instead of compiling a BSP, we’d be compiling an ESP. But it’s the same concept Quake uses – in-development, maps are passed around as text-based source files, and then a compiler converts them into actual 3D geometry, gameobjects, et cetera.

Inside of a .map file, brushes are stored as a set of planes with some data about their extents and mapped textures.

For reference, here’s a simple cube – the default map Trenchbroom creates along with each new document:

// brush 0
{
( -64 -64 -16 ) ( -64 -63 -16 ) ( -64 -64 -15 ) __TB_empty [ 0 -1 0 0 ] [ 0 0 -1 0 ] 0 0.25 0.25
( -64 -64 -16 ) ( -64 -64 -15 ) ( -63 -64 -16 ) __TB_empty [ 1 0 0 0 ] [ 0 0 -1 0 ] 0 0.25 0.25
( -64 -64 -16 ) ( -63 -64 -16 ) ( -64 -63 -16 ) __TB_empty [ -1 0 0 0 ] [ 0 -1 0 0 ] 0 0.25 0.25
( 64 64 16 ) ( 64 65 16 ) ( 65 64 16 ) __TB_empty [ 1 0 0 0 ] [ 0 -1 0 0 ] 0 0.25 0.25
( 64 64 16 ) ( 65 64 16 ) ( 64 64 17 ) __TB_empty [ -1 0 0 0 ] [ 0 0 -1 0 ] 0 0.25 0.25
( 64 64 16 ) ( 64 64 17 ) ( 64 65 16 ) __TB_empty [ 0 1 0 0 ] [ 0 0 -1 0 ] 0 0.25 0.25
}

By convention, they’re numbered, but this is not a crucial aspect of the format. The important bit is that this is a representation of each face of the cube, stored as three (three-dimensional) points. These three points define a plane which is a half-space – an infinite set of points bounded by a plane. It sounds complicated, and the mathematics are, but essentially – you’re looking at each side of a cube here.

BSP compilers then use a range of techniques to extrapolate vertices from these half-spaces, such as computing them directly, or the original Quake compiler’s approach of using a large cube to determine points of intersection. For more of the mathematical details, you can read up here. Originally I attempted to reproduce this approach on my own with little success – I tried many variations on the formula, and eventually hit one that seemed to work, but actually, was only valid on perfect cubes. It did work on every possible cube, though. But only cubes.

Defeated, I researched further and learned about Qodot. I wasn’t the first person to have this idea. Now known as func_godot, a project already existed which used Trenchbroom in another unintended engine. Digging around in their repositories didn’t net me much, until I stumbled into this little ditty. Apparently, the original developer of Qodot suddenly got very into Rust one day and rewrote all of the necessary tooling in Rust and then vanished. The team was very cagey about discussing this particular developer, and they seemed to have been gone for a while, and I couldn’t reach them for months. It happened to be precisely what I needed in ways I didn’t even think of originally, and seemingly was all mine to whatever I pleased with.

Now we’re really going to get into technical details, so please bear with me – I’ll take you through it as best as I can, and I pinky-promise this won’t be half as bad as you think it’ll be! Once you’ve built a map, the final step is to compile it and get it in-game. So how does the compilation process work for OpenMW? Let’s crack open the Morrobroom source code and take a high-level overview of what it’s doing.

It all starts… with startup arguments. Not a lot to see here – you give it a path to a .map file, the ESP it’s supposed to save to, and an optional scale argument to increase or decrease the overall asset size. This is handy for making maps for both Morrowind and Quake (yes, really).

Some key points here – MapData is a class which does the necessary Shambler calls in order to get all of the texture and geometry data out of Shambler and into a struct we can work with later. This includes the texture info, entity data, vertices, vertex normals, et cetera. We then loop over all brush entities inside of the map and generate a Mesh from them. The Mesh struct is halfway between a custom representation and an actual NIF file – there’s just a little bit of extra info there to make the compiler work properly. This segment is also responsible for making sure that game objects do not have duplicate definitions inside of the final ESP file.

We then get the reference’s object ID and if assigned, the model override which they’ve been given. Trenchbroom doesn’t support OpenMW’s primary model format, NIF, so the best we can do is just tell it to use a different asset instead of the one the mapper put together. I’ll omit the next part, but, we simply do a big match against the name of the type of the brush entity, and use that to decide if it should become a light, or an NPC, or a door, et cetera.

Finally we get the center point of each brush asset and use that position as the reference position in-engine. This means they’ll be placed in the same spot in-game as they were in Trenchbroom. Buried underneath all this are also advanced model editing options, such as configuring alpha testing vertex colors, and whether or not collisions are used. More features are consistently being added over time as we improve the compiler and find new things to add!

That was a highly simplified overview, but, that’s the entire main loop for the OpenMW compiler. There is a lot more code which was not showed or explained for brevity – please do review the Morrobroom GitHub or simply reach out if you have any questions about it! So, now, all compiler’d up and nowhere to go… What do I do from here?

Well, naturally, you try to port Quake whole-hog into Morrowind at this point. What else would you do as a responsible Morrowind-modding Rustacean who really needs a job and plays too much Quake? Now, this gets into dicey legal territory. I refuse to publish the compiled assets myself, because this is an area that’s way too ambiguous for me to mess with. However, it’s worth mentioning that the Quake community tosses around the entire texture set for the game all over the place, and way back when, John Romero released the map sources claiming that he made them GPL, but that claim has been disputed. Now, John Romero can get away with just saying he made the maps GPL and nobody’s gonna go argue with him about that, but I don’t have that luxury.

Instead, I will just share some screenshots and mention that both the necessary textures and .map sources are easy to get, if you’d like to reproduce this for yourself:

Is it cursed? Yes. Is it my crowning achievement as a technologist? Probably also yes. So far. We still have even further to go. You might notice the maps are empty. We don’t support quake entities yet, and we dropped porting official Quake because of above licensing issues I wasn’t able to get solid answers on. Enter LibreQuake – much like FreeDoom, LibreQuake is an open-source reimplementation of the game code and assets that made up Quake. It’s not the exact same thing, but it’s intended to be visually and technically compatible with any Quake engine or mod.

And thus began the port. First came the shotgun:

This is the first screenshot I took with it, but it worked! Later versions have much better bullet spread and are actually capable of killing targets which they hit. They even use real objects, although it’d be much more efficient if we simply used raycasts to do hit scanning instead of these slow-moving projectiles.

We’re almost done, actually. Research is ongoing into porting creatures. Fortunately, LibreQuake has the source .blend files in its repository, so this won’t be too awful to figure out… eventually. However, I’d like to demonstrate Epoch’s technique he developed for reproducing the Quake skybox! You might’ve noticed in previous images the sky looks really odd.

This is because The Quake sky was implemented at a time before transparency in textures was a common technique – the sky there is actually one texture, folded on top of itself, with the black pixels masked out, and then the result scrolls across any brush which uses the sky texture. Epoch’s postprocess shader is able to replicate this effect, mostly, by essentially utilizing a greenscreen. We place green sky brushes as usual, and then:

It has all the problems of a typical greenscreen though:

Later, we’ll be able to implement a much nicer version of this technique by using Morrobroom to apply animations directly to these assets and maybe use alpha testing to similarly mask out the black pixels. The great thing about it is… We don’t even know yet!

So what’s the value add in all this? Well, we’re able to iterate much faster on level design and create more unique assets than almost anybody else using this engine. They’re not necessarily as high fidelity, but they’re much more satisfying to work with and really allow to execute one’s artistic vision. Our results speak for themselves: !

What you see above are maps which Epoch and I produced together, and he worked to develop baked lighting, normal, and specular maps for. Along with a creepy postprocess fog visible in the last image. The first image is a set of 2500 chunks procedurally generated based on the Trenchbroom maps we made. Eat your heart out, Starfield!

If you want to know more about our stack, the OpenMW project, or just to talk, please do reach out! I love discussing this topic and am always open to explore game development concepts (and OpenMW) with new friends.

What does this mean for OpenCS?

Great things. Trenchbroom has a very similar stack to OpenCS – both are Qt-based level editing applications running OpenGL. The similarities mostly end there, though, and in a good way. I borrowed some of Trenchbroom’s code for an early attempt at Windows dark mode support. My implementation didn’t manifest, but the relevant Trenchbroom bits from that old MR will allow better usage of the ALT key in our editor to more closely reflect the orbit camera behavior of the original TESCS.

Additionally, I’ve (politely) butted heads with the Trenchbroom author once or twice about adding new preferences in TB – something which they are very resistant to. And rightly so! I’ve spoken with many people who thought they had feature requests for OpenCS and it turned out they were asking for something buried in its preferences menu.

Finally, after implementing !3675, I realized we could do even better than that when it comes to moving objects in the editor. In Trenchbroom, you simply hold shift to move an object only along whichever of the X and Y axes has moved further, and alt to move on the Z axis. It’s not at all like how TESCS works, but it’s very fast once you’re used to it and far less laborious than either my or Blender’s versions of the same feature.

To cap this article, I’d like to also share Tremble, the Unity integration for Trenchbroom, and HammUEr, the Unreal integration. You can use Quake-based workflows in essentially any 3D-capable game engine! Consider using it if you find Blender difficult or just don’t have the time or interest. It might just revolutionize the way you think about level design.

2024-11-08 - jvoisin - No pingbacks so far.

Good morning and welcome to this joint interview. Can you tell us a bit about yourselves?

A.: Hey, anonymous interviewer! I’m neither a cat nor a month, but a rather fortunate bird — if you believe some historians’ hypothesis about my nickname’s origin. In my day-to-day life, I prefer to take the form of a German electrical engineer doing his PhD in the field of battery technology. Thanks for reminding me that I still was an undergraduate when I joined the project in early 2016, technically transforming from long-time lurker to, well, bird.

J.: Hello there! I enjoy the company of cats but like my fine friend Atahualpa I also am not a month. I also may not always be that hostile. When I’m not poking around in OpenMW-related things I do enjoy cycling, nature hiking, and playing music. I started hanging out in the OpenMW IRC channel back in 2013 or so and have just been hanging out ever since.

Word on the street is that you’re the dynamic duo of OpenMW’s massive video production industry. Is that true?

J.: I remember learning about OpenMW, and of course part of that first exposure was a classic release video. I forget which was the first video I saw, but what did stay with me was the style — and I hope we’re staying true to it with our work.

A.: While we might be the somewhat dynamic video duo today, we are standing on the shoulders of giants: Star-Demon, who started the whole concept of presenting OpenMW’s progress in video format over twelve years ago for version 0.6.0, and the brilliant WeirdSexy, whose great voice and even greater love for spears have been ingrained in our collective memory.

Producing video sounds like work. What does it look like, what’s the secret sauce?

A.: At this point, a short disclaimer: We aren’t professionals by any means, so take everything we say with a spoonful of salt.

J.: Oh please, everybody knows that Atahualpa is a Blender video-editing Arch Magister. I learned everything I know from him!

A.: Alright then, let’s look at some of the things we need to cover in order to produce a somewhat entertaining release video. Please note that this is a simplified breakdown and that many of these steps may overlap, change order, or require several iterations and feedback loops. Video production is reaaaaally time-consuming (maybe we should start doing reaction videos).

1. Content considerations
   We usually take the complete list of changes (nowadays 100+ closed issues per release), add changes without tickets on our issue tracker, put them into suitable categories, and rate their video eligibility:
   • Importance?
   • Interesting to the viewer?
   • “Easy” to demonstrate?
2. Content outline
   After choosing the issues we want to cover, we define their order of appearance. The structure might look like this:
   • Intro
   • Credits
   • Main video
     • Section 1
       • Cool new feature
       • …
     • Section 2
     • …
   • Outro
   • Fake “end card”
   • “Post-credit” scene
3. Script draft
   Having a rough outline, we start writing the script. Especially this step might go through several feedback loops by discussing it among us or passing it to the team for review.
4. Audio recording
   We usually divide our speaking parts evenly. Then, we record our paragraphs, optimise audio quality, put in labels, and export them into single files for greater flexibility.
5. Video recording
   With the script and audio in place, we can start recording video footage. This is, of course, heavily guided by the script — not only in content but also in length. Moreover, many of the scenes might require a certain setup, even including mods or custom editor content to fit in those little inside jokes no one will catch anyway.
6. Pre-postproduction
   Each video requires title screens, text overlays, and pre-rendered audio visualisers (see intro of 0.47.0 video). Those are done in Blender.
7. Postprodcution
   In this step, everything is put together using Blender’s video sequence editor: video and audio files, background music, overlays, video and audio transitions, and additional effects, e.g., speed modifiers or zoom effects. The final Blender file might look like in the image below.
8. Rendering
   The video is rendered in 4K to ensure highest quality on YouTube — yep, even 1080p viewers benefit from a 4K source file due to YouTube’s infamous compression shenanigans! Early video tests are usually rendered with a lower resolution to speed up the process.
9. Post-postproduction
   Before the video is published, we create closed captions in English (as well as subtitles in German if there is no separate German video) and a custom thumbnail.
10. Pre-release tests
    The last step before a release is extensive test viewing by other team members to catch any remaining errors. — Et voilà, a new release video is ready to go!

Is it true that you’re mysteriously showing up in time of need, like, right before an OpenMW release?

A.: Nice try to get that famous quote from this wizard in Star Wars. Ehm, Spock it was, right?

J.: Think of me as the reverse homer-in-the-bushes gif. Oh, and yeah Atahualpa: that was Captain Spock for sure.

A.: In fact, OpenMW releases tend to spawn right after one of our videos. Except for 0.48.0, which, to this very day, is a great mystery in and of itself.

Wait, does that mean you’re cooking a release video right now‽ Can you share some details? Can you leak the date of the release?

A.: My estimate is that we will release the video at least one day too late from everyone’s perspective, which is going to be mitigated by delaying the actual release which, in turn, is going to annoy everyone even more. It wouldn’t be the same otherwise.

J.: Maybe a few days plus or minus from that. I can’t be too sure. It’s likely we won’t know when it will be out until it is.

A.: Seriously though: 2024 would be awesome — looking at you, extended release phase for 0.48.0.

Previous videos have been awesome and thus rightfully well-received. How do you handle so much fame?

J.: Give the people what they want! And by that I, of course, mean Fargoth jokes and Imperial guard mosh pits.

A.: Not to rain on your parade, but I measure fame in the amount of bot comments below our videos — and going by that metric, we are as famous as the menu pinning feature in Morrowind.

Speaking of videos, since you’re obviously domain experts, any recommendations with regard to movies and TV shows?

A.: Boomer advice: Don’t let your consumption of movies and TV series become arbitrary. Oh, and consider reading the source material (if it exists), especially if you happen to love fantasy and sci-fi works like I do — it usually allows you to imagine and explore other worlds in much more depth than a TV adaption can provide. As to actual recommendations, my last movie was “Dune: Part Two” (you might have heard about it). One of the best audio-visual experiences I’ve ever had in cinema. (Again, read the books! Well, at least the first three, I guess. The series gets increasingly more complicated and esoteric.)

J.: Oh yeah, Dune is on my “to-watch” list, and I guess now on my “to-read” list as well! Ahem, as TV shows go, I must take this opportunity to give a shout out to “Star Trek: Deep Space Nine”. When I think about movies, I think about “Fear and Loathing in Las Vegas” and I think of mine and Atahualpa’s adventures in making OpenMW-related videos. Yeah… it’s kinda like that!

A.: Uhm, okay. But who is which character in that analogy?

J.: I do think of you as my attorney and you are doing the PhD thing, so that makes you Dr. Gonzo. I’ll be Hunter S. Thompson; I can wear cool hats and take all the ~screenshots~ photographs.

Have you ever thought about learning C++ to contribute by writing code, like some other contributors did?

J.: Years back, my first experience with (very roughly) hacking on C++ at all was with OpenMW — I wanted to hack in the ability to wear more rings and kind of grepped my way to it. More recently, I actually did decide to dive back in to get a small feature added into the Lua API. Major thanks to everyone who helped, especially S3ctor and Evil Eye! It’s a big, complicated codebase but it can be reasoned about. The C++ itself is just another thing you must cope with, but things can come together surprisingly quickly.

A.: Truth be told, I learned C++ at technical college back in 2008. The problem is that an engineer’s ability to produce completely functional spaghetti code doesn’t qualify them to work as a game engine developer. Nonetheless, I’ve already contributed some smaller changes and bugfixes, with an emphasis on our editor, OpenMW-CS. — Even more truth be told, I have several thousand lines of unpublished code for various parts of the CS buried in my local OpenMW folder. Programmers can be harsh at times, and OpenMW developers are especially good at humbling you, allowing you to sustain your personal coding insecurities and letting you keep your work for yourself.

What’s the next big OpenMW thing you’re super excited about?

A. and J.: Lua!

J.: Of course it’s playing Half-Life 3 in OpenMW: Unity Edition. Seriously though: I’m looking forward to the awesome work that’s being done with spell casting and combat for the Lua API. These are some of the most sought-after features for modding and I think we’re going to see a lot of cool content that will utilize this. There’s also been some hacking on sky shaders that looked amazing, hopefully that can be on our pre-2090 list.

A.: I also like to see new stuff which I’ll probably never use myself, but which sets OpenMW apart from the original TES games. Upcoming features like (eventual) native support for multiplayer and VR are not only great for the people that use them — but they’ll also make OpenMW more accessible to other audiences which, in turn, might draw new contributors to the project. Moreover, let’s not forget that all these features will be most likely integrated into one platform, i.e., multiplayer users should be able to join using the Android version of OpenMW, VR users get to enjoy full support for OpenMW-Lua mods, etc.

Following, OpenMW intends to be a platform for independent games. Do you have a “dream” OpenMW game, and if so, what’s that look like?

A.: With “Tamriel Rebuilt”, “Skyrim: Home of the Nords”, “Province: Cyrodiil”, and the other “Project Tamriel” projects, Morrowind-era Tamriel is already covered if you ask me. What I would like to see — and, yes, I’m a sucker for Daggerfall, especially Daggerfall Unity — are large-scale approaches to a fantasy game. Maybe not as massive as Daggerfall or the (hopefully) to-be-released “Wayward Realms”, but with a greater sense of scale than the tiny theme parks current TES games are. Eventually, OpenMW-CS should allow for some kind of random/procedural generation, and I would like to see somebody take advantage of that possibility.

J.: I’m looking forward to community-driven projects that are using OpenMW for their engine such as Open-Z; My dream game made with OpenMW might be something surprising, maybe something with Katamari-like gameplay or some kind of recreation of a classic game. I love to see unexpected, not-Morrowind things as much as I love the Morrowind things.

A.: *cough* RoboWind Construct (RWC). Google it.

If you could change one thing about OpenMW, what would it be?

J.: I would remove the team’s harsh ban on hardcoding every actor in any game using OpenMW as Fargoth. It’s a crime, really!

A.: Speaking of hardcoding: the father of OpenMW, Nicolay Korslund, found it funny to hide most of our engine’s features behind a hardcoded 2090 timestamp which can only be removed for each feature individually by wasting huge amounts of energy to mine a developer token. That must have been the single biggest mistake in computer history! I want my vanilla-style water now!

Someone told me that johnnyhostile was going to jam with lysol in a sludge metal cover of the Morrowind theme. Is this true?

J.: It is true! This is actually the epitome of vaporware, 2090 edition projects. Coming soon^TM.

A.: Not to spoil anything, but having heard an early demo of johnnyhostile’s guitar part, I’m more than hyped for the full album release!

Anything you’d like to add?

A.: To avoid a shameless self-plug by my wonderful partner in crime: If you want to mod OpenMW, go visit modding-openmw.com! I consider it to be OpenMW’s sister project, a hub for mod creators and modders alike that allows the community to decentralise mod hosting, while it ensures easy access to mods and modding instructions for everyone. It’s johnnyhostile’s baby, and he’s managed to build a team of dedicated contributors who help maintaining and improving the site for all of us to benefit from! Oh, and if you are a modder who wants to dive into OpenMW-Lua, have a look at johnnyhostile’s Lua mod template. It even allows you to host a little static website for your mod. — End of ad break.

J.: That’s it for today’s interview. See you next time — and as always: thanks for watch-, uhm, reading!

2024-05-26 - jvoisin - No pingbacks so far.

Good morning, who are you, and have you always been a month?

Only for a little while. My previous moniker was CMTuesday, or was it?

When did you join the project and why?

I first heard of OpenMW in late 2015, around the release of 0.37.0. The MrOpenMW Release Commentaries hadn’t caught up by that point, but the FAQ video successfully piqued my interest in a clean-room reverse engineered engine that could run Morrowind better than the original. I had bounced off of Morrowind in my first attempts to play it, but after the release of Skyrim ignited my interest in The Elder Scrolls like never before, I was ready to try it again in this new engine. And believe it or not, that was the first time I finished Morrowind’s main quest.

It was already a very playable experience in OpenMW even then, but there were some minor visual and UI hiccups along the way – these I documented and submitted as bug reports, which were promptly fixed by scrawl, who was still working like a machine after moving the engine from OGRE to OSG for 0.37.0. Seeing that level of responsiveness encouraged me, and thanks to the ease of being able to download a fixed build the next day, the testing process was in a sense more satisfying than if I had just played the game and moved on. Of course I played some more, and noticed some more oddities, and opened more issues on the tracker. And I basically never stopped.

I’ve been told you’re part of the “OpenMW Public Relations And Assorted Propaganda cabal”, is that so?

It’s news to me, but maybe I haven’t been let in on the joke! First and foremost my role in OpenMW has been as a tester, giving feedback to identify any bugs, issues, or features that will help to improve the user experience. I generally interact more within the OpenMW team than outside it – or to put it another way, if I’m pestering anyone, it’s the devs themselves. Of course, I do regularly wade over to the various Discord servers such as Morrowind Modding Community as well as the big projects like Tamriel Rebuilt to see what’s being worked on there, and occasionally I put in my two cents when certain topics like rendering performance are being discussed. That topic comes up fairly often with a game as CPU-intensive as Morrowind, and mods are constantly hitting that performance ceiling. I don’t care to do any preaching or propaganda for more users to pick up OpenMW, because as far as I’m concerned the engine speaks for itself with each new version that’s released. It’s good enough for me to know that the OpenMW team itself is in great shape, with a community Discord server that’s friendly and focused on the business at hand.

Out of all your time playing OpenMW and looking for bugs, which issues have been the most satisfying to see resolved?

For me it probably has to be the visual side of things, as in rendering. For a long time particles weren’t lit correctly, at least according to how Morrowind originally rendered them. Particle effects are usually the thing that brings the most “pizazz” to any game, and Morrowind’s effects aren’t great to begin with, so it irked me that they looked a bit worse in certain lighting conditions. I was also bothered by the light rendering in general, since while OpenMW faithfully replicated Morrowind’s fixed function lighting, the lighting in Morrowind is just hideous. Quite apart from the infamous 8 lights limit, the attenuation model used was so whack¹ that it produced lighting seams and unsightly blinking everywhere you looked. Cleaning all this stuff up and replacing it with something better was not for the faint of heart, requiring knowledge of not just rendering but the many rules and quirks of OSG and OpenMW engine itself, and there was more than one attempt by different developers over the years with several false starts. To my eternal gratitude, all of this was finally resolved by wazabear in 0.47.0 and 0.48.0, with some further tweaks by Capo and wareya to end up in 0.49.0, and all with such finesse that OpenMW now has a direct upgrade path to clustered shading² at a future date.

How come you know literally everything about OpenMW graphics even though you never wrote a single line of its code?

“Talk is cheap. Ask questions. You don’t ask, you never learn.”

When I notice something about Morrowind that looks broken, or runs slow, or is simply not as pretty as other games, I ask why. The OpenMW team is after all stuffed with people knowledgeable about such things, and more often than not a guru like AnyOldName3 or wazabear will explain it to me. Or, on the occasion they can’t recall off the top of their head like a Zen master, they might do some investigation of their own, in which case we both end up learning something.

Moreover, one of the nice things about identifying problems for open development is that you get to see the solutions. I read every issue and merge request that comes through on the tracker at least once, which usually conveys the gist of what was wrong and what was changed even if I don’t understand a lick of code. I also read each message that comes through the Discord, and each new post on the OpenMW forum before that. To sum it up, eventually some of that knowledge soaks through. But I certainly don’t know it all, and any day can bring new surprises.

Has OpenMW lived up to what you expected when you first discovered the project so far?

Looking back, I’d say OpenMW has nearly fulfilled all my original hopes from when it first caught my attention. At that time there was no distant land, object paging, groundcover, shadows, fancy shaders… and while all the Morrowind essentials were more or less in its place, not all the thousands of little pieces that make up the game fit quite right. Things are much further along today. OpenMW has reached parity with vanilla Morrowind in nearly every conceivable way, and for a stickler like me, that’s saying something. Out of all those original expectations, the only thing that still falls short is the dehardcoding of all relevant systems, and that is now well underway with the Lua API. But that’s not the end of the story, because completing the various features doesn’t simply close chapters of the OpenMW book – it opens new ones.

What’s the current or next big thing you’re hyped about?

Bindless textures³ will be a huge deal if it lands, and because one is related to the other, clustered shading* is likely to come with it. Aside from the advent of Vulkan, this is likely to be the biggest leap in rendering performance OpenMW will ever see. When that happens, there is suddenly scope for huge (and expensive) leaps in visual fidelity such as point light shadows. In addition, we could soon have a native physically based rendering path⁴ and support for its materials to go with it. Altogether, there’s a lot to be excited about in OpenMW’s future.

Any favourite mods?

When I’m not testing stuff, I run a fairly light setup, mostly related to fixes like Morrowind Optimization Patch and Patch for Purists. I think my favorite mods haven’t been invented yet. If I had to describe it, I think I’m most inclined towards mods that provide glimpses of a Morrowind that is less clumsy and more refined in every respect, polished and fun from end to end.

If you could change one thing about OpenMW, what would it be?

Giving it the power to dispense good luck and motivation to its many talented developers, so it can be developed still further.

1. Morrowind’s whack attenuation model: CMAugust refers to Morrowind’s suboptimal use of the traditional lighting calculations. Unlike in most modern games and later Bethesda games, Morrowind’s light sources fade according to inverse-linear law rather than according to the physically accurate inverse-square law which means that it can take a while for the produced lighting to “disappear”. Due to Morrowind’s low light source limit this often results in it getting cut off prematurely. In OpenMW’s shader lighting, the used formula is tweaked to let lights fade earlier, preventing most apparent instances of lighting seams and pop-in. This does mean the game becomes darker overall. In 0.49.0, shader lighting will be further adjusted to minimize the resulting differences. ↩︎
2. Clustered shading: another shader pipeline technique where light sources are bound to small segments of the screen (clusters) rather than objects. It allows to significantly increase the light source limit without running into the act’s usual performance penalties. ↩︎
3. Bindless textures: a shader pipeline technique that makes it possible to use textures without binding them to the scene. This allows to significantly reduce the number of draw calls and thus the CPU load, similar to atlasing but avoiding its usual drawbacks. ↩︎
4. Physically based rendering (PBR): the rendering approach often employed in modern video games in which texturing defines the object’s optic properties in a standardised way consistent with real physics. ↩︎

2024-05-12 - jvoisin - No pingbacks so far.

Hello and who are you?

Resident cat herder, metaphorically speaking and a dad, literally speaking. I, in fact, have no cats but it seems that I’m in charge of 3 children, a few teams at work and other teams spread all around the planet who work on FOSS stuff. An ex-patriot who settled in Europe and rebuilt his life. When there is free time, I do in fact play games, but I like hacking, tinkering and travelling more.

When did you join the project and why?

I’m a little fuzzy on the details, but it was likely around 2011, when 0.11 was released. I provided Debian and Ubuntu packages for the project. At this point, I was operating under the pseudonym BrotherBrick — to keep my work on OpenMW separate from my day job. I’ve had psi29a since the 90s, so once I talked to legal at my work to make sure everything was okay, I switched back to using my old handle. I had lurked around earlier of course because I was totally into finally completing the main quest while running Morrowind natively on Linux. So that was my overriding goal. Years passed, but I’m still putting off completing the main quest, which is probably why I’m still around.

This was my first post on the forum I think, in 2011.

I’ve been told that you’re the one currently wearing the “Benevolent Dictator for Life” hat, and that you’re the third hero to do so. Is that true? And if so, is it heavy?

It is. Not all heroes wear capes. That being said, it’s more like being a glorified cat herder. FOSS developers will do what developers think is cool, neat or interesting to work on. As a hobby project, as Project Lead, one can only give guidance, make suggestions, propose solutions, represent the project to the outside world, remove roadblocks and in the end still get unanimously outvoted, which is fine because the OpenMW doesn’t really need a BDFL in the traditional Linus Torvalds sense. 

Much of the work comes down to coordination and communication between developers, with upstream libraries we use and downstream in distributions. We can and have provided fixes for many of the libraries we use and also provide patches downstreams to fix issues that would prevent OpenMW from running. 

Sometimes I have to put on my dad hat or my therapist hat and help developers suffering from burn out or personal issues. I mean, I’ve known most of the developers for over a decade and bonds form. They are all welcome to the 1.0 release party at my house :)

So you do plan on continuing to lead the project for the foreseeable future?

<_<  >_>

I’m not as involved as I would like to be for such a role. I think I only got here because of how long I’ve been active in the project, not necessarily a master of shadows or a master of lights. If new leadership wants to step forward, I’ll support them. 

What have you been working on recently?

Recently not so much; I had a small break with the project to focus on my family. I can’t express how much I value boundaries, setting them, having a good work life balance for one’s own mental wellness. A few months ago, I reconnected with OpenMW thanks to the positivity of the community and developers which I’d like to think I helped foster. 

While away, I reconnected with an email penpal and worked on vsgopenmw: a fork of OpenMW that runs on Vulkan, specifically VulkanSceneGraph, the successor of OpenSceneGraph which we use as our rendering middleware library. It was nice to collaborate again, even though it was slightly unorthodox. Many patches were sent upstream to VSG and vsgopenmw now also runs on macOS via MoltenVK and Linux.

I guess I’ll let the cat out of the bag here and mention that I’m currently working on the OpenMW 1.0 roadmap. It’s been going on for the past few months and the plan is to release this roadmap sometime after 0.49’s release. Its release will not mean that 0.50 will be the first 1.x release, but it will make it a point that OpenMW is taking a “1.0” release seriously and setting things up for getting the project across this threshold and beyond. It’ll also be the opportunity to make the fabled “1.0 release party” happen.

Has OpenMW lived up to what you expected when you first discovered the project so far?

Absolutely, I feel like OpenMW reached “1.0” for me in 0.46, when it was mentioned to me that I could theoretically complete the main quest line with a reasonable approximation of the original spirit of Morrowind, just without the constant crashing. It’s gone now above and beyond with all sorts of graphical (object paging), scripting (Lua), physics (threaded) enhancements. That it does so on the three major systems is a bonus, because while emotionally I only care about Linux, in practice I have to care about Windows and macOS as well. 

When I first discovered the project, Windows was more of a novelty and most developerss used Linux, no macOS work to speak of. I think I floated around T-posing in a cave for a long time, and exteriors only had buildings with no terrain. So we’ve come a long way.

What’s the current or the next big thing you’re hyped about?

Seeing Lua support maturing is wonderful, however, the next “big thing” I’m hyped about is VSG support. For me, it’s a way of future-proofing Morrowind. OpenGL is dead, it’s not even being maintained and in some cases like macOS, it’s been abstracted away with another layer of bugs upon the existing ones. 

There are many other things to be hyped about as well including VR that exists in another long-lived fork, and multiplayer, TES3MP. That being said, with the amount of work going into de-hardcoding for Lua, I’m waiting to see what cool stuff the community comes up with.

Speaking of Lua, what’s your opinion on MWSE, and also MGE XE? Shall we expect them to be ported one way or the other unto OpenMW?

MWSE and MGE XE are a great bit of kit; it’s great for extending Morrowind.exe and giving modders an amazing amount of freedom. I believe there continues to be value in continuing work on MWSE, specifically in addressing the stability issues. Hooking into parts of Morrowind.exe that are prone to failure and rewriting it to be more failure resistant would go a long way in addressing one of the largest pain points of playing Morrowind on the original engine. Major thanks to all involved in these two projects, those who work on them have also indirectly helped OpenMW with research.

Saying that Lua is similar across MWSE and OpenMW is a misnomer; what’s been done is that we have a Domain Specific Language (DSL) tailored to each engine. There is no way to reconcile this as the underlying engines are not the same, which is good from a legal standpoint as it proves to Bethesda that OpenMW is a clean-room reverse engineering effort. This might not be a good thing to hear to end users who really don’t care, but this is very important to us to keep the project in a safe legal position.

Some of the work done for both MWSE and OpenMW can be bridged though, as we could sit down and define higher-level API that modders can use that in turn would make platform-specific calls to either MWSE or OpenMW. In theory a determined modder or group of modders can already build off what both projects have done and create the common API. I think both projects would support this endeavour and help provide support. 

As the saying goes, don’t let your dreams be dreams.

Any favourite mods?

Oh gosh, the original one that got me into OpenMW was Zini‘s ambitious Ultima Total Convertion which originally used Morrowind.exe to remake Ultima 9 with the original script/ideas. Ultima IX: Redemption is what brought Zini to OpenMW as it was clear that Morrowind.exe couldn’t handle the vision. You can hear more about this with Zini’s interview with DarkElfGuy here. This was also why he was adamant about having OpenMW-CS, our editor. 

So while the project was abandoned, the assets were released and I contacted as many modders as I could find and got their permission to release a ‘libre edition’ that allows anyone to use the assets based on the CC-BY or even CC0 licences. You can download them here.

I also want to throw out how much I respect the Tamriel Rebuilt team and all the blood, sweat and tears they’ve poured into their labour of love. Same goes for the MWSE and MGE XE contributors.

If you could change one thing about OpenMW, what would it be?

Nothing… really, well, maybe the ability to “play” other TES games and Fallout. ;)

2024-04-11 - jvoisin - No pingbacks so far.

To eliminate any potential confusion, this post was originally published on the 1st of April, and Unity is terrible. If you must use an engine other than OpenMW for your next project, why not try an open-source alternative such as Godot?

Original article below:

As technology surges forward, video games are becoming more visually stunning and performant than ever before. To keep pace, OpenMW must evolve. With OpenGL being phased out in favor of Vulkan, GPUs gaining more muscle, and CPUs packing an increasing number of cores, we must either adapt or risk obsolescence.

This is why we’re making a bold move and switching our main engine once again. In the past, we’ve transitioned from OGRE to OpenSceneGraph. And now, the time has come to embrace the future and choose Unity. 

Why Unity?

Unity is not just something that will dramatically alter the course of our progress — it is also a platform that aligns more closely with our values. Despite being closed-source, Unity boasts several advantages over our current engine: solid leadership, first-class mobile support, a healthy enterprise culture, generative AI integration, publicly traded status, and a rock-solid reputation in the industry.

Exciting Prospects

We’re thrilled about the possibilities that this move opens up for us. For one, it means that we will finally be able to transpose OpenMW from C++ to D♭. Also, while we currently only target the niche operating systems Windows, macOS and GNU/Linux, the switch will let us effortlessly provide OpenMW builds for mainstream platforms such as Google Stadia, modern BlackBerries and Samsung TV. Furthermore, Unity’s advanced high-performance graphical capabilities will open the door to cutting-edge rendering techniques like ray-tracing, ray-coloring, ray-scribbling and ray-watercolor-painting.

Fueling the Ambitions

Unfortunately, embracing Unity means we’ll need to gather funds to cover its embracing fees. Since OpenMW as a whole does not accept donations, we’ll fund the project tentatively codenamed “Tribunity” through three primary avenues:

• We’ll create our very own marketplace for downloadable content created by the community. To promote it, we’ll start by publishing a few exclusive creations of our own, such as map marker-based fast travel, an armour pack for pack guars, Centurion Tetrahedrons, and cosmetics like a Dwarven monocle.
• Thanks to the Unity Ads SDK‘s comprehensive monetisation framework, we’re planning on integrating a couple of minimally invasive and tasteful ads into the game via natural surfacing points, like loading screens. Naturally, we’ll have to modify the game slightly to abide by the rules set by ad publishers, but fortunately, the required adjustments will be limited to omitting the usage of and references to alcohol, drugs, slavery, racism, violence, blood, religious blasphemy, crude humor, suggestive themes, partial nudity and Wood Elves.
• For players outside of California and the European Union, we might share some anonymised playthrough and associated data with various partners. We will respect our users’ privacy and will not¹ include references to adult content from their content lists in this information.

We can’t wait to release Tribunity and for you to enjoy it with us!

1.  terms and conditions may apply ↩︎

2024-04-01 - jvoisin - No pingbacks so far.