# Oddity With Bump ?

• This was only intended to be a quick and easy comparison of renders of a hemisphere using bump and normal maps :oS I seem to have:

1. Odd behaviour of bump when object/scale is very small
2. Normal map not rendering as expected

I think I'll just pretend I never started this thread...

• I just started analyzing what you're doing vs. what you should be doing. Care to stay?

• My first difficulty with your first post is you calculate radius from 0 to .5 whereas I always calculate it from 0 to 1.

The difference results in rather severe contortions to renormalize on your part where I don't have to. But that doesn't mean your OP is wrong. Just that it's hard to reason about it.

• Rather than be influenced/confused by your shader, I started my own. Here's mine.

I am using a 12 inch square of my own construction, so I'm creating a hemisphere of radius 6 inches.

My calculation starts with 2 * U - 1 and 2 * V - 1, resulting in -1 to 1 as my x,y coordinates. A simple Sqrt(x^2 + y^2) [not shown] gives me distance (d) from center on the 2D circle. For the bump height I need h = 6 inch * Sqrt(1 - d^2) which is what you see calculated here into the PoserSurface. For the CyclesSurface I use the Bump node which strictly is meters. Regardless of which root I render, the image is the same.

Note: My sun is up 80 degrees, so 10 degrees off the vertical.

• I want to point out that in the Cycles root above, the shader IS USING A NORMAL MAP.

I know you don't see a normal map there, but there is one. It's the output of the Bump node.

However, it is not a tangent space normal map - it's the actual normal!!!!

I believe you're trying to figure out how to make a tangent space normal map, right? The kind that you plug in to the PoserSurface Gradient_Bump input.

• I'm still reading the first post and I'm very confused by the shader nodes.

You asked if I can spot the mistake? Well I can't because I have no idea what you're doing there.

What formula are you implementing, first of all? If the formula is wrong, then the nodes don't matter.

• I tend to confuse myself a lot ! Just took a break - reading your posts now.

• So I'm seeing the User_Defined assembly appears to be trying to calculate the normal vector from its xyz triple components.
But - it's wonky.

For the x component you feed U - .5 + .5 which is just U. So your x component varies from 0 to 1 and that seems about right but it's a wonky way to do it.

For the y component similarly you feed V - .5 + .5 which is just V. Same comment.

Now the z component (blue) seems wrong to me. It appears to be assembled as follows:

x = U-.5 (varies from -.5 to .5)
y = V-.5 (varies from -.5 to .5)

d^2 = x^2 + y^2 (Math_Functions_38, varies from 0 to .25, center to edge)

Abs(.25 - d^2) (Math_Functions_20, varies from .25 to 0, center to edge)

Sqrt(Abs(.25 - d^2)) (Math_Functions_11, varies from .5 to 0, center to edge)

I believe this should not be .5 to 0, but rather 1 to 0, like my height node, my Math_Functions_7.

• Grrrrr. Even when I use my height map calculation (spherical center 1, edge 0) I still don't get a match between the bump map and the normal map. I get a mismatch both in FF and SF but the mismatch is different for each.

• 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.