I ran into this conundrum while trying to combine two normal maps using  DAZ Studio 4.5's Shader Mixer. For a long time I thought the problem was in my maths, so I decided to start again from scratch, putting the maths in one step at a time. I was really surprised when the very first bit of maths I tried caused the same problem!

The attached image shows a very simple network at the top (works fine), and a similar one at the bottom (doesn't work - object renders completely black).

The only difference is that the top network plugs Z Component directly into Z Value, whereas the bottom plugs a calculated value into Z Value, the calculated value being √(Z Component*Z Component) , which should equal Z Component, same as the first network (or possibly -Z Component, I've already checked and that's not the problem here)

I've asked this question in various forms over on various DAZ forums, but nobody seems to have the answer.

Anybody over here have any ideas?

One obvious point = sqrt(z*z) is always positive, while the raw z may have been positive or negative. I would have thought positive z would be facing the viewer, but if not then that would guarantee that the normal was facing into the volume and so would be dark.

A negative Z value would seem to be the obvious culprit, but I'd already checked that. However, it's always worth double checking, so I tried simply changing the sign of the Z Component output before plugging it into the Z Value input.

Network snippet and render attached.

Judging from that I don't think it's just a wrong sign.

It appears that I spoke too soon... My next one (see post below) worked!)

This one works!

So it does appear to be a sign issue. Thanks Richard!

But I'm now even more puzzled - why did the original faulty network in the first post render completely black, and not just mostly black like the one a few posts above this?

Quote - This one works!

So it does appear to be a sign issue. Thanks Richard!

But I'm now even more puzzled - why did the original faulty network in the first post render completely black, and not just mostly black like the one a few posts above this?

When rendering your scene, 3delight (DS's renderer) converts all your geometry to camera space. The camera space's origin is where your camera is located in the 3d scene. It has x pointing right, y pointing up, and z pointing away from the camera (which, btw is a left-handed coordinate system). As a result, faces that are visible by the camera have their normals point in the general direction of the camera, and because those faces are in front of the camera they point in the direction of the negative z-axis, hence they have usually a negative z value.

You have to be careful when manipulating normals in your shader in the way you did, like negation of a single component, because after that in general the resulting vector will not be a normal anymore; e.g. negating the z-component of a vector does not make it point into the opposite direction, for that you would have to negate all its components - so negating one component only does not necessarily make your render totally black.

Note that the normals in the render depend on the s/t-parameters of the object (i.e. the UV-map). The little spheres you see in the preview windows of the shader mixer are of course mapped differently than the object you want to render, so do not rely on them to determine if everything works correctly.

Thanks for the reply - lots to think about there. Going through your reply paragragh at a time...

Quote - When rendering your scene, 3delight (DS's renderer) converts all your geometry to camera space. The camera space's origin is where your camera is located in the 3d scene. It has x pointing right, y pointing up, and z pointing away from the camera (which, btw is a left-handed coordinate system). As a result, faces that are visible by the camera have their normals point in the general direction of the camera, and because those faces are in front of the camera they point in the direction of the negative z-axis, hence they have usually a negative z value.

So DS Camera space uses a LH axis set while DS world space uses a RH axis set - is that correct? The mists are beginning to clear! I'll expand on this in the next post...

Quote - You have to be careful when manipulating normals in your shader in the way you did, like negation of a single component, because after that in general the resulting vector will not be a normal anymore; e.g. negating the z-component of a vector does not make it point into the opposite direction, for that you would have to negate all its components - so negating one component only does not necessarily make your render totally black.

I've been assuming that any old unit vector is interchangeable with a normal. Changing the sign of 1,2, or all 3 of the components of a unit vector will still give you a unit vector, and thus I assumed a valid normal - is this incorrect? (I realise that you'd need to change the signs of all 3 components to 'flip' the normal)

Quote - Note that the normals in the render depend on the s/t-parameters of the object (i.e. the UV-map). The little spheres you see in the preview windows of the shader mixer are of course mapped differently than the object you want to render, so do not rely on them to determine if everything works correctly.

For my tests I've been loading a single sphere primitive into the scene. I'd assumed that the brick preview renders were using a similar, if not identical, object and that the mapping would be the same or similar. Test renders that weren't totally black seemed to indicate that the mapping was similar enough.

Hmmm... I said the mists were beginning to clear, but they've closed in again! In very simple terms, when you're rendering a given pixel the renderer will convert the normal of the point on the appropriate face to camera-space coordinates, correct?

So it makes sense that somewhere the blue channel/Z component of the normal map gets its sign changed to fit the camera-space left-handed system.

But where? Specifically, where in the Shader Mixer network? I still can't answer this given the results of the four simple networks already posted in this thread, i.e.:

Zv = Zc ...renders correctly

Zv = √(Zc*Zc) … renders completely black

Zv = -Zc ...renders mostly black

Zv = -√(Zc*Zc) … renders correctly

(Zv is the input to the Point brick, and Zc the ouput of the XYZ Components brick)

Hmmm...

Zv = ABS(Zc) ...renders completely black!

Not what I was expecting, but it explains just about everything! It looks like the Z Component output of my XYZ Components brick is already in camera-space, with forward-facing normals having negative values. Time to try my combining normals network again.

Thanks Richard and millighost!

(In my defence,  I was absolutely convinced that the brick preview renders for float values showed black for negative values!)

Yet more hmmmms....

I'd assumed that if I had a 'flat' Normal Map (i.e. solid colour 128,128,255) plugged into my XYZ Components brick, then the X,Y,Z Component outputs would be the same for every point on my sphere primitive (i.e. I'd assumed I was working in the same UVW space as the normals map).

It's looking increasingly likely that I've been barking up the wrong tree!*  I'm getting the feeling that they're actually the values of the normals, after being applied to the sphere primitive, and after being transformed to camera-space - which sort-of makes more sense...

Can anybody confirm or refute this?

*'a tree in the wrong forest' might be more approriate!

 

> Quote - .... So DS Camera space uses a LH axis set while DS world space uses a RH axis set - is that correct? The mists are beginning to clear! I'll expand on this in the next post...

Correct. Technically DS mirrors the scene along the camera axis before rendering. And because the camera is at the origin the scene gets mirrored along the z-axis.

Quote - I've been assuming that any old unit vector is interchangeable with a normal. Changing the sign of 1,2, or all 3 of the components of a unit vector will still give you a unit vector, and thus I assumed a valid normal - is this incorrect? (I realise that you'd need to change the signs of all 3 components to 'flip' the normal)

Of course a normal is nothing else than a unit vector. The only thing that makes it different from any other unit vector is the fact that it is perpendicular to a surface. The only thing to remember is that when using a normal to display e.g. dents is that when the normal is tilted right for one pixel, it should be tilted left for another pixel (on the other side of the dent). That property can easily be destroyed when manipulating normals. This is not a hard rule, however, it just might look weird, and for experimentation everything is allowed, of course.

Quote - For my tests I've been loading a single sphere primitive into the scene. I'd assumed that the brick preview renders were using a similar, if not identical, object and that the mapping would be the same or similar. Test renders that weren't totally black seemed to indicate that the mapping was similar enough.

In most cases it is similar enough, but not the same: in the illustration i connected the s-variable straight to the color of the output. As you can see, in the render the increasing s wraps around the sphere counterclockwise, in the preview-sphere it wraps around clockwise. Often not a problem, but should be kept in mind when dealing with shaders that depend on the direction of the s-parameter (like normal maps do).

Quote - Zv = Zc ...renders correctly

Zv = √(Zc*Zc) … renders completely black

Zv = -Zc ...renders mostly black

Zv = -√(Zc*Zc) … renders correctly

(Zv is the input to the Point brick, and Zc the ouput of the XYZ Components brick)

Only the first one renders correctly. The other three statements are not always true (but they are probably in your case); the normals might point in any direction, away from or towards the camera. But of course the shader does not really care in which direction the camera is located (at least the diffuse shader does not). The shaders care where the light sources are located relative to the normal. When rendering without a light source, the renderer creates a default light at the same location where the camera is, so it might look like a normal with a positive z value resulting in a black pixel, but this is actually only the case for the default light. If you have not already done, add a distant light to your scene and things will render very different from different angles, most of them neither correct nor black.

Quote - ....

Yet more hmmmms....

I'd assumed that if I had a 'flat' Normal Map (i.e. solid colour 128,128,255) plugged into my XYZ Components brick, then the X,Y,Z Component outputs would be the same for every point on my sphere primitive (i.e. I'd assumed I was working in the same UVW space as the normals map).

The kind of normal map you use is a "tangent-space" normal map. As the name says, it does not use the same coordinate system as all the other coordinates of the scene use but the tangent space. The tangent space is different for every point on the surface, and there is no transform brick to convert from or to tangent space. That transformation happens inside the normal-map brick, which does a lot more than just a simple image-map. The normal-map brick outputs camera space normals, and because the tangent space is different for every surface point the result is different, even if the map is the same for two points.

Quote - It's looking increasingly likely that I've been barking up the wrong tree!*  I'm getting the feeling that they're actually the values of the normals, after being applied to the sphere primitive, and after being transformed to camera-space - which sort-of makes more sense... Can anybody confirm or refute this?

confirmed

Quote - *'a tree in the wrong forest' might be more approriate!

Thanks again millighost. To summarise my mistakes:

1. Camera-space is a left-handed axis system (not a right-handed system)

2. The output of a Normal Map brick is the normal in camera-space (not in tangent-space)

So now I can get back to the main task - the approach I was using for combining two normal maps (in tangent-space) wass simply adding the red channels, adding the green channels, and calculating the blue channel as the value that combined with the calculated red and green values would result in a unit vector (i.e.  Zc=√(1-((Xb+Xo)²+(Yb+Yo)²))  where the subscripts are b=base material, o=overlay material, c=combined). Of course, I'll have to check for the √(-ve) case, but I first need to see if I can get the basics working!

I should be able to adapt this for camera-space - the maths will be more complex (maybe too complex for me), but I'll give it a shot.