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

3dcheapskate3dcheapskate Posts: 759

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

Comments

  • 3dcheapskate3dcheapskate Posts: 759
    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)

    NormalsFAIL.jpg
    1846 x 869 - 343K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 759
    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.

    WhatsUp.png
    512 x 512 - 156K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 759
    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.

  • 3dcheapskate3dcheapskate Posts: 759
    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!

    SimplestFail.jpg
    1381 x 728 - 112K
    Post edited by 3dcheapskate on
  • 3dcheapskate3dcheapskate Posts: 759
    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
  • GiGi_7GiGi_7 Posts: 825
    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.

  • mjc1016mjc1016 Posts: 7,841
    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...

  • RAMWolffRAMWolff Posts: 5,578
    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??

  • 3dcheapskate3dcheapskate Posts: 759
    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...

  • Eustace ScrubbEustace Scrubb Posts: 1,395
    edited August 2013

    Ooh, look! ShaderMixer puzzle!

    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
  • 3dcheapskate3dcheapskate Posts: 759
    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
  • Eustace ScrubbEustace Scrubb Posts: 1,395
    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.

    UV-Mapped_Normals.jpg
    1262 x 495 - 405K
    Post edited by Eustace Scrubb on
  • 3dcheapskate3dcheapskate Posts: 759
    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!

  • Eustace ScrubbEustace Scrubb Posts: 1,395
    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
Sign In or Register to comment.
Rocket Fuel