# DS4.5 Shader Mixer - What's happening with the normals here? PROBLEM UNDERSTOOD, STILL TRYING TO SOL

Posts: 724
edited August 2013

PROBLEM UNDERSTOOD: The output of a Normal Map brick is NOT a tangent-space normal (which is what I thought). It's the normal in camera-space after it's been applied to the object. And by the way, camera space uses a left-handed axis system with the camera's line of sight being the positive Z axis, so normals for 'forward'-facing faces will have negative values.
STILL TRYING TO SOLVE!

I've run into a curious problem while trying to combine normal maps with DS4.5 Shader Mixer. I've managed to reduce the problem to something (hopefully) quite straightforward. I'll start with the bit that works fine.

The four brick network shown here simply takes a normal map, splits it into it's components and recombines them.

I'd expect this to work, and it does.

Post edited by 3dcheapskate on

• Posts: 724
edited October 2012

Since a normal is just a unit vector, it should be easy to calculate the third component (Z, blue) from the other two (X, red and Y, green) using simple trigonometry, B = SQRT(1-((R*R)+(G*G)))
(No, there's not really any point in doing this, but it's just the simplest way I found to explain the problem)

That's what this next network does. (The three bricks in the bottom right are simply to verify that the calculated Z(blue) value matches the Z (blue) output of the splitter brick - it does)

I would expect this network to work too, but it doesn't!

(Edit: discovered an even simpler demonstration of the problem - see the fifth post (#4) for the network I used)

Post edited by 3dcheapskate on
• Posts: 724
edited October 2012

Here's the results when you apply the two networks to a sphere primitive (I also tried applying plugging the end result into the Diffuse Color input of a Surface brick, and noticed the difference there too - I include those renders as they may provide a clue).

The renders on the left are from the first network and are as expected.

The renders on the right are from the second network, and I can't understand why they're so different.

Post edited by 3dcheapskate on
• Posts: 724
edited December 1969

I've got to the banging-head-against-the-wall stage with this one.
An explanation as to why on earth the second network behaves so differently, even though the inputs to the final Point brick are to all intents and purposes the same, would be greatly appreciated.

More background in my Simple Material Mixing With DS4.5 Shader Mixer thread.

• Posts: 724
edited November 2012

I've just discovered an even simpler demonstration of the problem - take the 'Z Component' output of the 'XYZ Components' brick, multiply it by itself, take the square root (so you should end up with the same value as the 'Z Component' that you started with) and plug that into the 'Z Value' input of the point brick.

That should definitely work, shouldn't it?

It doesn't!

I get the same effect as the network in the second post (i.e. renders like the two images on the right in the third post)

To me this makes it clear that it's not faulty maths that's causing the problem!

Post edited by 3dcheapskate on
• Posts: 724
edited November 2012

SOLVED: The output of a Normal Map brick is NOT a tangent-space normal (which is what I thought). It’s the normal in camera-space after it’s been applied to the object.
And by the way, camera space uses a left-handed axis system with the camera’s line of sight being the positive Z axis, so normals for 'forward'-facing faces will have negative values.

(Addendum: thanks to millighost over in this Renderosity forum thread for the enlightenment)

Post edited by 3dcheapskate on
• Posts: 784
edited December 1969

SOLVED: The output of a Normal Map brick is NOT a tangent-space normal (which is what I thought). It’s the normal in camera-space after it’s been applied to the object.
And by the way, camera space uses a left-handed axis system with the camera’s line of sight being the positive Z axis, so normals for 'forward'-facing faces will have negative values.

Thanks. I didn't understand why I obtain results with negative normal and not with positive. I didn't think about changing axis when space is changed.

• Posts: 7,272
edited December 1969

SOLVED: The output of a Normal Map brick is NOT a tangent-space normal (which is what I thought). It’s the normal in camera-space after it’s been applied to the object.
And by the way, camera space uses a left-handed axis system with the camera’s line of sight being the positive Z axis, so normals for 'forward'-facing faces will have negative values.

A lot simpler explanation than what I was working on when I lost power for 4 days...

• Posts: 5,307
edited December 1969

Is there any hope of making a shader brick that creates a normal map for something like my Bruno skin for V4/Genesis/Genesis 02 Female??

• Posts: 724
edited December 1969

There's always hope!

Is the Bruno texture in question purely shader-based or does it use a texture/bump/displacement map image?

If you're creating bump/displacement (procedurally or from an image) couldn't you just use the Normal output from a 'DS Default Displacement' brick?

If it's image-based then you could create a separate normal map in GIMP, etc from your bump/displacement image

Maybe I'm not quite understanding the question...

• Posts: 1,375
edited August 2013

RAMWolff said:
Is there any hope of making a shader brick that creates a normal map for something like my Bruno skin for V4/Genesis/Genesis 02 Female??

I may be tracking something that applies the Displacement Map as a Normal Map....

[EDIT: No. False Alarm. I still know VERY little about Normal Mapping, but I did get some progress toward aligning the Normal-Map with the UV instead of with the camera.]

Post edited by Eustace Scrubb on
• Posts: 724
edited August 2013

Go on... do tell! Getting the normals in UV space rather than camera space was THE big problem I had...

Post edited by 3dcheapskate on
• Posts: 1,375
edited August 2013

Simple: Plug the Normal Map and an NTransform brick into a Binary Functional set to Multiply, and set the NTransform at [From: current To: object] and plug it in wherever you need to.

Post edited by Eustace Scrubb on
• Posts: 724
edited December 1969

Simple's good! So the NTransform brick is the key - hidden in plain sight! (that's often my blind spot ;o)
It's such a long time since I was playing with normals that I've forgotten most of it, but it sounds like something along these lines is what I was after. Maybe time to dust off this project and take another look...
Thanks!

• Posts: 1,375
edited August 2013

I'm sorry for the error in my last post: it should have read "From Current to Object" for the NTransform brick. The image is right. Post edited to match.

Post edited by Eustace Scrubb on