strange bumpmap behaviour in 2.53

when i assign an image texture to an object in 2.53 r31315 and enable the normal influence in the texture options the result is far from what im used to.
the outcome is this:

whereas it should look like this:

rendered in 2.49

am i missing a switch or is it a bug? please help

I do not use anything newer than version 2.49 so I may be very wrong about this. You are using the normal function, but you don’t have a normal map. Maybe there’s a separate slider for bump maps?

(normal maps are those colorful textures like this:
Bump maps are greyscale)

i looked all around and there is no seperate slider for bump maps, i found a way to get it to work however, turning on AA gives a very nice result:

trouble is that i hardly ever use aa and don’t really want to start because of that.
i hope that there is another way without aa.

That’s … odd. I can reproduce something similar by starting with a blend file (and materials) created in 2.49 and opened in 2.53, but not consistently.

Try making a new wood material completely in 2.53. There are changes to how normal mapping is calculated in 2.5+, and there seems to be some code for pre-2.5 material compatibility that can do some unexpected things. Alternately, make the material in 2.49 and don’t try to edit the material in 2.53

(I do usually keep separate normal map images like radialronnie mentions, but using the same wood image for color and normal can get acceptable results as well)

normally in 2.53 if you load up from 2.49 it will use the old algo for Nor

but if you make one in 2.5 it will use the new algo for Bump map!

unless there was a change in latest built !

but your right the light scene is not like in 2.49
so it will affecdt the resulting render !

happy 2.5

the example scene from 2.53 in the first post was created in 2.53
The problem here seems to be the new algorythm in 2.5 it seems to heayily rely on aa, which the wasn’t neccesary in 2.49.

happy 2.5

lets hope that they fix it or someone finds a workaround for that issue, beeing forced to use AA just to use bumpmaps makes me far from happy.

try to report it as a bug in 2,53

may be it is a bug !


IMHO the problem lies within the mipmaps - if you use mipmaps, then you don’t get so much distortion when fine differences in nor is farther away from the camera. This shows up as nasty speckles like so many crawling ants. However, you lose a lot of nor effect if mipmaps are on and the texture is aligned any direction other than along the camera plane. WHat may help is to use a mask mapped to the camera that smudges out nor textures further away from the camera.

thanks for your posts
sadly changing any of the settings like mip map options camera position and rgb to intensity don’t change anything the only thing that helps is aa.
ive uploaded a test .blend here:

have a look at it, maybe someone can get it to work as it should without aa.

i’ve just found a workaround.
bake the normals to a new texture with AA enabeled and then use that normal map to render, tangent space normal maps seem to work without AA

OK I’ve been working on this - infact I was making a vid on it when I discovered another bug! Anyway, with 2.5 the NOR value may at times need to be much higher than with 2.49, however, for the most part, the most interesting feature you can adjust is the Texture normal mipmap filter size! THis is new AND you can set the normal map to camera - which is what we really want. Now you can adjust just how rough/ smooth the normal effect is to suit your needs! (BTW for this I have NOR at only 0.8)
The new bug - you can animate the filter size just fine however when you do, no f-curves or keys are visible in the curve editor window. I’ll upload the vid so you can see what I’m talking about, There is no AO here just normal so it renders quick. To show off the normal effect there is a light set to specular only at the back of the half cube.

well, there is defenitly something wrong here, trouble is that i don’t have enough undertanding of the inner workings to say what it is exactly and how to fix it.

i did some more fiddling and found that there are definetly two different ways blender handles textures to use as normal maps.
there is the one, wich apparently only gives good results with aa, used when the texture is directly applied to the material.

and the other wich is used when you use texture nodes to input the normals from the image texture and feed them into the material.
this method gives a rather standard rgb normal map but the effect is far too extreme and i havn’t found a way to decrease the strenght yet.
heres a screen of what i mean:

the top section shows the normals from the texture beeing fed into the material and the lower sections shows the normals beeing fed into the output to show the normal map.

dont forget a normal map is sort of a bluish image coded in RGB for the normal

so if you show that it wont be decoded to calculate the normal!

so your are comparing apples with oranges here

it’s not the same thing!


Interesting, I wonder what values come out of a normal socket in the compositor, certainly seems to be different than texture NOR. Since the socket is blue, I think it is a vector, but as RickyBlender pointed out, I have no idea how many dimensions, its likely an array. We all sort of assume that greyscale normal map is the same as local Z adding r, g, b, I don’t know if that is correct. Did you ever try to put a color ramp between the texture normal socket and the material normal input socket? May be able to use that to multiply it to control the effect. Don’t know.

Anyway, It will be interesting to fiddle with filter size settings, this should minimize the speckle effect you see when moving/ animating by a nor’d material.

as i remember it’s a vector RGB which represent the Normal for each point in a picture

hope it helps

happy 2.5

i tried a lot of ways to decrease the strenght and havn’t found a way yet, color ramps, saturation adjustments and different sorts of color blend methods dont work, vector and rgb curves can decrease the strenght but they also cause specularities and reflections to be dislocated. The results are “interesting” but not practical.

another strange thing is that procedural textures work just fine when used as normal map, there is no flickering and no aa is required to get good results.

have you tried with texture node instead of the mat node
should work better
i’v seen it in the brick model by blenderguru if i remember well


more strangeness ahead
i tried the texture nodes and again found that there must be two different ways blender handles images when using them as bumpmap.
when you set the texture to be an image and enable nor its full of artifacts and only gives good results with AA on (top section of screenshot)
when texture nodes are used to input the image into the texture there are no artifacts when using the nor slider (bottom section of screenshot)

can you show the node set up !

i don’t see the Nodes in your pic fro normal just amage going to the output

can you load up the file
what hardware are you uisng and OS ?


i don’t see the Nodes in your pic fro normal just amage going to the output

exactly, there are no nodes for the normal, plugging the image to the output and enabeling the nor influence is enough to get the bumpmap effect.
have a look at the .blend and try for yourself, there are two textures on the material,
the first one is just the image texture without any nodes, the bump effect is noisy and only looks good with aa enabled.
the second one uses the simple node setup from the image above and the bumps effect is very nice, even without aa.

Well all because of you MaGoo, I’m experimenting with the mipmaps again! I’m still working on the render and I’m pretty sure that I’ve figured out a few things:
First: NOR currently seems to be backwards, eg white is down and black is up
Second: NOR seems to only work right with raytracing shadows
Third: the method used for mipmap NOR projection and the mipmap filter value are very powerful but, by the same token, very touchy.

I am intrigued by your experimentation, please keep it up, I’ll try to keep posting here on mipmaps for nor too, even though its a bit of a tangent.