Lookdev supports bump, but cycles not?

Using Blender 2.8, i created a nice skin material for a dino :
When using lookdev preview all seams great


But in render preview i get :

And here is a full render :

Using blender 2.8 cpu render on windows.

This is an UI inconsistency.
Displacement nodes are new in 2.8.
It looks like during the process of their creation, displacement socket of material output was restricted to exclude Bump node.

I don’t remember if it is intentional. It is a better practice to plug Bump node into Shader node instead of material output. You have a better control of Bump, if it is done by shader instead of globally.
There is no problem if you plug Bump node into normal input of Principled shader.

Anyways, if they want to discourage this practice, devs should not allow EEVEE to do, so.
Or if it is an oblivion for Cycles, Cycles should be fixed.

The issue is that LookDev uses Eevee, even if the renderer is set to Cycles. Eevee and Cycles aren’t identical, and have some settings specific to each renderer. The real solution would be change it, so that Cycles LookDev actually uses Cycles. This would eliminate any differences between LookDev and Rendered views


ok so it worked in the shader material instead of the output material, got to get used to that.

What would be the point of having a rendered view then ?

Rendered view used the environment and lights - LookDev is for viewing your material in many lighting conditions, separate from the scene. In Eevee it works this way already.

2 Likes

But in this case, we are not talking about specific settings.
We are talking about same Bump map node supported differently by both render engines nodes UI.

There may be difference in the way bump looks in both render engines. But that is not the point, here.
The point is just : why response of nodes UI corresponds to Bump in EEVEE and no Bump in Cycles ?
When using Cycles, you can connect a displacement node, a normal node, a texture node (color socket orgreyscale image/value socket), a math node or a ColorRamp (after this texture) to Displacement node : it produces Bump.
But connecting a Bump node does not produce a Bump, this is an inconsistency.
There is no reason to disallow indirect connection from a texture to this socket through Bump node and allow direct connection from a texture to this socket.
If the goal is to make a restriction to Displacement node workflow, restriction should be less permissive.

The difference is because LookDev uses Eevee, even if you pick Cycles as your renderer. This needs to be fixed.

This part does not relate to lookdev. What is described here is still incoherent if you don’t use LookDev at all and just use Rendered display.

For most people, unless they sport dual RTX 2080Ti cards or some such, Cycles will just not be responsive enough to support lookdev. If you’re going to “fix” this, I suggest simply allowing the user to pick the lookdev renderer separately. This would also allow other renderers to have their own lookdev modes.

1 Like

There should be a fast preview mode, of course. But that really has nothing to do with LookDev.

Why do you say that? Isn’t lookdev exactly that? A fast preview mode for shader editing?

No, with Eevee, LookDev isn’t faster. If just allows you to accurately view objects separated from their environment in various lighting conditions. LookDev is only useful if the materials are correct, and so it must use the chosen renderer.

‘Fast preview of Cycles using OpenGL’ is something else, unrelated.

Here is what I would want for this to work, Eevee works fine but Cycles:

  • With all objects; ignore scene lighting and light only using Lookdev HDRs, overriding my exposure settings. Option to enable “Trace Rays to HDR only”, meaning that reflections and refractions only lookup the HDR.

  • With object in isolation (which also doesn’t work now); ignore scene lighting and light only using Lookdev HDRs, overriding my exposure settings. Option to enable “Trace Rays to HDR only”, meaning that reflections and refractions only lookup the HDR.

If all we got was working isolation mode (and no Lookdev), I would have to go back and forth on the exposure setting; sun&sky would be far too bright for auditing a velvety chair with aniso feet (both not supported by Eevee) that is normally positioned in an indoor scene (and exposed for it).

How do you mean that? It takes at least half a minute even for simple materials with a plain environment map to converge on cycles to the point where you can accurately judge the surface shading without being hampered by noise. On Eevee it’s closer to seconds even for complex ones.

That’s why you are confused. LookDev is being used for something different than the intended purpose. Fast preview of Cycles is different from LookDev. With Eevee, LookDev isn’t faster.

I’m not confused, I immensely value how quickly and nicely Eevee works as shading preview for Cycles. I dare say, the speed and responsiveness is lookdev’s most important feature. It makes no sense to make lookdev in cycles slow on account of a small imperfection.

Or are you saying you want (someone) to write yet another rasteriser that is not eevee but would achieve slightly better parity with cycles?

Or maybe what you’re saying is that you want to add two different functionally identical lookdev modes, except one would render in eevee and the other in cycles?

Currently, we have lots of viewport settings for Rendered display mode to be faster than high quality render.
A Lookdev mode using cycles would probably be a kind of optimized set of such settings to be fast with HDRIs for background.

I am not sure it is necessary to make things as is. It is probably more logical. But it is probably less work to make a quick way to reuse lookdev HDRIs in Rendered display mode as Background textures.

Maybe just keep as is, but remove the bump node from the material output shader, so the fault i made wouldnt occure, if it has to be set to the shaders then the gui shouldnt mislead.