Textures Invert On Primitives When Flipped.

[chancefaolan Kiko]

I am facing difficulties with maintaining consistent texture across my build. Upon observing walls, I have found that the texture undergoes an inversion when the object is flipped or when the identical texture is placed on both sides. Upon examining my photograph, I have observed a distinct polarization phenomenon that can only be reversed by inverting the object. In order to maintain the pristine appearance of the white surfaces on both sides of the wall, I must construct two separate prims for each side. I have observed a recurring problem with mesh tubing, wherein its texture consistency is compromised when I attempt to align gutters or pipes within a larger system. I am unable to resolve the issue by modifying the parameters of the textures in the primitives.

[Qie Niangao]

10 minutes ago, chancefaolan Kiko said:

The images were captured from Firestorm viewer. However, individuals using different viewers that visited my island have verified that what I perceive is indeed what they observe.

Right, I was just casting about for a reason it's happening, and PBR being the new thing, there's some lighting behaviors not entirely familiar yet. But that doesn't seem a productive line of investigation here. And the normal map hypothesis turned out to be another dead end because even without it, "the image retains its negative visual representation" and I'm pretty stumped, at least without seeing the problem "in person". (I'm not quite sure, now, whether the issue is unique to this particular texture, or a general observation about how textures work in SL.)

So I hope somebody else recognizes this. 

[Qie Niangao]

Aha! It was the normalmap after all! I think you'll find things behave much more as expected with that "Synchronize Materials" checkbox enabled at the bottom of the build tool. (That's what Firestorm calls it; it's called "Lock repeat' in the Linden and Catznip viewers and probably others.) 

[animats]

16 hours ago, chancefaolan Kiko said:

lighter-toned areas of the normal map,

A normal map is a set of vectors, stored as XYZ values in RGB color format. All the vectors are supposed to have unit length. If you have light and dark areas in the normal map, your normal map is broken. All the cells should have roughly the same intensity.

[Qie Niangao]

Do these surfaces have a normal map, in addition to the texture? If so, I wonder what happens if it's removed as an experiment.

(Admittedly, I'm not really understanding what is shown in the picture, so the normal map may have nothing to do with anything. I feel like I need to move my cam around to see the lighting. Somebody else might recognize something simple happening here that I'm missing.)

Also, is this in a PBR viewer? like the current Linden viewer, or a Firestorm PBR alpha, etc? If so, there's not a reflection probe involved by any chance?

[chancefaolan Kiko]

Indeed, each of these fundamental primitives is equipped with a normal map to enhance their textures. Removing the map results in a significant decrease in clarity, while the image on the opposite side remains darker. Furthermore, the image retains its negative visual representation compared to its positive counterpart, resulting in a reversal of brighter parts in the opposite image.

When I make a simple cube, the image on all four sides stays the same, but it appears darker and negative compared to how it looks in the inventory selection. By inverting the cube, the image seen in this photo undergoes a transformation where dark regions become light and light regions become dark. To achieve the desired image, I can rotate the image by 180 degrees on the inverted cube. This will result in the image being displayed in white on all four sides of the cube.

While rotating mesh AO images can serve as a temporary solution for certain problems, it may not always be feasible due to limitations in its UV map. The images were captured from Firestorm viewer. However, individuals using different viewers that visited my island have verified that what I perceive is indeed what they observe.

[chancefaolan Kiko]

While further investigating this phenomena, I observed further anomalies in the manner in which textures were being utilized on fundamental shapes, such as the extended box. These images of wall parts extracted from my home demonstrate that diffuse textures are placed at the appropriate angle, however the normal maps are applied in an inverted manner, necessitating a 180-degree rotation to achieve proper alignment with the diffuse.

The second image depicts the unaltered normal map being applied to an unadorned cube of identical orientation, without any rotation of the image for the sake of comparison. The same principle applies to the specular map, however it is contingent upon the specific face of the cube that you are now working on. In any case, the textures are not being applied with their original orientation in a consistent manner with the others as they were initially uploaded and saved.

 

Edited January 7 by chancefaolan Kiko

[Frionil Fang]

On non-PBR materials, you're not supposed to have negative scaling or rotation the normal map or else it'll be wrong. The rotation and scaling are not accounted for for computing the light direction, so you get an inverted direction in the best case (both X and Y scaling are negative, or the normal map is rotated 180 degrees) or a non-physical direction that makes no sense with how light lands on it for anything else.

If you use the "synchronize materials" checkbox as suggested, then you also cannot rotate or negative scale the diffuse because that will, as it says, apply the negative scaling and rotation to the normal map.

[chancefaolan Kiko]

On 1/8/2024 at 1:31 PM, Frionil Fang said:

On non-PBR materials, you're not supposed to have negative scaling or rotation the normal map or else it'll be wrong. The rotation and scaling are not accounted for for computing the light direction, so you get an inverted direction in the best case (both X and Y scaling are negative, or the normal map is rotated 180 degrees) or a non-physical direction that makes no sense with how light lands on it for anything else.

If you use the "synchronize materials" checkbox as suggested, then you also cannot rotate or negative scale the diffuse because that will, as it says, apply the negative scaling and rotation to the normal map.

 

PBR materials should not determine the reflection of light only based on its rotation, without considering the light source's direction. If a spinning disk maintains a constant angle and rotation relative to its light source, a white texture on its surface should not exhibit oscillations between gray and white.

In my complaint, I explained that in order to achieve accurate shading of my textures on both sides of a wall, I had to initially construct a cube and subsequently rotate it 90 degrees along its axis. Failure to do this task will result in the inability to get the desired shade of texture reflection on both sides of the wall constructed from that cube. The issue at hand is closely linked to the normal map, as there is a flaw affecting how the new Physically Based Rendering (PBR) technology produces the texture as a whole.

 

Edited January 10 by chancefaolan Kiko

[Qie Niangao]

13 hours ago, chancefaolan Kiko said:

PBR materials should not determine the reflection of light only based on its rotation, without considering the light source's direction. If a spinning disk maintains a constant angle and rotation relative to its light source, a white texture on its surface should not exhibit oscillations between gray and white.

In my complaint, I explained that in order to achieve accurate shading of my textures on both sides of a wall, I had to initially construct a cube and subsequently rotate it 90 degrees along its axis. Failure to do this task will result in the inability to get the desired shade of texture reflection on both sides of the wall constructed from that cube. The issue at hand is closely linked to the normal map, as there is a flaw affecting how the new Physically Based Rendering (PBR) technology produces the texture as a whole.

I'm not sure whether this is a whole new topic or how the subject drifted into PBR materials given that the original question was about non-PBR normalmaps applied and viewed in a non-PBR viewer (which became clear from the Build Tool's "Materials" pulldown label, rather than "Textures").

I don't claim to understand the practical limits on rotating (non-PBR) normalmaps other than to observe that scripts can't set negative offsets on normalmaps which is probably quaintly related.

But I do know this: This picture:

On 1/7/2024 at 6:38 PM, chancefaolan Kiko said:

 

shows a normalmap inverted (either by rotation or vertical scale) from its corresponding diffusemap, and that's just sure to be wrong regardless of light source or object orientation. If something else is going on here, I'm not seeing it.

[chancefaolan Kiko]

Physically Based Rendering is a very recent subject, particularly in the context of Second Life, which adds to the challenge of explaining my problem. Be confident that the topic did not deviate into this because, without the normal map applied, the video given here would not illustrate my issue.

Based on the video, it is clear that the cube's angle and orientation stay consistent with respect to the light source, although the diffuse texture appears gray, giving the impression of shading. The white portion of the wall appears grey due to the grey coloration of its corresponding normal map in those specific areas.

Upon closer analysis of the texture, it becomes apparent that light is exclusively delivered perpendicular to the lighter-toned areas of the normal map, rather than to the diffuse map in its entirety. The map appears to function as the diffuse map as the object rotates.

Edited January 11 by chancefaolan Kiko

[Love Zhaoying]

1 hour ago, chancefaolan Kiko said:

Upon closer analysis of the texture, it becomes apparent that light is exclusively delivered perpendicular to the lighter-toned areas of the normal map, rather than to the diffuse map in its entirety. The map appears to function as the diffuse map as the object rotates.

I know it is not a desired functionality for you, but I just noticed that the effect is similar to a "polarizing" lens!

[Qie Niangao]

Oh, that gif is different from what I thought I was seeing in the static images. I took a screenshot of the normalmap to make sure there wasn't some funky tangent-space complication or something, and no, it's simply that the surface depicted in the gif has the normalmap either rotated 180 degrees or Y-scaled by -1 (but not both, which for these purposes would cancel each other out). To make it all more intuitive, it may help to start with no diffusemap at all (just the blank texture) and make sure the normalmap is oriented correctly, then apply the diffusemap in identical scale and offset as the normalmap.

(What's bothering me about this is that I'm still not understanding how the build process suggested flipping any of the maps in the first place. I feel like I'm still probably missing something about the problem description, despite having re-read it a dozen times at this point.)

Edited January 11 by Qie Niangao

[Love Zhaoying]

12 minutes ago, Qie Niangao said:

(What's bothering me about this is that I'm still not understanding how the build process suggested flipping any of the maps in the first place. I feel like I'm still probably missing something about the problem description, despite having re-read it a dozen times at this point.)

If I understand correctly, while building they are flipping the object (since it can go either 1 way or the other, having what appears to be "crown molding"). The map gets flipped just because they flip the object with the map already applied. It doesn't sound like they are trying to flip the maps intentionally (just the object).

[Qie Niangao]

43 minutes ago, Love Zhaoying said:

If I understand correctly, while building they are flipping the object (since it can go either 1 way or the other, having what appears to be "crown molding"). The map gets flipped just because they flip the object with the map already applied. It doesn't sound like they are trying to flip the maps intentionally (just the object).

Well, but the map doesn't get flipped like this (basically, y-inverted) just because the object is upside down. That narrow strip at the "bottom" of the wall, for example should appear to protrude whether the wall is rightside up or upside down—and it does as long as the normalmap isn't y-inverted on the surface. (It's possible to make a normalmap for Unreal Engine / DirectX instead of Unity/OpenGL, which have inverse Y normals, but this is an OpenGL normalmap; you can tell because the map itself appears to be "green lit" from the top.)

Edited January 11 by Qie Niangao
"inverse" less confusing than "inverted" maybe

[chancefaolan Kiko]

6 hours ago, animats said:

A normal map is a set of vectors, stored as XYZ values in RGB color format. All the vectors are supposed to have unit length. If you have light and dark areas in the normal map, your normal map is broken. All the cells should have roughly the same intensity.

Here is the usual normal map that I use for the interior walls. This specific normal map was acquired from a commercial product that I have been using for a good while. As you can see, this map is visually pleasing and functions, at least for me, beautifully, provided that the entire object is not rotated. The issue I am currently facing is of recent origin and is probably linked to recently incorporated functionalities.

However, it is not limited to only this map. Every white diffuse texture that is accompanied by a normal map in my observations, behaves in the same manner as seen in my video. My issue is not with these normal maps, but rather with the inherent flaws I believe exist within Second Life itself, particularly its rendering capabilities.

One last piece of observation I should like to say is that if I were to use a filter to convert this image into grayscale, the resulting output would closely resemble the shadowing effect that I showcased in my GIF. The confusion may have arisen when I referred to the gray sections of the normal map, which I was examining in relation to the texture modification of my rotating wall.

Below is the Diffuse Texture

Below here is the normal map transformed to grayscale in Gimp, rotated for comparison, then merged with the diffuse map layer.

Displayed below is an image captured in Second Life, depicting an object that has been inverted by rotating it upside down. As depicted in this image, the texture closely resembles the grayscale image that I combined with the diffuse map using Gimp.

In my opinion, the rendering engine of Second Life is problematic since it essentially combines a grayscale version of the normal map with the diffuse map when the object is rotated, similar to what I accomplished in Gimp.

 

 

Edited January 12 by chancefaolan Kiko

[Qie Niangao]

8 hours ago, animats said:

A normal map is a set of vectors, stored as XYZ values in RGB color format. All the vectors are supposed to have unit length. If you have light and dark areas in the normal map, your normal map is broken. All the cells should have roughly the same intensity.

Unit vectors have X, Y, and Z values that range from -1 to 1 but (8-bit) RGB values range from 0 to 255, so a normal of <-1,-1,1> will map to an RGB of <0, 0, 255>, won't it? (They're always bluish because they represent vectors outwards, so positive Z, from the texture surface tangent, so should have blue-channel values ≥ 128.)

[Edit2: Double Doh! See @Frionil Fang's correction. Normals are unit vectors and <-1,-1,1> is no unit vector. Sorry.]

Edited January 12 by Qie Niangao
Doh! not <0, 0, 256>

[Wulfie Reanimator]

3 hours ago, Qie Niangao said:

Unit vectors have X, Y, and Z values that range from -1 to 1 but (8-bit) RGB values range from 0 to 255, so a normal of <-1,-1,1> will map to an RGB of <0, 0, 255>, won't it? (They're always bluish because they represent vectors outwards, so positive Z, from the texture surface tangent, so should have blue-channel values ≥ 128.)

That's right. The "flat normal" blue is <128, 128, 255> (RGB) as in <0, 0, 1> (vector) relative to the face itself (in tangent space).

The darkest strip of color in the wall's normal map corresponds to about a +30 degree angle on the Y axis, which is a valid value for an overhang.

When the object is rotated 180 degrees, the "bottom" of the overhang becomes exposed to light, and shading should disappear. That works.
When only the normal map is rotated 180 degrees, the face's shading doesn't change. That's a bug.

So the problem appears to be that the renderer's texture-shading part doesn't consider texture transformations at all (rotation nor scale).

P.S. I'm glad someone else noticed the slightly-off normals. I thought I was losing my mind or it would've been due to compression. 😋

Edited January 12 by Wulfie Reanimator

[Frionil Fang]

3 hours ago, chancefaolan Kiko said:

Here is the usual normal map that I use for the interior walls. This specific normal map was acquired from a commercial product that I have been using for a good while. As you can see, this map is visually pleasing and functions, at least for me, beautifully, provided that the entire object is not rotated.

The normal map is not "level":

Compared to the neutral normal map colored square at the bottom right it's visibly different in overall brightness/tone, so it will respond differently depending on the light direction - the entire surface is slanted, in other words.

It looks like it was saved with an incorrect color profile or something along those lines. Normal maps should never use a color profile and be linear color, not sRGB. If I manually butcher it to ~0.82 gamma with a levels adjustment, it will more or less match the neutral color overall and retain its general shade while rotating the object, but that's a dirty eyeballed hack job. Ideally you'd use normal maps that aren't flawed to begin with.

2 hours ago, Qie Niangao said:

Unit vectors have X, Y, and Z values that range from -1 to 1 but (8-bit) RGB values range from 0 to 255, so a normal of <-1,-1,1> will map to an RGB of <0, 0, 255>, won't it? (They're always bluish because they represent vectors outwards, so positive Z, from the texture surface tangent, so should have blue-channel values ≥ 128.)

Well *ackshually* a -1, -1, 1 is not a valid unit/normal map vector, the magnitude is a unit, not the components themselves. The correct normal vector would be -1/√3, -1/√3, 1/√3, corresponding to the rgb color 53, 53, 212. SL does accept a non-normalized normal map though and you might get away with it without visible issues, the values are normalized before use.

2 hours ago, Wulfie Reanimator said:

So the problem appears to be that the renderer's texture-shading part doesn't consider texture transformations at all (rotation nor scale).

That may be part of it, PBR material rendering compensates for negative scaling and rotations of the normal map, non-PBR does not. The only proper value is a positive scale on both axes and 0 rotation, but the 180 degree rotation (or both axes negatively scaled) will at least be "correct" as in physically sensible, only inverted in direction.  

[chancefaolan Kiko]

38 minutes ago, Frionil Fang said:

The normal map is not "level":

Compared to the neutral normal map colored square at the bottom right it's visibly different in overall brightness/tone, so it will respond differently depending on the light direction - the entire surface is slanted, in other words.

It looks like it was saved with an incorrect color profile or something along those lines. Normal maps should never use a color profile and be linear color, not sRGB. If I manually butcher it to ~0.82 gamma with a levels adjustment, it will more or less match the neutral color overall and retain its general shade while rotating the object, but that's a dirty eyeballed hack job. Ideally you'd use normal maps that aren't flawed to begin with.

 

This problem impacts all of my constructions that incorporate normal maps, rather than being limited to this specific wall. White dice in games become discolored when a specific side is exposed. In my opinion, there were issues encountered during the implementation of these features. It would be unfair to interfere with my belongings by rendering all normal maps, which were previously functioning well, incompatible.

Based on your explanation, I have gained some comprehension regarding the underlying truth, although I lack the knowledge on how to rectify my normal maps using GIMP. I tried adjusting the gamma in the settings as much as you suggested, but it consistently results in my walls appearing gray, regardless of their orientation. I like to have my pristine white walls without the full brightness enabled, rather than having it.

Nevertheless, if I am able to retain my white walls, is there a video or website available that provides instructions on creating PBR compatible normal and specular maps using Gimp?