Major bug in Blender 2.8. Discrepancies between Solid/LookDev and Rendered View

Hello everyone, I have been using Blender 2.8 quite extensively and it is a huge improvement. The viewport performance is so good it is almost impossible for me to go back to 2.7, despite a few bugs. However I came across a bug today that is really quite upsetting.

When in solid view, or LookDev view, the UV maps and position of meshes can change when in rendered view or rendering the final version. This has caused a lot of confusion and wasted render time until I realized what was going on. It doesn’t happen with every object or UV map, either. I have attached a bunch of pictures showing the differences.

In my line of work the details are everything, and when the differences between LookDev view and rendered view are this bad it makes the entire program essentially useless for working with. If you can’t reliably see in the viewport what materials and meshes will look like in the final render it will waste a ton of time.

I have not been able to reproduce this with exact steps, but I’m wondering if anyone else has this problem. I searched for it quite a bit and couldn’t even get close to finding anything about it. If it was posted here already please feel free to link the post.

If this isn’t a bug and I am doing something wrong, I would love to know. I have been using Blender for almost 4 years now and I have never come across something like this before.

Thanks,
Jake

Currently, LookDev mode uses a different rendering engine (Eevee) when you are using Cycles as your renderer. I think we will probably change this, as it makes little sense.

This should address your issue.

1 Like

If you have a file you can share with the developers, file a bug report at developer.blender.org and attach the file. The texture misalignment is definitely a bug. There will be some differences because they are different rendering engines, but texture alignment isn’t one of them.

EDIT: I see you already filed T60758

While I would normally agree, I experience the same bug with mesh location when using Solid Viewport. How can anyone accurately render anything if there are changes in mesh location between solid viewport and rendered? Not to mention, Blender 2.7 had material mode which was very necessary for UV mapping materials and preparing a scene for cycles. If there are guaranteed differences between LookDev and cycles, what is the replacement for material mode?

The differences between Eevee and Cycles should be very minimal, and mostly related to lighting because cycles calculates light bounces while eevee uses less accurate (but much faster!) approximation methods. Major discrepancies like mesh location and UV positions should be reported as bugs.

Edit: There are a few shader nodes that are not yet supported in Eevee. In OP’s case he was using displacement which is not yet supported by Eevee.

2 Likes

Looking at the images it seems to me that you are using displacement in cycles, if that’s the case then the vertices will change position in render, and eevee doesn’t support displacement as far as I know, only normal mapping. That would explain the difference between the two.

Try setting the displacement to “bump only” in the material settings and see if that fixes the problem.

3 Likes

Yes. All problems would be solved if the LookDev mode supported Cycles.

1 Like

Using Eevee for lookdev’ing Cycles still makes sense though due to the much faster feedback, even if some features are not supported.

I’d like Cycles supported, but shouldn’t replace Eevee completely if Cycles is the rendering engine.

1 Like

That is actually unrelated. A fast preview of Cycles is something other than Lookdev.

Lookdev: View your object separated from the scene, in different temporary lighting, to test the material

Fast Cycles Preview: View whatever materials or lights from Cycles but using Eevee.

There’s very little overlap between those use-cases, so we should treat them as two different things. Changing the renderer because you are using Lookdev doesn’t make sense. Eevee and Cycles are different enough that you’ll often get quite different results when using things like the AO node, displacement, light paths and other features.

The current situation means that you can’t really use Lookdev for its intended purpose, if you are using Cycles.

Lookdev to me means authoring your materials, and easily setup and compare Eevee and Cycles responses using material outputs. That would mean using the Eevee style lights (or at least the Eevee environment map if lights are difficult).

The idea is, author Eevee and Cycles materials under same lighting and figure out how to workaround any discrepancies.

I can see myself setting up my assets to work well under both renderers. If they look wrong, then it’s probably the lighting and environment.

You might want to use Eevee to preview your full scene or your materials, or your individual assets or anything. It’s useful. But Lookev is not meant for that. It’s using a screwdriver as a hammer. Both are useful things, but we should use the correct tool for the purpose.

Lookdev should use the currently chosen renderer. Cycles and Eevee materials are similar but there are many cases where they will behave different.

1 Like