Not only FloatCurve but also Gradient, VectorCurve, and RGB Curve give this jagged result!
If we turn off the adaptive subdivision and set the Displacement to Displacement only mode, it will be solved, but I need both of them.
Blender version 4.1.1
Are you using ‘Displacement Only’ or ‘Displacement and Bump’?
I don’t see any problem using ‘Displacement Only’…
And I confess that ‘Displacement and Bump’ makes very little sense to me, since it adds a new layer of complexity to the normals calculation, and modifies the Normal vectors feeded to the BSDFs.
In these shots “Displacement and bump” but as i said If you don’t turn off “Adaptive Subdivision”, it doesn’t matter in either case, the problem persists, but if you turn it off, the problem will be solved in the “displacement only” case.
Use a full metallic and zero roughness bsdf it is so obviously
(Of course… ) the displacement fine grade depends on the subdivision… so:
This simple plane has a subdiv level 4… and the right part also use smooth shading…
…also… adaptive subdiv… has no problems… 
I used smooth shading too .
You need to pure reflection to see the problem .
roughness can hide it
Test with
Metallic 1, rough 0
I did… the exr i quicly choosed simply does have not much trees to reflect…
…but you already cans see in the other images two light reflections…
Edit:
Okay forest then… also dubdiv 4 or 6 does make a difference:
I still don’t see any problem…
‘Displacement Only’:
And from left to right: (adaptive subdiv modifier, normal subdiv modifier, hires mesh)
It’s true, I was confused
“displacement only” is ok …
And ‘Displacement and Bump’ should never be used!
It’s an old hack, and it messes with your BSDFs normals. IMHO, that option should be removed completely.
1 Like
That’s the forum for… to double and triple check… or to un-confuse users 
Why? What is alternative?
I test this using manual bump node connected to normal socket , we get same results
The ‘Displacement and Bump’ was just to compensate the fact that AdaptiveSubdiv is still an experimental feature… it fakes normals on faces, but displaces vertices; which is a bit clumsy workflow.
I don’t understand what that even means… Bumps/Normals and Displacements are different things… You shouldn’t mix both concepts.
Yes, these two are two different things and our problem is the bump. Of course, we cannot ignore its use! Especially in procedural shaders, so what is the solution? Meanwhile, it is still not clear why this did not happen with math nodes
Thanks
I believe that problem is more related to the interpolation of the FloatCurve node, than to the Bump node… (perhaps, the FloatCurve is giving up the wrong derivatives ?!)
I would need to check the source code, to see what’s going on there.
Using only math nodes to produce a similar curve as the FloatCurve node, produces the correct result.
Edit: I haven’t looked the whole source, but I found plenty of places where the Bump node “fails” to give the correct result dued to a strange calculation of derivatives…
Here’s for example, a BandGradient connected to a Bump (left), and a custom Bump that with it’s own math (right):
it’s not easy that much.
Can this node setup be used in other situations or does it work specifically for this case?Of course, I didn’t understand much out of it
Yes, in most situations it can…
What’s happening there is just a ‘Finite Difference’ of the BandGradient with a very small h value (0.001), in the Tangent and CoTangent directions, which are then added to the Normal vector.
Yeah I’ve had the same experience. Draw up with a curve (even prior to float curve) or color ramp, and the results are anything from unpredictable to completely wrong. Draw them up with math nodes, and you get what you expect. My hairline have receded battling this.
1 Like
It seems to be a bump distance scaleing problem.Iirc then the units are Blenderunits.If the distance are 1 BU then you can guess how the wave (and its normals) would looks like.
1 Like
Yup, that may to be the case here…
But I have to say that the ‘Distance’ value is very non-intuitive. And i also doubt that it’s really measuring BUs, as it’s quite inconsistent depending on what you plug in as ‘Height’ (i.e. math vs texture vs image)…