Bump Node

[VelocityRa]

Equivalent of the Blender Bump Node.

Apart from the obvious usage when the particular workflow requires it, they are also very handy for creating fake normal mapping when only diffuse/color textures are available (by just using the color intensity, increasing contrast and such). That's my use case as well.

[Psi25]

This seems possible with the current Malt nodes but I don't know the math to get such thing working. Alternatively it would instead be nice to have this as a node addition for Malt.

[aVersionOfReality]

I have an Eevee equivalent one finished and am working on some higher quality options. I suppose we can get the Eevee version in for now. I'll try to get to it.

[aVersionOfReality]

Its the same thing we talked about awhile back in the Discord channel. I have several versions:

1: Uses dFdx/y on the height map for the derivatives, and also on position for the Tangent/Bitangent
2: Uses UV offset with an image texture height map for derivs, and precomputed Tangent.
3: Uses dFdx/y on the height map for the derivs, and uses precomputed Tangent (not fully working, but I think I know how to fix it.)

So none of these are quite right.
#1 is the same as Eevee, but eevee's bump is poor quality when used with image textures
#2 is good quality but only works with image textures.
#3 will be great for non-images if I can get it working.

So best quality will be 2 or 3 depending on if image tex or not.

Or I assume we can use a custom pipeline and offset the previous part of the pipeline.

[pragma37]

Doesn't 3 cause the bump to be "blocky"?

My assumption is that the ideal solution would be to do what Vertex Displacement does but on the pixel level.

Malt/Malt/Pipelines/NPR_Pipeline/Shaders/NPR_MeshShader.glsl

Line 107 in 3728027

#ifdef CUSTOM_VERTEX_DISPLACEMENT

So you use derivatives to compute position, normal, uvs and vertex colors at the offsets and then compute the bump at those points.
That should work fine for everything.

But you can "only" use one bump value, you couldn't compute multiple normals from multiple bumps.

[aVersionOfReality]

Any time dFdx/y is involved there are some issues. But as long as its not on an image texture, they are so small it isn't really an issue (at least, in my testing.) Even the current issues in Eevee's bump are only really visible when using hard Toon Shading.

But if we've got a higher quality solution still, then no reason not to use it!

I'm not quite clear on what you mean by only one bump value? You mean if you use multiple height maps, they are all based on the same offsets? That would be fine.

EDIT: See pictures in my other reply. Derivs based on dFdx/y cause blockiness on image texture height maps, but not procedural for whatever reason. I would have expected it on both.

[pragma37]

Any time dFdx/y is involved there are some issues

Any value that changes linearly across the rendered triangle (interpolated per-vertex values like position/normal/uvs are the most obvious example) shouldn't have any issues. That's how mip-mapping works after all.

I'm not quite clear on what you mean by only one bump value?

I mean it would be an output node, like this:

So here the normal in the main pass would have the bump applied.

But you couldn't have regular nodes in the middle of your tree that compute a normal output from a bump input.

[pragma37]

This is what I got from a "naive" implementation:

I expected this to work fine, but I must be missing something. It shows obvious artifacts at quad edges.
They go away with enough subdivisions, but yeah... not perfect.

[pragma37]

Getting this in an EEVEE-like way requires evaluating the previous part of the node tree at different offsets and the Malt node compiler doesn't support this.

We could add a Bump output node though, kind of like the Depth Offset we already have.
You can also use shader derivatives (dfdx/y) on the bump value, but since this works on 2x2 pixel blocks the result works at half the resolution.

That said if you only need this for image textures, you can easily do it in a simple function that samples the texture at offsets.
You could even precompute the normal maps on a separate program, there are plenty of tools to do that.

[aVersionOfReality]

Are you sure Eevee is actually doing this? In my investigation, it was using dFdx/y for the derivs, not offsetting. Unless it changed recently.

[pragma37]

Actually I'm not.
I remember Clément told me the node compiler was able to do so, but I'm not 100% sure if that's what is used for bump.

Edit:
https://github.com/blender/blender/blob/master/source/blender/nodes/shader/nodes/node_shader_bump.cc#L60

[aVersionOfReality]

I'm not entirely sure what's going on in that code, and if its Eevee or just Cycles. I went through a lot of the Eevee bump map code like 8 months ago, and I'm pretty sure I found everything related, and that the height derivs were just dFdx/y. But I know there's been updates since.

But I am looking at an older file where I made my own custom bump node group in Eevee to try to solve some of the issues, and it still has the same issues now. So I don't think anything has changed.

Here's a nose bumped mapped onto Custom Normals with toon shading. Left is the Height Map (procedural), then the Eevee Bump using it, then Eevee Bump with it baked to a 2048x2048 texture (although its not filling the whole texture. The texture fits the whole face. But its still a decent amount of pixels.

So with the procedural texture, the distortion is coming from the Tangent being based on dFdx/y of Position. With the image texture, the blockiness of the derivatives is also very noticable.

Here is procedural height map vs image texture using UV offset derivs and precomputed tangent:

So the Tangent problems are gone, but we do still get blockiness in the derivatives. However, when I made this sort of setup in Malt, it was much less blocky for whatever reason (I can't pull up that file anymore since Malt has updated too many times. So I need to update it. I'll try to get around to that.) Also, if the height map is blurred even very slightly (1 or 2 pixels), the blockiness goes away.