# Oddity With Bump ?

• I'm half-asleep at the moment (and likely half-asleep when I was doing all this too). but yes.

The radius of my hemisphere's 0.5, the distance in the UV plane to any point (u,v) on or within the hemisphere is r = sqrt( (u-0.5)^2 + (v-0.5)^2 ), and I'm trying to calculate the height of the hemisphere above that point in the UV plane using h = sqrt ( (hemisphereRadius)^2 - d^2 )

• I just discovered that in SuperFly, I get a match when the blue color is from 1 to .5, not .5 to 0, not 1 to 0.

So apparently SuperFly believes that a tangent space normal is fully capable of pointing in any direction, even having a negative Z. This is a surprise.

• The redundant -0.5 and +0.5 math nodes... well, like you said, wonky !

And bump and normal map versions rendering differently - so it's not just my imagination then.

• I have to go - I'll be back (and hopefully awake) later

• I opened up Poser Pro 2014 just to confirm my findings because they are strange.

Here are my findings:

• As with red (x) and green (y), the blue (z) value is scaled identically. So the blue value for forward-facing/outward normals always has a positive z and therefore the blue value is always at least .5. A blue value of 0 indicates a reversed normal pointing straight into the surface.

• FireFly does not use the blue channel value from the normal map AT ALL. It calculates it on its own using exactly the equation you were trying to build with nodes. You don't need to plug anything into the blue channel to use a constructed normal map -- all that matters is that the red and green are set correctly.

• FireFly appears to be calculating the actual normal incorrectly. I have always suspected this as every time I constructed a normal map image from a bump map image, the FireFly render with the normal map NEVER matched that of the bump map from which it was derived. It may be that FireFly is using the wrong mapping for blue value. As a consequence, it is impossible to get FireFly to render the correct normals using a normal map.

As I said, I am able to exactly reproduce results in SuperFly with correctly derived normals based on a height map using the hemisphere construction.

• Note that I will probably get lots of users objecting that they've used normal maps just fine for years.

That is easily explained without contradiction of my findings.

Here is the explanation:

You never cared that it was wrong because you only did modest normal map deviations. The error I see in FireFly is only severe for normals pointing way off center. For normals that are only slightly off center, everything is directionally correct and only going to be noticed if you really pay attention to every little detail of a reference image from a renderer that is built correctly.

• @bagginsbill

I used to be a "Displacement man". LOL.

Never cared for Normal maps as they are so end user unfriendly.
(They were the first ones to go under the "Delete hammer" anyway, and recently I simply stopped installing them completely.)

These PP11 days? => I converted to a "Bump Guy". LOL.

End used friendly and it works everywhere.

• @vilters said in Oddity With Bump ?:

@bagginsbill

I used to be a "Displacement man". LOL.

Never cared for Normal maps as they are so end user unfriendly.
(They were the first ones to go under the "Delete hammer" anyway, and recently I simply stopped installing them completely.)

These PP11 days? => I converted to a "Bump Guy". LOL.

End used friendly and it works everywhere.

I agree. I have always found neat things I can do with bump that just isn't workable with normals.

• I'm doing lighting testing with geometry (a real sphere), a bump mapped square, and a normal mapped square.

The light is an infinite light, elevated 45 degrees. I'm rendering with various yRotate values.

FireFly renders in this post.

Here is yRotate 0 (light is behind the camera) -- clearly the Normal map knows which direction is the sun, but the shading is just wrong.

yRotate 30 -- still wrong on the normal map

yRotate 60

yRotate 90 -- this is the ONLY case where the normal map behaves correctly - so DO NOT JUST TEST LIKE THIS or you'll think there is no problem.

yRotate 120 -- light is now behind the props -- bump showing a little difficulty at the bottom, but the normal is just stupid

yRotate 180 -- the normal map has given up completely - total junk

• Here are identical setups but rendered with SuperFly. Here, the normal is generated the same in the shader, but the render is very much different. Clearly FireFly is broken.

But! I do see some error in SuperFly handling the SHADOW side with the indirect light. It turns out FireFly did this better than we see here. Peculiar.

Here we are at yRotate = 90 and SuperFly is now making a mistake on the lit side as well -- the same mistake with bump or normal. It's not lit as bright as it should be. Sigh...

And at yRotate = 120, SuperFly has completely lost its marbles. My God -- is it so hard to implement a damn renderer? I know real-time GAMES that do better than this. Jeez.

I almost didn't bother with the 180 degree case, but I'm here already so blah.

I'm seriously disappointed with BOTH renderers.

• Moral of the story

Do not waste your time with normals in either FF or SF - just, seriously, don't waste your time.

If you have to use something, use bump, and recognize that SF is actually not as good at this as FF is. On top of that insult, SF is slower. But if you actually want a realistic picture, then use real geometry.

• @bagginsbill said in Oddity With Bump ?:

Moral of the story
Do not waste your time with normals in either FF or SF - just, seriously, don't waste your time.
If you have to use something, use bump, and recognize that SF is actually not as good at this as FF is. On top of that insult, SF is slower. But if you actually want a realistic picture, then use real geometry.

A beautiful way to end this thread ! Thank you.