Older bump mapped mods (and how to make them work in OpenMW)

Post about your mods, learn about OpenMW mod compatibility, check for problematic mods, discuss issues, and give us feedback about your experience with modded OpenMW.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by AnyOldName3 »

We're only going to end up displaying what you'd get if you mistakenly loaded a bump-mapped mod in the vanilla engine without MCP, so it's not like we're bending to the whims of other projects.
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by lysol »

Oh, right. I always thought vanilla MW displayed them like OpenMW does.
User avatar
Starsheep
Posts: 54
Joined: 06 Jun 2018, 16:09

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by Starsheep »

yeah if you figure out a workaround to make the fake bump mapping of meshes designed for mcp look "ok-ish" out of the box instead of the current shiny-metal effect even though it's not proper normal maps, that would be great.

When I built my load out, I went through a whole manual correction of nifs and that took a lot of time. The average user is not going to do that.

Sure it shouldn't be in the scope of the engine, but more straight compatibility with existing mods -> less complaining -> more acceptance of OpenMW by the community.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by AnyOldName3 »

We have the ability to replicate MCP's bump mapping system exactly, but it would just involve removing the vanilla-style environment mapping altogether. I don't know if any vanilla content or mods actually relies on the non-MCP behaviour, but pre-1.0, we shouldn't be removing features which the vanilla engine had.
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by lysol »

AnyOldName3 wrote: 12 Aug 2018, 22:00 We have the ability to replicate MCP's bump mapping system exactly, but it would just involve removing the vanilla-style environment mapping altogether. I don't know if any vanilla content or mods actually relies on the non-MCP behaviour, but pre-1.0, we shouldn't be removing features which the vanilla engine had.
Don't think any vanilla content uses the environment mapping, but there are mods that does.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by akortunov »

So what we decided to do?
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by lysol »

akortunov wrote: 17 Aug 2018, 06:19 So what we decided to do?
Well I kind of misunderstood this a bit at the beginning, so:
AnyOldName3 wrote: 12 Aug 2018, 19:24 We're only going to end up displaying what you'd get if you mistakenly loaded a bump-mapped mod in the vanilla engine without MCP, so it's not like we're bending to the whims of other projects.
Re-reading the previous posts, I get it. OpenMW doesn't care about "Bump Map Luma Scale", which the vanilla engine does, and mods that actually uses environment mapping will have a high Bump Map Luma Scale parameter, so those will still look as intended.

Sorry for being stupid. Of course this should be fixed.
User avatar
AnyOldName3
Posts: 2666
Joined: 26 Nov 2015, 03:25

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by AnyOldName3 »

But fixed to look like MCP or fixed to look like vanilla?
User avatar
lysol
Posts: 1513
Joined: 26 Mar 2013, 01:48
Location: Sweden

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by lysol »

Like vanilla imo. The MCP way was just an ugly hack, but it was the only way to do it. It makes some mods that actually use the environment maps not look as intended too, as I've understood it.

Converting mods that rely on the MCP hack makes the normal maps look a lot better and is fairly easily done. I've converted and uploaded one of the most common old normal mapped mods on the Nexus, and the only reason I didn't upload more conversions is because it was so hard to get in touch with the original creators. I was planning to upload a lot of comverted mods actually but the lack of contact info made me lose interest in that project.
User avatar
Capostrophic
Posts: 794
Joined: 22 Feb 2016, 20:32

Re: Older bump mapped mods (and how to make them work in OpenMW)

Post by Capostrophic »

Okay. A month ago I was fairly ignorant about all these EMBM (environment-mapped bump mapping) matters (I still am about many things), but now I have some idea about how to reimplement Morrowind-like bumpmapping in OpenMW, and maybe conjure up something for 0.46.0 if someone doesn't happen to be faster than myself or I'm motivated enough to finish up something for 0.45.0.

To elaborate: a bumpmap's chroma channel (RGB part of the texture) is a heightmap. In Morrowind's case, that heightmap is applied to the environment map, resulting in lighter texels of the bumpmaps corresponding to the environment map texel to result in a more intense environment map being applied to the surface, and darker texels lowering the intensity of the correspondent environment map texel. Practically this results in a 0.0-2.0 range of multipliers being applied to every texel of the environment map, where 50% gray ~#888888 is 1.0 multiplier.
However, there's also the luma channel of the bumpmap (alpha channel of the texture). Also called the luminance channel, it allows a more fine-grained control over the luminance of every bumpmap texel. Every texel of the luma channel acts as a multiplier (0.0 to 1.0 from black to white) for the correspondent bumpmap texel. A heightmap for a heightmap.

Luma scale setting is another multiplier, and it allows to control the luminance of the luminance channel. Every texel of the luma channel is multiplied by luma scale value.

Luma offset is added to that new value and brightens up the luma channel. It can be negative, then it'll darken the channel.

The difference of luma scale and luma offset is that while luma scale increases the value of a texel by N times, luma offset increases the value of a texel by N.

Luma matrix name is somewhat misleading. It adjusts the UV of the whole bumpmap before it's applied to the environment map. Every texel of the bumpmap gets a new coordinate. I'll give an example:
We have a matrix of (0.5; 0.25; 0.6; 1.0).
We have the coordinates of a bumpmap texel x and y. (Here we copy these original coordinates because we can't work with a modified x).
Note that x and y change from -1 to 1.
x = 0.5x + 0.25y;
y = 0.6x + y;

Practical result is that the bumpmap is displaced relatively to the environment map and the same texel of the environment map might get a different intensity depending on its real position.
By default the values of luma matrix are (1, 0, 0, 1), so the UV is unchanged. Some mod authors decide to randomly change the values of it (I guess they don't understand the consequences).

akortunov's current texture_effects branch implements just the luma scale of the bump map as a replacement for environment map color parameter can mess up the environment map color of an enchanted item (it hasn't been tested). I've set up a branch with changes that make the luma scale and luma offset apply to the environment map itself, roughly mimicing their original effect, but it's not exactly correct. To properly apply these parameters and luma matrix EMBM must be reimplemented in full.

This is all just guesswork that kind of makes sense, there's no proper documentation for most of this.

Reimplementing EMBM for OpenMW is *not* bad. It allows to have better support for supposedly legacy content that uses NIF files. A side effect would be that it won't be possible to apply a specific normal map for the mesh and you'll have to use the autodetection option, but the assumption of bumpmaps in meshes being normal maps doesn't make sense from the first place anyway.
Post Reply