LookDev & Eevee Preview #68312

New Issue

William Reynish · 2019-08-06T13:54:55+02:00

William Reynish commented

2019-08-06 13:54:55 +02:00

This design task is related to {D5292}

We will change the shading mode design to clarify the purpose and make look dev features available to Cycles and external renderers. This means the following.

Material Preview

LookDev shading mode is renamed to Material Preview. It always uses Eevee as the renderer, and is intended to provide a fast material preview suitable for texture painting, and texture and material setup.

The "Use Scene Lights" and "Use Scene World" options will be removed, and it will always use HDRIs for lighting.

Further, there will additional options to disable some effects that are slow or get in the way of setting up materials. These would be things like depth of field, motion blur, indirect light or bloom, and be disabled by default. The purpose here is not to provide all Eevee renderer controls, just a commonly useful subset. This is not a requirement to be added immediately, and can be done later.

Rendered

Rendered shading gains "Use Scene Lights" and "Use Scene World" options previously in LookDev. These will be enabled by default. When off, HDRIs will be used for lighting instead.

Renderers will be able to customize the shading settings panel and add additional settings. For example choice of render passes to use instead of combined or render quality controls. This is up to each renderer and is not a requirement to be added immediately.

*This design task is related to {[D5292](https://archive.blender.org/developer/D5292)}* We will change the shading mode design to clarify the purpose and make look dev features available to Cycles and external renderers. This means the following. **Material Preview** LookDev shading mode is renamed to Material Preview. It always uses Eevee as the renderer, and is intended to provide a fast material preview suitable for texture painting, and texture and material setup. The "Use Scene Lights" and "Use Scene World" options will be removed, and it will always use HDRIs for lighting. Further, there will additional options to disable some effects that are slow or get in the way of setting up materials. These would be things like depth of field, motion blur, indirect light or bloom, and be disabled by default. The purpose here is not to provide all Eevee renderer controls, just a commonly useful subset. This is not a requirement to be added immediately, and can be done later. **Rendered** Rendered shading gains "Use Scene Lights" and "Use Scene World" options previously in LookDev. These will be enabled by default. When off, HDRIs will be used for lighting instead. Renderers will be able to customize the shading settings panel and add additional settings. For example choice of render passes to use instead of combined or render quality controls. This is up to each renderer and is not a requirement to be added immediately.

William Reynish commented

2019-08-06 13:54:55 +02:00

Added subscriber: @WilliamReynish

Jeroen Bakker was assigned by William Reynish

2019-08-06 13:55:30 +02:00

William Reynish commented

2019-08-06 13:55:30 +02:00

Added subscriber: @brecht

Jeroen Bakker commented

2019-08-06 14:08:39 +02:00

This entails that we will need to render the lookdev spheres using Cycles. Technical this could be done by adding additional preview renders like we have for materials and composite them on top of the viewport, seems to be doable, but a bit hackish as there can actually be tree cycles-sessions at once. Of course we can cache these previews so it only changes when the camera or world settings change.

William Reynish commented

2019-08-06 14:12:18 +02:00

@Jeroen-Bakker I don't really understand why the spheres themselves need to be rendered using Cycles? Is there a technical reason for that? I thought they were just overlays?

Jeroen Bakker commented

2019-08-07 08:41:54 +02:00

Added subscriber: @fclem

Jeroen Bakker commented

2019-08-07 08:41:54 +02:00

LookDev Spheres
HDRI
Depends on what the user expects. I would say that they expect it to be rendered by the engine it is currently using. Showing EEVEE spheres on top of Cycles renders will not produce the expected results (EEVEE doesn't extract hotspots and shadows from HDRI for example). So the reason why rendering the spheres using cycles is first of all functional.

Current Implementation
For performance reasons the current spheres are drawn together with the scene (using some mathematics to place it in the corner) . When we want EEVEE spheres on top of a Cycles rendering we will have some challenges and overhead there as we need to render cycles with the scene, and eevee for the spheres at the same time.

Fast Preview Settings
Slider
I do not think we should hide render preview options under a slider as it will reduce the control that advanced users want. We did try to do it with the workbench, but as it was not well implemented it was also not clear to the user what it did, so users didn't trust it. Of course we can design it better, if so we should design it that the user still has full control without becoming overcomplicated.

Subsurface Scattering
I would propose to remove the this setting as users always want to see them when they are available, and are currently automatically detected and optimized by the EEVEE render pipeline.

Volumetrics
At this point the volumetric rendering do not behave equally between the render engines but still be useful to have.

Sharing Settings
We didn't address the sharing of settings between Cycles and EEVEE when in render mode. I would propose that the settings will be as shared as much as possible, but the settings will be a 3d view specific. So when switching the scene render engine, the view should still look similar.

Just a technical note: Although the resolution setting is Cycles only, we want to store it inside the 3dview.

**LookDev Spheres** *HDRI* Depends on what the user expects. I would say that they expect it to be rendered by the engine it is currently using. Showing EEVEE spheres on top of Cycles renders will not produce the expected results (EEVEE doesn't extract hotspots and shadows from HDRI for example). So the reason why rendering the spheres using cycles is first of all functional. *Current Implementation* For performance reasons the current spheres are drawn together with the scene (using some mathematics to place it in the corner) . When we want EEVEE spheres on top of a Cycles rendering we will have some challenges and overhead there as we need to render cycles with the scene, and eevee for the spheres at the same time. **Fast Preview Settings** *Slider* I do not think we should hide render preview options under a slider as it will reduce the control that advanced users want. We did try to do it with the workbench, but as it was not well implemented it was also not clear to the user what it did, so users didn't trust it. Of course we can design it better, if so we should design it that the user still has full control without becoming overcomplicated. *Subsurface Scattering* I would propose to remove the this setting as users always want to see them when they are available, and are currently automatically detected and optimized by the EEVEE render pipeline. *Volumetrics* At this point the volumetric rendering do not behave equally between the render engines but still be useful to have. **Sharing Settings** We didn't address the sharing of settings between Cycles and EEVEE when in render mode. I would propose that the settings will be as shared as much as possible, but the settings will be a 3d view specific. So when switching the scene render engine, the view should still look similar. Just a technical note: Although the resolution setting is Cycles only, we want to store it inside the 3dview.

Vladimir commented

2019-08-07 09:49:33 +02:00

Added subscriber: @VladimirKunyansky

Vladimir commented

2019-08-07 09:49:33 +02:00

If I has permission, I will leave a comment, because The topic is very important.

Regarding the HDRI, I agree with Jeroen Bakker: LookDev Spheres are important and should show the proper lighting of the scene.

Volumetrics and subsurface scattering.
As already suggested on the right-click-select , must add the ability to turn off the visualization of these effects. If the scene has many objects with volumetrics materials, then viewing the scene causes some difficulties. The volume and SSS are heavily loaded with viewing, and the check-box will help to view the scene without having to turn off the shaders on dozens or hundreds of objects with different materials.
Or, as already suggested, add these features to the "Simplify Scene" section.

Only Render.
In the drop-down menu of the Render View button, it is extremely necessary to return the check box "Only Render" (which was in version 2.79). If some object is hidden for rendering, then this cannot be seen until you press the F12 button.

If I has permission, I will leave a comment, because The topic is very important. Regarding the HDRI, I agree with Jeroen Bakker: LookDev Spheres are important and should show the proper lighting of the scene. **Volumetrics and subsurface scattering.** As already suggested on the [right-click-select ](https://blender.community/c/rightclickselect/mkdbbc/), must add the ability to turn off the visualization of these effects. If the scene has many objects with volumetrics materials, then viewing the scene causes some difficulties. The volume and SSS are heavily loaded with viewing, and the check-box will help to view the scene without having to turn off the shaders on dozens or hundreds of objects with different materials. Or, as already suggested, add these features to the "Simplify Scene" section. **Only Render.** In the drop-down menu of the Render View button, it is extremely necessary to return the check box ["Only Render" ](https://blender.community/c/rightclickselect/d2dbbc/) (which was in version 2.79). If some object is hidden for rendering, then this cannot be seen until you press the F12 button.

William Reynish commented

2019-08-07 09:57:16 +02:00

@Jeroen-Bakker I updated the task image to match your suggestions.

With the HDRI spheres, it seems like a more technical issue. The resulting HDRI sphere would surely look identical?

Re. Resolution: in theory this would be useful to add to Eevee at some point too. At least on my 5K retina iMac, Eevee often has trouble filling all those pixels. But that's not directly relevant here, only to say that this option could become consistent across Cycles & Eevee at some point.

@Jeroen-Bakker I updated the task image to match your suggestions. With the HDRI spheres, it seems like a more technical issue. The resulting HDRI sphere would surely look identical? Re. Resolution: in theory this would be useful to add to Eevee at some point too. At least on my 5K retina iMac, Eevee often has trouble filling all those pixels. But that's not directly relevant here, only to say that this option could become consistent across Cycles & Eevee at some point.

William Reynish changed title from ~~LookDev & Fast Preview~~ to LookDev & Eevee Preview

2019-08-07 10:45:19 +02:00

SecuoyaEx commented

2019-08-07 10:58:10 +02:00

Added subscriber: @SecuoyaEx

SecuoyaEx commented

2019-08-07 10:58:10 +02:00

Let's say I'm using Cycles, but using the Fast preview mode with Eevee underneath. How would I change HDRI and toggle lights on Fast Preview? They are not in the popover so I would have to click on Rendered mode, open the popover and change the HDRI, and then go back to Fast preview? Not having the HDRI toggles and selector affects more negatively Fast preview/Lookdev than it does Rendered view. And if you put Eevee settings in Fast preview together with the HDRI and toggles, then it would make the popover too long.

Having the Lookdev as an extra display mode in Eevee is still useful, as it's just one click away, instead of 3, or 2 and a drag. Even more if you add quick settings in the popover, so the Eevee settings for the fast preview are different than the render or the full shaded mode, which I'm always manually switching back and forth, shadow resolution in particular.

My proposal: Leave things as they are but with some changes

If you use Cycles or another engine, Lookdev would use that engine by default, but it should have a toggle, rather than a dropdown, called Fast preview to use the Eevee backend.
The quick settings for Lookdev would appear as a Gear, like the Shadow or Cavity settings in Solid mode. And only appear either if you click Fast preview in Cycles, or if you're using Eevee. Although I understand that for Eevee, switching back and forth may cause shader recompilation. It may also be cool to have quick settings for Cycles as well
Both popups of both modes should have the Resolution dropdown if using Cycles, and maybe in the future Eevee can have it too
The Only Render toggle would be nice as well, as Vladimir said.

Let's say I'm using Cycles, but using the Fast preview mode with Eevee underneath. How would I change HDRI and toggle lights on Fast Preview? They are not in the popover so I would have to click on Rendered mode, open the popover and change the HDRI, and then go back to Fast preview? Not having the HDRI toggles and selector affects more negatively Fast preview/Lookdev than it does Rendered view. And if you put Eevee settings in Fast preview together with the HDRI and toggles, then it would make the popover too long. Having the Lookdev as an extra display mode in Eevee is still useful, as it's just one click away, instead of 3, or 2 and a drag. Even more if you add quick settings in the popover, so the Eevee settings for the fast preview are different than the render or the full shaded mode, which I'm always manually switching back and forth, shadow resolution in particular. My proposal: Leave things as they are but with some changes - If you use Cycles or another engine, Lookdev would use that engine by default, but it should have a toggle, rather than a dropdown, called Fast preview to use the Eevee backend. - The quick settings for Lookdev would appear as a Gear, like the Shadow or Cavity settings in Solid mode. And only appear either if you click Fast preview in Cycles, or if you're using Eevee. Although I understand that for Eevee, switching back and forth may cause shader recompilation. It may also be cool to have quick settings for Cycles as well - Both popups of both modes should have the Resolution dropdown if using Cycles, and maybe in the future Eevee can have it too - The Only Render toggle would be nice as well, as Vladimir said.

William Reynish commented

2019-08-07 11:04:12 +02:00

The 'Only Render' option is not relevant to this - it is a View Layer option, which would be added to Properties > View Layer, probably under a different name.

Ludvik Koutny commented

2019-08-07 11:16:28 +02:00

Added subscriber: @Rawalanche

Ludvik Koutny commented

2019-08-07 11:16:28 +02:00

Can we please, please pretty please finally fix the background blur in lookdev mode with Eevee? That one makes it really frustrating to use and is the reason I avoid using it unless I really need to: https://devtalk.blender.org/t/lookdev-mode-blurry-background-problem/2706

I doubt there is single person doing lookdev at high professional level who does prefer to not see orientation and relation of the scene environment to the object he's working on.

Can we please, please pretty please finally fix the background blur in lookdev mode with Eevee? That one makes it really frustrating to use and is the reason I avoid using it unless I really need to: https://devtalk.blender.org/t/lookdev-mode-blurry-background-problem/2706 I doubt there is single person doing lookdev at high professional level who does prefer to not see orientation and relation of the scene environment to the object he's working on.

Jeroen Bakker commented

2019-08-07 11:33:05 +02:00

Just for completeness, here is the image that shows the difference when rendering the spheres in cycles and eevee using an HDRI with highlights.

@VladimirKunyansky thanks for your suggestions. When valid we can add options later on, but this needs to be carefully designed.
About the only render option. We are aware of this, but it is not related to shading. There should be a separate design for that.

Just for completeness, here is the image that shows the difference when rendering the spheres in cycles and eevee using an HDRI with highlights. ![image.png](https://archive.blender.org/developer/F7652709/image.png) @VladimirKunyansky thanks for your suggestions. When valid we can add options later on, but this needs to be carefully designed. About the only render option. We are aware of this, but it is not related to shading. There should be a separate design for that.

Ludvik Koutny commented

2019-08-07 12:58:31 +02:00

In #68312#747414, @Jeroen-Bakker wrote:
Just for completeness, here is the image that shows the difference when rendering the spheres in cycles and eevee using an HDRI with highlights.

@VladimirKunyansky thanks for your suggestions. When valid we can add options later on, but this needs to be carefully designed.
About the only render option. We are aware of this, but it is not related to shading. There should be a separate design for that.

This can (and should) be addressed:
https://devtalk.blender.org/t/eevee-soft-shadows-for-environment-light/5256

Edit: Another example of shadow accumulation technique (which Eevee already successfuly uses for area lights) utilized in realtime rasterizer by Substance Painter: https://youtu.be/am0vwULRqHo

My main point being that instead of giving up on the idea of better parity between Cycles and Eevee, it should be simply solved by implementing what's missing in Eevee to match Cycles. It will never be perfect, but it can be close enough that Eevee will truly be usable as a tool look develop Cycles assets.

> In #68312#747414, @Jeroen-Bakker wrote: > Just for completeness, here is the image that shows the difference when rendering the spheres in cycles and eevee using an HDRI with highlights. > > ![image.png](https://archive.blender.org/developer/F7652709/image.png) > > @VladimirKunyansky thanks for your suggestions. When valid we can add options later on, but this needs to be carefully designed. > About the only render option. We are aware of this, but it is not related to shading. There should be a separate design for that. This can (and **should**) be addressed: https://devtalk.blender.org/t/eevee-soft-shadows-for-environment-light/5256 Edit: Another example of shadow accumulation technique (which Eevee already successfuly uses for area lights) utilized in realtime rasterizer by Substance Painter: https://youtu.be/am0vwULRqHo My main point being that instead of giving up on the idea of better parity between Cycles and Eevee, it should be simply solved by implementing what's missing in Eevee to match Cycles. It will never be perfect, but it can be close enough that Eevee will truly be usable as a tool look develop Cycles assets.

William Reynish commented

2019-08-07 13:24:28 +02:00

My main point being that instead of giving up on the idea of better parity between Cycles and Eevee, it should be simply solved by implementing what's missing in Eevee to match Cycles. It will never be perfect, but it can be close enough that Eevee will truly be usable as a tool look develop Cycles assets.

There is no plan or intention to give that up - on the contrary, this direction allows us to do this even more, because we have a dedicated Eevee Preview mode exactly for this purpose. Here we could potentially do all sorts of tricks to make Eevee emulate Cycles even more.

That's one of the main points: the old LookDev mode was not for emulating Cycles using Eevee, it was for LookDev. This change should make everything a lot more clear.

> My main point being that instead of giving up on the idea of better parity between Cycles and Eevee, it should be simply solved by implementing what's missing in Eevee to match Cycles. It will never be perfect, but it can be close enough that Eevee will truly be usable as a tool look develop Cycles assets. There is no plan or intention to give that up - on the contrary, this direction allows us to do this even more, because we have a dedicated Eevee Preview mode exactly for this purpose. Here we could potentially do all sorts of tricks to make Eevee emulate Cycles even more. That's one of the main points: the old LookDev mode was not for emulating Cycles using Eevee, it was for LookDev. This change should make everything a lot more clear.

Jeroen Bakker commented

2019-08-07 13:47:36 +02:00

Added subscriber: @JulienKaspar

Jeroen Bakker commented

2019-08-07 13:47:36 +02:00

Some feedback from @JulienKaspar:

How will this work when doing texture painting? During texture painting you want to select different lighting conditions, but having a fast render. Probably in that case (with this design) he will still need to switch the scene render engine to EEVEE.
Workbench is not used for texture painting as you want to see the shaded result using the correct UV mapping.
Also checked the SSS/Volumetrics toggle, and that is something that he definitely would use for fast previewing of the scene (Lighting workflow).

The second option might be a limitation of workbench. But still you could be working on a cycles scene, but need the options that is suggested to be moved into the rendering pop-over.

Some feedback from @JulienKaspar: - How will this work when doing texture painting? During texture painting you want to select different lighting conditions, but having a fast render. Probably in that case (with this design) he will still need to switch the scene render engine to EEVEE. - Workbench is not used for texture painting as you want to see the shaded result using the correct UV mapping. - Also checked the SSS/Volumetrics toggle, and that is something that he definitely would use for fast previewing of the scene (Lighting workflow). The second option might be a limitation of workbench. But still you could be working on a cycles scene, but need the options that is suggested to be moved into the rendering pop-over.

SecuoyaEx commented

2019-08-07 13:56:57 +02:00

His first point echoes what I said. In this current design, you can't change HDRI in Fast view without switching to Rendered first.

This totally puts in question the whole design, why move the HDRI selector to the other Render popover if it's already in LookDev where it's needed. That's why I made those suggestions.

His first point echoes what I said. In this current design, you can't change HDRI in Fast view without switching to Rendered first. This totally puts in question the whole design, why move the HDRI selector to the other Render popover if it's already in LookDev where it's needed. That's why I made those suggestions.

YAFU commented

2019-08-07 14:03:18 +02:00

Added subscriber: @YAFU

YAFU commented

2019-08-07 14:03:18 +02:00

To not complicate matters further, my proposal is to leave things as they are, and add a tiny sphere icon/option for "Fast Preview/Material view" in the row of current 4 icon spheres in Viewport Shading icon row (Wireframe/Solid/Material View/Look Dev/Rendered). So Look Dev will always respect render engine by default, and new option "Material View" will always use Eevee by default. Remaining the main options that the user wants a single click away.

Edit:
I just found a weak point in my proposal. For Eevee, Material View and LookDev can end up being very similar.

To not complicate matters further, my proposal is to leave things as they are, and add a tiny sphere icon/option for "Fast Preview/Material view" in the row of current 4 icon spheres in Viewport Shading icon row (Wireframe/Solid/Material View/Look Dev/Rendered). So Look Dev will always respect render engine by default, and new option "Material View" will always use Eevee by default. Remaining the main options that the user wants a single click away. Edit: I just found a weak point in my proposal. For Eevee, Material View and LookDev can end up being very similar.

William Reynish commented

2019-08-07 14:40:16 +02:00

So Look Dev will always respect render engine by default, and new option "Material View" will always use Eevee by default.

That's exactly what this is. LookDev always uses the current renderer, and what you call Material View is what we call Eevee Preview.

> So Look Dev will always respect render engine by default, and new option "Material View" will always use Eevee by default. That's exactly what this is. LookDev always uses the current renderer, and what you call Material View is what we call Eevee Preview.

Brecht Van Lommel commented

2019-08-07 23:08:27 +02:00

I'm not sure about the name "Eevee Preview". I think you want a dedicated shading mode for texture painting also when using Eevee, so that you can quickly switch to see your textures and material clearly, and then go back to seeing what it looks like with full scene lighting. For that I think "Material Preview" is a better name when Eevee is the scene engine. It could be named "Eevee Material Preview" when Cycles is the scene engine.

This mode should use a HDR image by default (not sure if an option for scene world and lights is even needed). Effects like depth of field, motion blur, SSR, light probes should indeed be disabled by default or entirely as well, both for performance and to give a clear render without blurring. If there are some good settings to lower quality and significantly increase performance they could be exposed, but the specific settings need some thinking since there aren't always obvious "overall quality" type settings that fit well here.

I'm not sure about the name "Eevee Preview". I think you want a dedicated shading mode for texture painting also when using Eevee, so that you can quickly switch to see your textures and material clearly, and then go back to seeing what it looks like with full scene lighting. For that I think "Material Preview" is a better name when Eevee is the scene engine. It could be named "Eevee Material Preview" when Cycles is the scene engine. This mode should use a HDR image by default (not sure if an option for scene world and lights is even needed). Effects like depth of field, motion blur, SSR, light probes should indeed be disabled by default or entirely as well, both for performance and to give a clear render without blurring. If there are some good settings to lower quality and significantly increase performance they could be exposed, but the specific settings need some thinking since there aren't always obvious "overall quality" type settings that fit well here.

William Reynish commented

2019-08-08 01:25:18 +02:00

It could be named "Eevee Material Preview" when Cycles is the scene engine.

To me that doesn't make a lot of sense, since the entire purpose of that shading mode is to preview your cycles scene using Eevee. The current LookDev mode, which always uses Eevee, is really not very good for viewing Cycles materials, because many things differ slightly in how materials work.

If it's called Material Preview that just sounds like a confusing synonym for LookDev again.

The two use-cases are really different:

Checking your model & material in various different lighting conditions using current renderer always = LookDev (found in Rendered popover)
Previewing your Cycles scene using Eevee = Eevee Preview

This is very clear I think, and would remove the muddied confusion we currently have.

If there are some good settings to lower quality and significantly increase performance they could be exposed, but the specific settings need some thinking since there aren't always obvious "overall quality" type settings that fit well here.

Yes it's not 100% clear which Eevee features to expose here. In my experience there are some key controls we could expose which generally have a big impact on performance, such as shadow resolution.

> It could be named "Eevee Material Preview" when Cycles is the scene engine. To me that doesn't make a lot of sense, since the entire purpose of that shading mode is to preview your cycles *scene* using Eevee. The current LookDev mode, which always uses Eevee, is really not very good for viewing Cycles materials, because many things differ slightly in how materials work. If it's called Material Preview that just sounds like a confusing synonym for LookDev again. The two use-cases are really different: - Checking your model & material in various different lighting conditions using current renderer always = LookDev (found in Rendered popover) - Previewing your Cycles scene using Eevee = Eevee Preview This is very clear I think, and would remove the muddied confusion we currently have. > If there are some good settings to lower quality and significantly increase performance they could be exposed, but the specific settings need some thinking since there aren't always obvious "overall quality" type settings that fit well here. Yes it's not 100% clear which Eevee features to expose here. In my experience there are some key controls we could expose which generally have a big impact on performance, such as shadow resolution.

SecuoyaEx commented

2019-08-08 11:36:54 +02:00

I feel this is important and it's not being addressed or acknowledged despite being the third time I bring this up. Please acknowledge this, even if to tell me I'm crazy. This design is saying to me that I should not be allowed to lookdev Cycles materials with an Eevee preview, like it's somehow wrong or a second class thing to do even though I constantly check Cycles materials using Eevee in the current Lookdev mode, when the shaders are not too different. All I see is two or three extra step that will make that more cumbersome, as it hasn't been properly explained what the Eevee preview mode will do. Will it...?:

Use the lookdev HDRI that is used in Rendered mode, if the lookdev toggles are on? This is bad because the ONLY way to change HDRI would be to first click on Rendered mode to change the contents of its popover, and then go back.
Only use scene lights, regardless of Lookdev toggles in the Cycles rendered mode? This would be worse because you'd literally have to change to Eevee as render engine to have the HDRI selector.

It's overdesigning! All you need to do is add an Eevee Preview toggle inside the current Lookdev shading mode popover so it doesn't use Eevee by default and uses Cycles/Other engine instead. It seems the only problem you are trying to solve is to make the word Lookdev live up to the actual look of the engine selected. But just doing this allows you to achieve exactly that

List of bullet points on why just adding the Fast Preview/Eevee preview toggle is better and solves every point in your design document:

Does it live up to the name "Lookdev?", yes. It will be using the engine of choice by default. But the Scene light toggles will be off by default.
Does it allow you to check lights? Yes, just click the toggles.
Can you preview your scene with Eevee? Yes, just click Eevee preview.
Can you preview your materials with Eevee preview while using the HDRI and using Cycles? Yes, and you don't even have to change shading mode, popovers or engine to do it.
Could you change quick settings in for the Eevee preview? If it's too cluttered, add them one popover deeper, under a Gear button. After all, what needs to be fast is switching to Lookdev, and this is still faster than changing engines.

The only "problem" would be that whenever Eevee preview is On, it's not "Lookdev" based on your definition. But that's semantics, not an actual usability problem. You can as easily just change the name of the Third shading mode button from Lookdev to something else, and put the word lookdev inside the popup whenever Cycles is used instead of the Eevee Preview

List of problems of the current document:

It will make it harder to preview Cycles materials with Eevee, or make it harder to change Lookdev HDRIs while doing it. Which is totally a valid workflow, and there's no need to be condescending to the user as if they don't know the limitations of Eevee Vs Cycles when authoring materials.
Having the HDRI selector on the Rendered mode popover gives the false impression that when you press F12 you will get that HDRI lighting, which doesn't happen.
Makes it harder to switch between Lookdev lighting, with lookdev HDRI and Scene lights Off, and Rendered lighting, with Scene world and Scene lights On, since it's two toggles inside the popup, instead of a different mode clickeable from outside.

Is it really worth moving all these things just for the sake of semantics at the expense of the user? All because Lookdev HAS to mean "actually using the engine used for the final render" for whatever reason? Cmon. Have my back on this @JulienKaspar. Make them listen ?

I feel this is important and it's not being addressed or acknowledged despite being the third time I bring this up. Please acknowledge this, even if to tell me I'm crazy. This design is saying to me that I should not be allowed to lookdev Cycles materials with an Eevee preview, like it's somehow wrong or a second class thing to do even though I constantly check Cycles materials using Eevee in the current Lookdev mode, when the shaders are not too different. All I see is two or three extra step that will make that more cumbersome, as it hasn't been properly explained what the Eevee preview mode will do. Will it...?: 1) Use the lookdev HDRI that is used in Rendered mode, if the lookdev toggles are on? This is bad because the ONLY way to change HDRI would be to first click on Rendered mode to change the contents of its popover, and then go back. 2) Only use scene lights, regardless of Lookdev toggles in the Cycles rendered mode? This would be worse because you'd literally have to change to Eevee as render engine to have the HDRI selector. It's overdesigning! All you need to do is add an Eevee Preview toggle inside the current Lookdev shading mode popover so it doesn't use Eevee by default and uses Cycles/Other engine instead. It seems the only problem you are trying to solve is to make the word Lookdev live up to the actual look of the engine selected. But just doing this allows you to achieve exactly that List of bullet points on why just adding the Fast Preview/Eevee preview toggle is better and solves every point in your design document: - Does it live up to the name "Lookdev?", yes. It will be using the engine of choice by default. But the Scene light toggles will be off by default. - Does it allow you to check lights? Yes, just click the toggles. - Can you preview your scene with Eevee? Yes, just click Eevee preview. - Can you preview your materials with Eevee preview while using the HDRI and using Cycles? Yes, and you don't even have to change shading mode, popovers or engine to do it. - Could you change quick settings in for the Eevee preview? If it's too cluttered, add them one popover deeper, under a Gear button. After all, what needs to be fast is switching to Lookdev, and this is still faster than changing engines. The only "problem" would be that whenever Eevee preview is On, it's not "Lookdev" based on your definition. But that's semantics, not an actual usability problem. You can as easily just change the name of the Third shading mode button from Lookdev to something else, and put the word lookdev inside the popup whenever Cycles is used instead of the Eevee Preview List of problems of the current document: - It will make it harder to preview Cycles materials with Eevee, or make it harder to change Lookdev HDRIs while doing it. Which is totally a valid workflow, and there's no need to be condescending to the user as if they don't know the limitations of Eevee Vs Cycles when authoring materials. - Having the HDRI selector on the Rendered mode popover gives the false impression that when you press F12 you will get that HDRI lighting, which doesn't happen. - Makes it harder to switch between Lookdev lighting, with lookdev HDRI and Scene lights Off, and Rendered lighting, with Scene world and Scene lights On, since it's two toggles inside the popup, instead of a different mode clickeable from outside. Is it really worth moving all these things just for the sake of semantics at the expense of the user? All because Lookdev HAS to mean "actually using the engine used for the final render" for whatever reason? Cmon. Have my back on this @JulienKaspar. Make them listen ?

Brecht Van Lommel commented

2019-08-08 13:54:32 +02:00

In #68312#748205, @WilliamReynish wrote:
To me that doesn't make a lot of sense, since the entire purpose of that shading mode is to preview your cycles scene using Eevee. The current LookDev mode, which always uses Eevee, is really not very good for viewing Cycles materials, because many things differ slightly in how materials work.

I guess this is just a language thing, about what you think of when you read "Eevee Preview". For you it's "Preview using Eevee" and I read it as "Preview of the Eevee render". In my opinion we should also name it after what we intend the user to use it for, which is to be a preview of materials mainly for texturing. It may not be accurate always, but that's exactly why it's a "preview".

Anyway, this is just naming. What is important to me are these two things missing from the proposal:

Making "Eevee Preview" or whatever it is named also available when using Eevee as the scene engine, for the purpose of texturing. And for that the name "Eevee Preview" is strange.
Having the choice of HDR available in "Eevee Preview", which I guess was just left out of the mockup and not an intentional choice.

> In #68312#748205, @WilliamReynish wrote: > To me that doesn't make a lot of sense, since the entire purpose of that shading mode is to preview your cycles *scene* using Eevee. The current LookDev mode, which always uses Eevee, is really not very good for viewing Cycles materials, because many things differ slightly in how materials work. I guess this is just a language thing, about what you think of when you read "Eevee Preview". For you it's "Preview using Eevee" and I read it as "Preview of the Eevee render". In my opinion we should also name it after what we intend the user to use it for, which is to be a preview of materials mainly for texturing. It may not be accurate always, but that's exactly why it's a "preview". Anyway, this is just naming. What is important to me are these two things missing from the proposal: * Making "Eevee Preview" or whatever it is named also available when using Eevee as the scene engine, for the purpose of texturing. And for that the name "Eevee Preview" is strange. * Having the choice of HDR available in "Eevee Preview", which I guess was just left out of the mockup and not an intentional choice.

SecuoyaEx commented

2019-08-08 14:00:41 +02:00

This comment was removed by @SecuoyaEx

*This comment was removed by @SecuoyaEx*

msalv commented

2019-08-08 14:08:33 +02:00

Added subscriber: @moisessalvador

msalv commented

2019-08-08 14:08:33 +02:00

This comment was removed by @moisessalvador

*This comment was removed by @moisessalvador*

Brecht Van Lommel commented

2019-08-08 14:09:03 +02:00

@SecuoyaEx, the issue you point out was probably just something that was left out of the mockup and not an intentional choice to exclude the HDRs from the "Eevee Preview" settings. But we need @WilliamReynish to clarify that.

SecuoyaEx commented

2019-08-08 14:10:35 +02:00

Thank you! @brecht

Pedro A. commented

2019-08-20 22:25:01 +02:00

Added subscriber: @povmaniac

Tyler Furby commented

2019-08-20 23:02:46 +02:00

Added subscriber: @tylerfurby

Tyler Furby commented

2019-08-20 23:07:19 +02:00

I would like to add, I think it would be important to add rendering out as sequences in this "eevee preview" to preview animation sequences. Could be very beneficial to custom render engines, and the industry in general, helping animators, directors, and the like.

William Reynish commented

2019-08-20 23:18:57 +02:00

@brecht no, the idea was that the temp HDRI thing is tied to LookDev. Eevee Preview would preview the scene, using the scene’s lights and materials.

Brecht Van Lommel commented

2019-08-20 23:30:15 +02:00

But that doesn't work, scene lights are not usable for texture painting in general, and texture painting is mostly done with Eevee.

lvxejay commented

2019-08-21 00:14:35 +02:00

Added subscriber: @lvxejay

lvxejay commented

2019-08-21 00:14:35 +02:00

The Look Development workflow is really straightforward. Model/Create an asset or assembly, create materials for those assets, add lights, and tweak till you're happy. Look Dev view in Blender should reflect this simplicity. From my perspective I've always seen this as a massive improvement over the OpenGL Material preview mode from Blender 2.7x. As for the design implementation, there are several cues to be taken from Marmoset Toolbag and Katana. However, when it comes to software UI and UX, everyone has their own opinion on what things should look like, so I don't want to push for anything too specific...

The real problem here is that EEVEE does not have a visualization API. Namely, Render Engine X or Y cannot hook into EEVEE. If we leave it this way, Look Dev view is pointless. End users should just switch back and forth between EEVEE and Cycles rendered view, since that is essentially what they're doing when they pop open Look Dev mode now. I understand that the original intent was to keep EEVEE's shading model in the same lane as Cycles so that the same nodes would work between them. Whatever interface exists between Cycles and EEVEE should just be abstracted and implemented via the Python API for external engines to hook into.

The Look Development workflow is really straightforward. Model/Create an asset or assembly, create materials for those assets, add lights, and tweak till you're happy. Look Dev view in Blender should reflect this simplicity. From my perspective I've always seen this as a massive improvement over the OpenGL Material preview mode from Blender 2.7x. As for the design implementation, there are several cues to be taken from Marmoset Toolbag and Katana. However, when it comes to software UI and UX, everyone has their own opinion on what things should look like, so I don't want to push for anything too specific... The real problem here is that EEVEE does not have a visualization API. Namely, Render Engine X or Y cannot hook into EEVEE. If we leave it this way, Look Dev view is pointless. End users should just switch back and forth between EEVEE and Cycles rendered view, since that is essentially what they're doing when they pop open Look Dev mode now. I understand that the original intent was to keep EEVEE's shading model in the same lane as Cycles so that the same nodes would work between them. Whatever interface exists between Cycles and EEVEE should just be abstracted and implemented via the Python API for external engines to hook into.

Tyler Furby commented

2019-08-21 00:21:01 +02:00

I agree with Jared's insight here. Leaving Look Dev the way it is, and simply allowing for custom render engines to make use of some sort of EEVEE API, for use of previewing realtime in Look Dev mode. Then when EEVEE is selected as the render engine, allowing you to render sequences and such from your custom render engine's node tree ShaderNodeTree. And having fuller options to the EEVEE engine such as Bloom, etc.

I agree with Jared's insight here. Leaving Look Dev the way it is, and simply allowing for custom render engines to make use of some sort of EEVEE API, for use of previewing realtime in Look Dev mode. Then when EEVEE is selected as the render engine, allowing you to render sequences and such from your custom render engine's node tree `ShaderNodeTree`. And having fuller options to the EEVEE engine such as Bloom, etc.

Brecht Van Lommel commented

2019-08-21 00:36:50 +02:00

This discussion has gone on for quite a while, I've now made a decision now on what we will do.

There are many more useful things that can be done. But the point of this task was to make some decision regarding the patches that @Jeroen-Bakker has been working on. Hopefully it's clear now and a relatively straightforward change.

This discussion has gone on for quite a while, I've now made a decision now on what we will do. There are many more useful things that can be done. But the point of this task was to make some decision regarding the patches that @Jeroen-Bakker has been working on. Hopefully it's clear now and a relatively straightforward change.

Brecht Van Lommel commented

2019-08-21 00:44:57 +02:00

Regarding allowing other renderers to extend Eevee, that is a highly complicated project. When realtime renderers were simple this might have been feasible. But with complex multi-pass rendering, caching and prefiltering, it becomes impractical for another renderer to just plug-in their BSDFs or lights. It would be a big API, and keeping that anywhere near stable and supported would make it difficult to evolve Eevee and improve its rendering algorithms. For now this is not going to happen, that's not a trade-off we are willing to make.

lvxejay commented

2019-08-21 01:25:57 +02:00

It seemed like we were well on our way to this API/Interface: https://developer.blender.org/D2577 I don't understand why this is being abandoned.

Brecht Van Lommel commented

2019-08-21 01:47:46 +02:00

That patch was less than 10% of the overall work needed. It was abandoned for being too big a project and the reasons I stated above.

SecuoyaEx commented

2019-08-21 11:15:08 +02:00

While I'm happy that previewing materials with HDRI and Eevee is back, now there's the opposite issue if you remove Use Scene Lights from the 3rd shading mode. Being able to see the scene lights with Eevee when authoring Cycles materials is also useful (eg the specular from light sources is more accurate than the HDRI, or the sharp contrast of lights might be better sometimes) Both things are useful. And this new change, while an improvement over the past version of the document still looks like a middle ground compromise, politician style, that doesn't improve over what exists just for the sake of semantics. To summarize, see this chart:

And a way to do it is to simply have a toggle inside the 3rd shading mode of the current 2.80 popover, similar to what was shown on the first videos. It's the easiest thing you can do an coincidentally the better option. You could use Cycles by default and the toggle would make it use Eevee, the quick settings could be hidden under a gear subpopover...

You could instead have the Use Scene Lights toggles back on the 3rd shading mode popover for this new version of the document, but then that would mean replicating both the HDRI selector and the toggles in both popovers, it's not as beautiful, possibly more work for you, but it would be nice too.

If what really bothers people is the word (because sometimes it would be Look development, sometimes Material preview, sometimes Fast preview of lights, and sometimes preview of lights with the final render engine) then look for a better word, not for worse usability

While I'm happy that previewing materials with HDRI and Eevee is back, now there's the opposite issue if you remove Use Scene Lights from the 3rd shading mode. Being able to see the scene lights with Eevee when authoring Cycles materials is also useful (eg the specular from light sources is more accurate than the HDRI, or the sharp contrast of lights might be better sometimes) Both things are useful. And this new change, while an improvement over the past version of the document still looks like a middle ground compromise, politician style, that doesn't improve over what exists just for the sake of semantics. To summarize, see this chart: ![proposal.png](https://archive.blender.org/developer/F7678954/proposal.png) And a way to do it is to simply have a toggle inside the 3rd shading mode of the current 2.80 popover, similar to what was shown on the first videos. It's the easiest thing you can do an coincidentally the better option. You could use Cycles by default and the toggle would make it use Eevee, the quick settings could be hidden under a gear subpopover... You could instead have the Use Scene Lights toggles back on the 3rd shading mode popover for this new version of the document, but then that would mean replicating both the HDRI selector and the toggles in both popovers, it's not as beautiful, possibly more work for you, but it would be nice too. If what really bothers people is the word (because sometimes it would be Look development, sometimes Material preview, sometimes Fast preview of lights, and sometimes preview of lights with the final render engine) then look for a better word, not for worse usability

SecuoyaEx commented

2019-08-28 17:27:44 +02:00

Please don't remove Use Scene Lights/World from the Material preview. I already outlined good reasons above. Please.

Hadrien Brissaud commented

2019-09-03 00:29:02 +02:00

Added subscriber: @hadrien

Hadrien Brissaud commented

2019-09-03 00:29:02 +02:00

For what it's worth, here is my use case : I have a scene set to render with Cycles, of which I render out previews using lookdev mode, with 'scene lights' and 'scene world' enabled, because that's what I need in a preview (not just previewing assets, but entire animated shots with lighting and backdrop). Why not simply use Eevee as the scene renderer then ? Good question ! Simply because I do full renders once in a while to check on the final look and lighting. Ideally, - and I have read all of the above and understood at least 40% of it- I could still do that after this change.

SecuoyaEx commented

2019-09-03 10:55:31 +02:00

Right now I'm working in something architectural that involves constantly tweaking the position of buildings to know where sun light and shadow falls, and Eevee's shadows are accurate enough that I don't have to switch to full a rendered Cycles view, which would be slower in this asset heavy scene. But I do use the full rendered view as well. This is more about feedback in the viewport than rendering a playblast. Could you still do it in this new design? Sure, only if you switch to eevee as the default render engine.

They can literally design this to satisfy EVERY use case in the chart, AND being easier to develop. But for no reason they are choosing to make one or another use case harder, while making it harder for themselves to develop, idk why

Right now I'm working in something architectural that involves constantly tweaking the position of buildings to know where sun light and shadow falls, and Eevee's shadows are accurate enough that I don't have to switch to full a rendered Cycles view, which would be slower in this asset heavy scene. But I do use the full rendered view as well. This is more about feedback in the viewport than rendering a playblast. Could you still do it in this new design? Sure, only if you switch to eevee as the default render engine. They can literally design this to satisfy EVERY use case in the chart, AND being easier to develop. But for no reason they are choosing to make one or another use case harder, while making it harder for themselves to develop, idk why

William Reynish commented

2019-09-03 11:05:08 +02:00

@SecuoyaEx yes of course you could do that - that's the point of the Eevee Preview - you can use Eevee to preview the lighting in your scene.

Hadrien Brissaud commented

2019-09-03 11:58:16 +02:00

@WilliamReynish Oh so it's actually an additional mode ? I thought that would replace Lookdev. Ok, so I understand better now : Lookdev becomes a way to preview your assets using the scene engine -supposedly the one that'll be used for the final renders- and Material Preview is gonna be what Lookdev was until now. Am I correct ?

@WilliamReynish Oh so it's actually an *additional* mode ? I thought that would replace Lookdev. Ok, so I understand better now : Lookdev becomes a way to preview your assets using the scene engine -supposedly the one that'll be used for the final renders- and Material Preview is gonna be what Lookdev was until now. Am I correct ?

William Reynish commented

2019-09-03 11:59:24 +02:00

@hadrien yes exactly, that's right.