Bump Node vs. Displacement Node (Bump Only)?

[AndreasResch]

I did a few more tests. It seems as if Cycles struggles with light at flat angles. All the options except “Displacement (Bump Only) - Correction ON” look not great compared to Octane. The later comes close but overall the Octane version still looks better.

I’ve uploaded a layered TIFF file that contains all the iterations to compare … Layered TIFF file

Here’s a comparison between the Octane version and the Cycles/Bump version (Correction ON). The main issue is, that the Cycles version looks very flat and lacks depth. Not great to see in this small comparison slider though. Better download the TIFF file.

I wanted to post the issue in the developer forum, but I don’t seem to have the rights to do so. There were days when users were able to post technical feedback to the devs - too bad. So it’s up in the stars if a dev stumbles over this thread by accident. Otherwise it’s sit and wait.

[SteffenD (Steffen Dünner)]

Thanks a lot for this comparison. In this and several other Cycles related threads here on BA we increasingly find more and more technical aspects that are easily comparable (not only “feelings” or “look how real other renderers look while Cycles doesn’t but I can’t put my finger on it”-stuff) and that might point into directions where Cycles can be improved.

Like energy con-/preservation (before Principled V2 was a thing), texture filtering (mipmaps, tiling), diffuse roughness (Oren-Nayar), … and now bump- / normalmaps.

I also made some comparison renderings (a few days ago for myself, didn’t plan to upload them) to see where the differences are between the render engines I have access to at home currently (Cycles, Karma, Radeon ProRender, EEVEE Next).

The scene is a horizontal cylinder that’s split into two sections so I could directly compare two settings next to each other. Light is a directional light with 6° spread. The texture is the 8k version from here. I used the normal and displacement map for bump. I used Principled / Uber shaders with 0.6 grey diffuse and 0.2 specular roughness.
I decided to just upload the raw renders in no particular order, sadly not with a nice comparison slider, but I think the results speak for themselves:

Left: Cycles normal map with “Bump Correction” (=default, will call it “BC” from now on)
Right: Cycles bump map with BC

Left: Cycles normal map no BC
Right: Cycles bump map no BC

Left: Cycles normal map no BC
Right: Cycles displacement map no BC

Left: Cycles normal map with BC
Right: Cycles displacement map with BC (= best you can get with Cycles currently)

Left: EEVEE Next normal map
Right: EEVEE Next bump map

Left: Karma normal map
Right: Karma bump map

Left: Radeon ProRender normal map
Right: Radeon ProRender bump map (yes, it’s really this blurry!)

It’s kind of shocking how sad Cycles’ default bump and normal maps look compared to the uncorrected versions, to the “Bump only”-displacement versions, the Karma version or probably the Octane version (that I can not render currently). This really shows a part of where the provable and visible differences in final render quality come from.

By the way, if I find time I will give downscaled versions of the 8k texture a try to see how it affects the results. I’ll also try a mipmapped version with Karma and Cycles OSL. But don’t hold your horses

[Midphase (Kays)]

@SteffenD

In this and several other Cycles related threads here on BA we increasingly find more and more technical aspects that are easily comparable (not only “feelings” or “look how real other renderers look while Cycles doesn’t but I can’t put my finger on it”-stuff) and that might point into directions where Cycles can be improved.

Hehe…I think this is a slight reference to me. I agree that getting to the bottom of what is actually happening is always best, but those “feelings” can also be useful by pointing out that all is not quite right and encourage users with more expertise into looking at things like these.

But yeah, between this thread, and my other one, it does appear as if Cycles could use a substantial amount of fine tuning. It’s unfortunate that I don’t think any of the things you mention are in the works for Blender 4.2.

[DeepBlender]

@AndreasResch

Maybe I’ll head over to the dev forum to get some answers. They don’t seem to be here that often.

Have you considered to just submit a bug report? The difference looks significant enough to me that it might be seen as bug.

[SteffenD (Steffen Dünner)]

Ha, you might be right it was a partial reference to you, but I’m sorry if it sounded like a negative reference (it is not). It’s super important that our beloved software gets improved by getting the constructive feedback by people using it. Be it because some guy digged through the source code and found a typo, another one zoomed to 1000% of a rendered output and compared color picker values or someone else just notices that something doesn’t look right.
The task is to feed it to the developers (who aren’t producing beautiful pictures but beautiful code most of the time) in bites they can and want to digest.

As a guy who has to deal with client feedback all the time (and clients doing TV commercials have all sorts of weird feelings ) I just imagine being a developer (of a renderer) and I had to debug the code to fix or improve what someone else thinks “feels wrong” or “doesn’t look as photoreal as in UE5”.

To make a long story short (I just wanted to write a looong text but I have to leave the keyboard right now ), I’m quite sure that most of the points I mentioned are being worked on, or at least they’re on a todo list:

blender

[silex (Jakub Jaszewski)]

@AndreasResch

I did a few more tests. It seems as if Cycles struggles with light at flat angles.

Thanks for the comparisons. To me it doesn’t look like grazing angle problem. At the center of the sphere you can see that Cycles too also puts a lot more darker values and not enough lighter ones.
Some values from the bump are either not converted properly, not normalized or not mixed properly with diffuse color.

[AndreasResch]

I don’t think that will work. Unless it’s a real bug it will come back as “that’s how it is supposed to work”. Unfortunately there’s no good way to communicate with the devs any more about these technical issues, now that the dev forum is locked.

[DeepBlender]

@AndreasResch

I don’t think that will work. Unless it’s a real bug it will come back as “that’s how it is supposed to work”.

Are you sure this isn’t a real bug?

[AndreasResch]

Pretty, pretty, pretty, pretty sure. Looks more like a flawed algorithm. But it would be interesting to test the scene in an older version of Blender just to see the differences.

[silex (Jakub Jaszewski)]

If there is then this is a regression and it should be reported too. Don’t bother with devtalk. Go straight to gitea.

[DNorman]

After further experimenting I have found circumstances where the displacement gives worse results.

This happens with high (ish) values of strength/scale. Values over 0.005 ( half a cm) start to get these spikes creeping in.
In this case the bump node handles the shadows better and does not produce those spikes in the shadow transition.

Here a default sphere with bump set to 0.05 (5 cm)

These “high” values for bump are not strictly a good idea but if you want them the bump node handles the shadows better.

My verdict is to use the displacement for values of bump that are half a cm or less and the bump for higher values.

In theory the sphere is 2m diameter and a strength of 0.005 is half a cm bump.

This is with 0.005 (half cm)

[DeepBlender]

As far as I understand it, when using displacement with bump only, it is supposed to fall back and essentially produce the same result as if you used the bump node and fed that into the normals.
I would assume that is the intended behavior and there is no need for a regression, but unintended behavior. A good comparison should be quite convincing that there is an issue.

[Zebrahead]

"Regression" : Using normal or bump maps in cycles produces flat washed-out...

[DNorman]

It does (nearly), it seems that the displacement method is not affected by the bump correction settings.

Edited
It is affected by the shadow terminator settings but a little different.

[silex (Jakub Jaszewski)]

Other way around. Currently Displacement with Bump Only givers the correct result while Bump node does not.

[AndreasResch]

Yeah. I’ve seen the same issues with larger curvatures. In those cases the Bump node has the better algorithm. So one has to wager which problem is more acceptable for each case.

[AndreasResch]

It is affected by the correction as you can see in my layered TIFF file above. Only marginally though.

[DeepBlender]

Sure, what I meant is that if displacement with bump only is used, as there is no actual displacement, it in a sense should fall back to the same behavior as if a normal input was used.

[DNorman]

Yea, it does seem like a compromise, also as Zebrahead states is a long standing known issue.
At least this thread makes us aware of it and we can choose our poison.

[AndreasResch]

Fortunately bump mapping is rarely used in rendering. So it’s understandable that this issue is but on the back burner.