# How to reproduce the Bump Node?

Is it possible to reproduce this node procedurally?

Is it something very complicated?

I do a little edit of the question to be more specific. I'm trying to figure out how to reproduce this node while avoiding the use of this node. I don't know if it's possible, but in blender inside nodes almost everything appears possible

A bump node is not possible to reproduce via component nodes. The reason for this is that a bump node doesn't just lookup the bump value of the sample being evaluated, but the bump values of adjacent samples, in order to generate a slope for the sample, which then gets translated into rotation of the normal. That hard part is, how far should those adjacent lookups be? You can't look by just shifting 1 UV pixel, because that could be a huge distance or a tiny distance, depending on distance, FOV, and on UV scale. (Not to mention filtering.) You need to figure out how far to look, and doing that requires something like screen space derivatives (which are probably used for Eevee, but Cycles probably does something different) to see how much UV changes with respect to world position.

Unfortunately, Blender does not expose screen space derivatives to its nodes. (Which is honestly too bad, because there are other cool things you can do with screen space derivatives as well.)

However, even though these can't be recreated using only Blender's nodes, there exist plenty of environments where you can play with exactly how bump mapping works. If you're interested in this kind of stuff, Unity is a great place to learn about (rasterizer) rendering, and there are plenty of public shaders available to study.

Normal mapping is a little bit different, because it doesn't require any screen space derivatives (except to determine the UV tangent, if you aren't providing that as vertex data, but Blender kindly provides you a tangent node, so you don't have to worry about that.) The basic way that it works is by rotating the normal toward or away from the tangent on the basis of + or - red, and toward or away from the binormal (a unit vector perpendicular to both the tangent and the "raw" normal) on the basis of + or - green. (What is minus green? The colors of a normal map are actually remapped unit vectors, which exist in the -1 to 1 space for all channels, remapped into the 0 to 1 space so they'll fit in typical image formats. That's why the base color of a tangent space normal map is that lilac: 0.5,0.5 red green actually maps to 0,0 x,y, and the 1.0 blue maps to 1.0 z.)

If you had a bake of UV stretch, you could do a bump procedurally, with other nodes, assuming your mesh didn't deform, which would change the UV stretch. However, the whole reason why we use tangent space normal maps is to support deforming meshes. If you were working with a mesh that didn't deform, you may as well use an object space normal map.

Object space normal maps are extremely simple-- you can just remap these to -1,1 space and vector transform from object to world.

Should be said, there's nothing to gain from recreating any of these in nodes, except understanding, and that understanding could be gained much more easily by reading shaders that implement bump mapping.

• Well... I have made a convolution node group that takes a reasonable shot at generating normals from procedural heights via Sobel.. but as you can imagine, it's quite big, and it doesn't cut in at the same time in the rendering pipeline w/respect to displacement, as the Bump node does? I would love to know more about the order of events, any clues about that would be very welcome.. I will post my own question when I can put it tidily.. – Robin Betts Oct 19 '20 at 21:32
• @Robin Betts A bump node is post-displacement, as would be creation of any arbitrary normal arrived at from geometry/normal via component nodes emulating a bump node. The issue with using convolution to determine that sample is, like I said, figuring out how far away your extra samples should be from your first sample, and figuring that out properly requires you to know delta UV/delta position-- something Blender's nodes are incapable of determining. – Nathan Oct 19 '20 at 21:38
• Yup, my dx and dy are arbitrary,user-selected, in whatever2D space has been set up by previous nodes. – Robin Betts Oct 19 '20 at 21:52
• PS I don't understand why in 'Geometry > Parametric' Blender gives us normalised barycentric U and V in a rendered triangle, without also giving us OSL's dPdu and dPdv?? Surely they can't be that hard to expose? – Robin Betts Oct 19 '20 at 22:00
• @Robin Betts I agree, and have made a Right Click Select suggestion that they be exposed. But I don't expect it to get much traction because of how RCS works. And it should be said, I'm not totally sure how these work in a raytracer like Cycles, although the existence of Shader to RGB, Specular BSDF suggests that there is at least a little bit of interest in support for Eevee-only features. – Nathan Oct 19 '20 at 22:28