Mirroring normal maps... too much to ask?

[Rick Nightingale]

It would be incredibly useful in my opinion to be able to mirror a normal map and have it work 'properly'. I often want to mirror a texture on a build, which saves UV space and texture memory, or would if I could also mirror the normal map. For those wondering what I'm on about, see the pictures.

All that's needed is to invert the red channel for a horizontal mirror, for instance. Would it be asking too much of the viewer to be able to do this if the normal map scale is negative? Or would it cause some issues I've not thought of? (other than possibly breaking existing content - it would need a new checkbox to enable the inversion, not just do it automatically to every existing mirrored normal map). Or... am I just missing something alltogether?

In these pictures, light is coming from the right. The top images show a normal map on the left, and the same normal map but scaled -1 on the right. Note the opposite shading. The bottom pictures have the same UV map on the left, with a mirrored but a red-inverted UV map on the right. I did that in photoshop but the viewer could do it on the fly.

[Wulfie Reanimator]

Huh, seems more like an oversight. I can't imagine why anyone would think the current behavior should be normal. (Pun not intended.)

[OptimoMaximo]

20 hours ago, Rick Nightingale said:

It would be incredibly useful in my opinion to be able to mirror a normal map and have it work 'properly'. I often want to mirror a texture on a build, which saves UV space and texture memory, or would if I could also mirror the normal map. For those wondering what I'm on about, see the pictures.

All that's needed is to invert the red channel for a horizontal mirror, for instance. Would it be asking too much of the viewer to be able to do this if the normal map scale is negative? Or would it cause some issues I've not thought of? (other than possibly breaking existing content - it would need a new checkbox to enable the inversion, not just do it automatically to every existing mirrored normal map). Or... am I just missing something alltogether?

In these pictures, light is coming from the right. The top images show a normal map on the left, and the same normal map but scaled -1 on the right. Note the opposite shading. The bottom pictures have the same UV map on the left, with a mirrored but a red-inverted UV map on the right. I did that in photoshop but the viewer could do it on the fly.

You should actually invert the UVs normals to have that behavior. If you mirror the UVs so that they're flipped, then a negatively scaled normal map would offset the placement of the red channel back to its original shaded look.

[Rick Nightingale]

You are quite right @OptimoMaximo, that does indeed work.

It requires, however, uploading two versions of what could otherwise be a single mesh asset, duplicated and rotated in world (assuming it has rotational symmetry which is the case here). It also then means dealing with an object with an inherently mirrored texture, an irritation should I want to apply different (not mirrored) textures afterwards to each object. I would have to mirror/invert everything before upload and could not simply use existing textures (if I want normal maps too). I do like to design things to be easy to retexture by myself or others.

And of course it cannot apply to prim builds.

I think as @Wulfie Reanimator said, it must be an oversight in the viewer's treatment of 'manually' mirrored normal maps, since I can't see any advantage to having highlights and shadows the wrong way around.

Edited April 1, 2023 by Rick Nightingale

[OptimoMaximo]

IMHO, what you're looking for is a bit too much, @Rick Nightingale DDon't get me wrong, it would make a pretty useful feature indeed. But consider also the practices found in the real world game industry. With the current tech advancements, do you believe nobody has ever thought of such a thing before? And yet, kit bash creators still use asset naming conventions to group models into batches and their mirrored versions. And game engine shaders do not have any of these options built in (although it can be made manually where material instances are a thing).

So i guess your final statement should be re-evaluated. It's definitely not an oversight in how the rendering pipeline works. That is indeed something it should be managed on the asset level, also to more easily keep track of what is what, instead of having to go into the editing tools to check. The fact that it looks shaded the other way around is a biproduct of the intended behavior, it is the mirroring technique that goes out of the standard (basic) practices.

[ChinRey]

15 hours ago, OptimoMaximo said:

IMHO, what you're looking for is a bit too much

I'm not sure but isn't this just a matter of changing the swizzle? If so, it should be easy to implement and it could be useful for some other purposes as well. The viewer already has code for inverting a channel of a texture even. Maybe that code could be reused for normal maps?

The fact that no other game/VR engine has it isn't really an argument. Such a function is only really useful as part of an advanced in-world texture manipulating system and that's something only SL and opensim offer.

[OptimoMaximo]

1 minute ago, ChinRey said:

The fact that no other game/VR engine has it isn't really an argument.

As I said, I would see such a feature quite useful. However, the point about real scale engines not offering this feature as a built-in (but those that use material instancing would theoretically allow making it yourself) is indicative AND an argument. See, those professionals have hit this issue for a long time before anyone in here could even notice it. And yet, the creation pipeline was established to account for that anyway, just OUTSIDE of the shader implementation, for a simple reason that I pointed out briefly: having that feature on a separate asset makes it easier to recognize what is what, as opposed to a material/shader feature being enabled or not, which requires going into that other asset and check what's the setting.

This is especially true when the person handling the asset for practical use isn't the same as the person who created it and, even in the latter case, who would be likely to remember all the details of their own kitbash parts after some time, when most likely they have made a couple of kits per month?

So the point is to see why a certain feature, however useful might it be, isn't being used by those that work on this stuff on a daily basis for a living. Trying to analyse such reasons gives an understanding of processes and why it is better not to have some useful features when those might affect the production downstream pipeline.

[Fluffy Sharkfin]

On 4/2/2023 at 11:55 AM, OptimoMaximo said:

So the point is to see why a certain feature, however useful might it be, isn't being used by those that work on this stuff on a daily basis for a living.

Because the vast majority of those people aren't developing for a platform built entirely from user-created content.  Second Life requires end users to have as much control as possible over how content is displayed whereas most game developers are entirely responsible for creating and optimizing all of the environments, props and characters and provide users with little to no ability to directly modify any of the content within the game/platform.

On 4/2/2023 at 11:41 AM, ChinRey said:

I'm not sure but isn't this just a matter of changing the swizzle? If so, it should be easy to implement and it could be useful for some other purposes as well. The viewer already has code for inverting a channel of a texture even. Maybe that code could be reused for normal maps?

It should be a matter of simply providing a couple of extra checkboxes in the texture tab of the build window which when checked will invert the red or green channel of the normal map, this would allow users to flip a normal map horizontally and/or vertically and then invert the corresponding channel(s) to compensate for the reversed texture orientation.

[Rick Nightingale]

I had posted a reply here a few days back - it's vanished!

My thoughts on the matter echo @Fluffy Sharkfin's. The ability to automatically correct a mirrored normal map in SL makes far more sense than having to upload a (possibly 'duplicate') mesh with a reversed UV map which makes re-texturing later a total pain.

Wonder if it's worth putting in a feature request... might do later. Although I have to agree with @OptimoMaximo's comment that someone else must surely have thought of it already. That's sort of why I asked here, in case I had missed it something.

[ChinRey]

1 hour ago, Fluffy Sharkfin said:

It should be a matter of simply providing a couple of extra checkboxes in the texture tab of the build window which when checked will invert the red or green channel of the normal map, this would allow users to flip a normal map horizontally and/or vertically and then invert the corresponding channel(s) to compensate for the reversed texture orientation.

That's what the normal map's swizzle means: http://wiki.polycount.com/wiki/Normal_Map_Technical_Details

 

1 hour ago, Rick Nightingale said:

Wonder if it's worth putting in a feature request... might do later.

Now is the only time there's even a hint of chance LL will process such a feature request. The chance increases slightly if you focus on the fact that it will make SL compatible with both Unity and UE.

[Rick Nightingale]

59 minutes ago, ChinRey said:

Now is the only time there's even a hint of chance LL will process such a feature request. The chance increases slightly if you focus on the fact that it will make SL compatible with both Unity and UE.

I'll get on it later tonight!

[OptimoMaximo]

6 hours ago, Fluffy Sharkfin said:

It should be a matter of simply providing a couple of extra checkboxes in the texture tab of the build window which when checked will invert the red or green channel of the normal map, this would allow users to flip a normal map horizontally and/or vertically and then invert the corresponding channel(s) to compensate for the reversed texture orientation.

You say correctly, "should". I'd remind you that what you have in the build windows is a texture asset, any changes made on one instance would be propagated to all instances, because the only asset type that actually uses instancing in SL is the texture asset. When you apply a texture to an object, that texture keeps its uuid, as opposed to any other asset that once rezzed gets it's own uuid.

 

4 hours ago, ChinRey said:

That's what the normal map's swizzle means:

Whats not explained there is that the handedness of some vector data also means a space mirroring, that in case of the Y axis fortunately just causes normals direction flipping. However, to keep consistent tangent space and binormals, once we flip another axis, there should be a compensation by either flipping another axis, or swapping the remaining pair (which basically switches the reference world up axis). (I learned all this while writing an exporter for vertex animated shaders from Maya Y up to unreal z up)

[ChinRey]

47 minutes ago, OptimoMaximo said:

You say correctly, "should". I'd remind you that what you have in the build windows is a texture asset, any changes made on one instance would be propagated to all instances, because the only asset type that actually uses instancing in SL is the texture asset.

No, it's perfectly possible to have a texture/map modifier that only is applied to a single instance of the asset: store it as a prim property and apply it client side. SL already has several texture/map modifiers that are handled this way.

[Rick Nightingale]

Feature request done, for what it's worth.

[OptimoMaximo]

33 minutes ago, Rick Nightingale said:

Feature request done, for what it's worth

Good luck!

[OptimoMaximo]

On 4/6/2023 at 3:54 PM, Fluffy Sharkfin said:

Because the vast majority of those people aren't developing for a platform built entirely from user-created content.  Second Life requires end users to have as much control as possible over how content is displayed whereas most game developers are entirely responsible for creating and optimizing all of the environments, props and characters and provide users with little to no ability to directly modify any of the content within the game/platform.

I must have missed this bit somehow.

Let me give you a frame of reference that puts things in a better perspective.

The control to the final user you talk about is de facto transferred to the people in the recipient studio that have to work with said content. So the same control you're advocating for, even though it's true that is not going to the end user intended as a consumer of the final product, is going to another type of "end user". The environment artist who makes the modules for a certain building is more often than not a different person than the level designer/layout artist, most likely to not even be sitting in the same studio, these days.

So what you're saying as a need for SL and not for a game studio is definitely applicable to a real studio, maximum ease of use as a first rule of production. And for this reason, not knowing where/who the models pack is going to, the general rule still is to name everything according to a series of identifiers, among which there is also a "mirrored" or similar keyword, where the scale tools do not help with negative scaling.

[Fluffy Sharkfin]

13 hours ago, OptimoMaximo said:

I must have missed this bit somehow.

Let me give you a frame of reference that puts things in a better perspective.

The control to the final user you talk about is de facto transferred to the people in the recipient studio that have to work with said content. So the same control you're advocating for, even though it's true that is not going to the end user intended as a consumer of the final product, is going to another type of "end user". The environment artist who makes the modules for a certain building is more often than not a different person than the level designer/layout artist, most likely to not even be sitting in the same studio, these days.

So what you're saying as a need for SL and not for a game studio is definitely applicable to a real studio, maximum ease of use as a first rule of production. And for this reason, not knowing where/who the models pack is going to, the general rule still is to name everything according to a series of identifiers, among which there is also a "mirrored" or similar keyword, where the scale tools do not help with negative scaling.

I agree that in most cases the individual creating the assets will not be the same person responsible for their implementation within a game engine but there are still considerable differences between a level designer working as part of a development team and the way in which SL residents utilize assets within SL.

To use your "mirrored" keyword as an example, if a level designer were facing the same issue being described in this thread they could simply ask one of the coders to add an additional function within the shader which would automatically invert the appropriate channel of the normal map whenever it encounters an asset which contains the "mirrored" keyword, whereas obviously SL residents don't have the ability to modify the shaders used to display the assets they're working with.

Incidentally both Unreal and Unity do support texture mirroring.  In Unreal Engine you can mirror a texture simply by multiplying the UV coordinates by -1 on the required axis (similar to how textures are mirrored in SL) while in Unity you can set the TextureWrapMode to Mirror/Mirror Once rather than Repeat and then offset the texture accordingly.

As an alternative to adding checkboxes which allow users to manually invert the red or green channel of a normal map LL could potentially implement a similar approach to the one used in Unity and provide the option to toggle between either repeating or mirrored tiling and then automatically invert the correct channel within the shader each time the mirrored version of the normal map is displayed, then rather than setting the texture scale to -1 residents could set the texture offset to 1.0 on the required axis in order to display a mirrored version of the textures/materials.

[OptimoMaximo]

18 hours ago, Fluffy Sharkfin said:

Incidentally both Unreal and Unity do support texture mirroring

Incidentally, all engines do. The inversion of a channel can be simply put in a base material implementation and either be instanced (unreal) or copied over and over, that's not the point.

But again, as I said 3 times already by now, I would see such a feature as a useful one. Just would not recommend using it, for the reasons I already explained twice.

With this said, good luck with getting LL to give you what you want.

[Rick Nightingale]

The request has been accepted. That's a start...

https://jira.secondlife.com/browse/BUG-233720

 

[Rick Nightingale]

Necro-bumping this because the JIRA report, which was accepted, seems to have got lost with the changeover to the new 'feedback' system. Given that PBR is still being worked on, and the issue still exists, it's the best time to push for change.

If you want to be able to reverse a normal map and have it still reflect in the correct direction, like other rendering engines do, please upvote this:

https://feedback.secondlife.com/bug-reports/p/normal-map-tangents-are-wrong-if-normal-map-is-mirrored-with-the-edit-tool

 

Edited June 18 by Rick Nightingale