What's up with these normal maps?

[Nutria2016]

I've been trying to understand SL how it uses normal maps. The problem is either the lighting on top and bottom are incorrect, or the lighting on the left and right is incorrect, shown on the pics below.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I've been using the image titled  "Checking Normal Maps as a reference thinking it was the correct way to create normal maps, but still giving me incorrect lighting.

Is SL's advanced lighting module just different from all the others?

Is there a guide to using normal maps for SL correctly?

[Nutria2016]

Here's the normal map for the first image shown. Had to watermark it to avoid breaking TOS.

 

 

[Amethyst Jetaime]

Normal maps add a 3D effect to the texture. Specular maps add the lighting effect.

Darker colors make the texture recede, lighter colors make the texture advance on a nomal map.  The lighter the color on the specular map the more light is reflected.

If you are doing a ceramic tile texture, you want the grout lower than the tile. So that would use darker colors for the grout, while the tile would use lighter.  The higher the contrast the higher the tiles will look compared to the grout 

On a gray scale specular map, you would use black for the grout, since most grout doesn't reflect light, and a dark to medium gray for the tile to give it a bit of reflection,depending on how much you want to the tile to be reflective.   Use a light gray to white to accent the areas where you want the tile to be the most reflective.

[Nutria2016]

I already know about specular maps but thanks for the answer. I'm talking about how the lighting from light sources reflect incorrectly.

[Callum Meriman]

Does seem  like the top and bottom are reversed.

Are you sure sync [ ] is ticked? Or that the scale is not -1.

[Drongle McMahon]

The "swizzle" of the normal map [X+Y-Z+] is wrong for SL. It has to be [X+Y+Z+]. That means the green values are interpreted as the opposite direction. You can correct this by inverting the green channel (because the green value is interpreted as a signed integer vector, it will remain normalized). Here is a cube in SL using your map on the left, and with with inverted green in the middle. At first sight, mirroring in the vertical axis has a similar effect (on the right), but that invertes the pattern of the stones too! For SL maps, the normal map should look as if lighted by cyan from above and by magenta from the right.

You can read more about swizzle here (together with the more subtle but more intractable effects of different tangent basis). The swizzles of various packages are listed there too.

[ChinRey]

---

Drongle McMahon wrote:

The "swizzle" of the normal map [X+Y-Z+] is wrong for SL. It has to be [X+Y+Z+].

---

I suppose you mean [X+Y-Z+] ?

But more important: What you are saying is that SL got the direction of one of the channels wrong? We've had normal maps for more than three years now, am I the only one who have never heard of this issue before? Or was the whole thing just too trivial to be worth mentioning?

[Drongle McMahon]

I suppose you mean [X+Y-Z+] ?

Erm...No. I'm pretty sure I mean normal maps for SL should be  X+Y+Z+, while the one for the stone wall in the OP was X+Y-Z+. I even retested it to make sure. Here is a picture with normal maps baked from a plane with a protruding part sphere to a flat plane in Blender: X+Y+Z+ (Blender default) on the left; X+Y-Z+ on the right (you can change the swizzle in Blender bakes). These are viewed at noon, with the sun directly overhead. So the left one, X+Y+Z+, gives the correct shading, while the other one doesn't. The same maps show the same shading effects in Blender, which is listed in the cited polycount article as being X+Y+Z+.

ETA. I don't think there's really a right or wrong here, is there? Different sofware/shaders use different swizzle, at least according to the polycount article.

[arton Rotaru]

Hey Chin (or is it Rey :matte-motes-smitten:), I guess you have just missread Drongles post. The swizzle of the OPs map is wrong to be used in SL. OpenGL normal maps are x+y+z+. While DirectX normal maps are x+y-z+.

[ChinRey]

---

arton Rotaru wrote:

Hey Chin (or is it Rey :matte-motes-smitten:)

---

Rey usually, but either is equally bad. (Hint to everybody: never choose a joke account name even for a minor just-for-fun alt. Before you know it, it's your main)

 

---

arton Rotaru wrote:

I guess you have just missread Drongles post.

---

Oh, I was sure he wrote [X+Y+Z+] twice but yes, I must have misread. (Unless he edited the post later that is... )

 

---

arton Rotaru wrote:

OpenGL normal maps are x+y+z+. While DirectX normal maps are x+y-z+.

---

So it's a difference between OpenGL and DirectX and not LL's fault then. They really love to make things as difficult as possible, don't they? But at least we have to make sure we know who to blame. Does anybody know what standard Vulkan uses btw?

[arton Rotaru]

---

ChinRey wrote:

Rey usually, but either is equally bad. (Hint to everybody: never choose a joke account name even for a minor just-for-fun alt. Before you know it, it's your main)

---

 K....Rey. :matte-motes-smitten: (That's how it goes. :matte-motes-little-laugh:)

 

---

ChinRey wrote:

So it's a difference between OpenGL and DirectX and not LL's fault then. They really love to make things as difficult as possible, don't they? But at least we have to make sure we know who to blame. Does anybody know what standard Vulkan uses btw?

---

 Yup, it's not their fault this time. However, it would have been cool if they had went with a standard tangent basis like MikkTSpace (Blender, XNormal default), rather than doing something on their own, for what there is no baker out there. So yes, they make things difficult at times. :matte-motes-whistle:

I hope they didn't do it again with Sansar.

[ChinRey]

---

arton Rotaru wrote:

I hope they didn't do it again with Sansar.

---

Oh, I'm sure they had the sense to use HSV rather than RGB values to map the normals there.

[Klytyna]

---

ChinRey wrote:

---

So it's a difference between OpenGL and DirectX and not LL's fault then. They really love to make things as difficult as possible, don't they? But at least we have to make sure we know who to blame. Does anybody know what standard Vulkan uses btw?

---

Vulcans, being logical creatures dont use StupidColor Normal maps at all, they use good old grey scale bump/displacement maps, where dark is lower and light is higher and there is no silly inter-brand confuse the channel directions nonsence.

[arton Rotaru]

[ChinRey]

---

Klytyna wrote:

Vulcans, being logical creatures dont use StupidColor Normal maps at all, they use good old grey scale bump/displacement maps, where dark is lower and light is higher...

---

You mean heightmaps? Ebbe has promised us we'll have those in Sansar. It might be ... interesting to see what shape the ears of the programmers he's hired for Sansar are.

Edit: No, I was wrong, it was displacement maps Ebbe promised we'll have in Sansar.

[Klytyna]

Yeah well... A lot of things have been promised for SL-2 Project Stupid...

 

Most of them are things I will never see, since I have absolutely no interest in forking out hundreds of dollars for vr gear to view 'cutting edge virtual art installations' where the 'artist' gets to chose my avatar, because we wonrt have an individual inventory except for the LL issue FuglyTech noob starter avis.

 

As for the maps, I meant bump/displ;acement maps of the kind that have been used in 3d rendering for over a decade, greyscale images, where typically black is a lowering of the surface at randertime and white is a raising of it (except for Poser 5 onwards where black was no movment and white was full movement in a single direction),

 

Since they dont use color channels, there is no problem of 'handedness' between openngl and directx. Remember stuff like directx 'direct draw surface' or dds files which use those 'not sl friendly' normal maps are in fact an INFERIOR graphics format, dds is a lossy file format designed for speed over quality, and normal maps were popular with that because you could run your diffuse texture map  through a desaturation process to get a greyscale image then stuff that through a 'normalising' filter in photoshop, to make inferior bumpiness maps very quickly and cheaply, no need to hand edit stuff on a per image basis.

[ChinRey]

---

Klytyna wrote:

As for the maps, I meant bump/displ;acement maps of the kind that have been used in 3d rendering for over a decade, greyscale images, where typically black is a lowering of the surface at randertime and white is a raising of it.

---

Yes, that's probably heightmaps.

Basic and very simplified terminology:

• A normal map creates the illusion of 3D by altering the directions of the normals across the surface. It is always color coded.
• A displacement map alters the actual geometry of the surface, raising some parts, lowering others.
• A heightmap says what effect is required, not how to achieve it. The client software generates either a normal map or a displacement map based on it.
• The term "Bump map" is a bit tricky to define since it can have different meanings in different contexts. It can be more or less synonymous to heightmap but it can also be a generic term for all the three kinds of maps.
• Bumpiness is an SL only term for a set of normal maps introduced long before we had a general normal map function. Two of them, Brightness and Darkness are generated by the viewer, using the texture as a heightmap, the others are perfectly regular color coded normal maps. The only things special about them are that they are poorly chosen and poorly implemented. (You can even look up the UUIDs of those maps and use a script to add them as "modern" normal maps although it's hard to see any reason why anybody would want to do so )

Edit: Almost forgot:

• Parallax map: A kind of normal map on steroids, combining normal manipulations with some degree of displacement.

[Nutria2016]

Thank you all for the answers. I understand normal maps better now. At first I thought normal maps worked the same for every game engine but looks like I was wrong. I'm now able to create normal maps the way I intended them to look.