Page MenuHome

Use Scene Render Engine for Look Dev
AbandonedPublic

Authored by Jeroen Bakker (jbakker) on Jul 12 2019, 4:58 PM.

Details

Summary

Any Render Engine can now be used in look dev mode (as long as they have
implemented it).

  • Added a bl_use_look_dev attribute to bpy.types.RenderEngine. This

attribute is used to check if the render engine can render the lookdev
shading mode without the support of EEVEE.

  • External engines that want to use this feature should provide their own shading pop-over. This way users will not be confused that settings will not work as it is not implemented in the add-on of the external engine or cannot be supported at all by the external engine.

Future changes would be:

  • Support for the Look Development Overlay.
  • Make Cycles render the Look Development Shading mode.

Note that this functionality is not being used yet. It can be tested by setting the bl_use_look_dev of Cycles to True.

diff --git a/intern/cycles/blender/addon/__init__.py b/intern/cycles/blender/addon/__init__.py
index 6d6f89603fe..468d04ba5b8 100644
--- a/intern/cycles/blender/addon/__init__.py
+++ b/intern/cycles/blender/addon/__init__.py
@@ -55,6 +55,7 @@ class CyclesRender(bpy.types.RenderEngine):
     bl_idname = 'CYCLES'
     bl_label = "Cycles"
     bl_use_eevee_viewport = True
+    bl_use_look_dev = True
     bl_use_preview = True
     bl_use_exclude_layers = True
     bl_use_save_buffers = True

Diff Detail

Repository
rB Blender
Branch
T66746 (branched from master)
Build Status
Buildable 4125
Build 4125: arc lint + arc unit

Event Timeline

Jeroen Bakker (jbakker) retitled this revision from LookDev: Use Scene Render Engine for Look Dev to (WIP) Use Scene Render Engine for Look Dev.Jul 12 2019, 4:59 PM
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Jul 12 2019, 6:10 PM
source/blender/editors/space_view3d/view3d_draw.c
1461–1462

I would like to modify this function to be complete. Currently It only does the exceptions and the normal behavior is implemented in the draw manager. We should combine these two functions.

Rename this method to ED_view3d_active_engine_type

Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)Jul 12 2019, 6:23 PM
Jeroen Bakker (jbakker) planned changes to this revision.Jul 13 2019, 10:29 AM
  • Moved determination of actual render engine to the draw manager.
  • External engine now have the responsibility to fill the Shading PopOver.
Jeroen Bakker (jbakker) retitled this revision from (WIP) Use Scene Render Engine for Look Dev to Use Scene Render Engine for Look Dev.Jul 17 2019, 2:59 PM
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)
Jeroen Bakker (jbakker) edited the summary of this revision. (Show Details)
  • Added workaround for missing id.data when cycles accesses shading.type

Trying to revert last diff

Jeroen Bakker (jbakker) planned changes to this revision.Jul 19 2019, 8:37 AM
  • stop rendering when swiching back to EEVEE for look dev.
  • Free the render engine when the use_scene_render_engine is changed.
Brecht Van Lommel (brecht) requested changes to this revision.Jul 31 2019, 12:58 PM

I'm not sure this is the best way to arrange these options. I think it's much more clear for users if "LookDev" is always Eevee and "Rendered" is always Cycles. And then "Rendered" can get options to disable the scene lights or use a custom background.

The name "LookDev" is then not really accurate, but still I think it's better to keep that separation between engines more clear, rather than "LookDev" shading mode using a different renderer depending on the settings.

@Julien Kaspar (JulienKaspar) and @Andy Goralczyk (eyecandy), do you have a preference on how this would work?

This revision now requires changes to proceed.Jul 31 2019, 12:58 PM

I'm not sure this is the best way to arrange these options. I think it's much more clear for users if "LookDev" is always Eevee and "Rendered" is always Cycles. And then "Rendered" can get options to disable the scene lights or use a custom background.
The name "LookDev" is then not really accurate, but still I think it's better to keep that separation between engines more clear, rather than "LookDev" shading mode using a different renderer depending on the settings.
@Julien Kaspar (JulienKaspar) and @Andy Goralczyk (eyecandy), do you have a preference on how this would work?

The current state is quite confusing and this solution would add confusion on top, not remove it. There are already issues which this one would not solve, for example:
If you select Cycles to be your render engine, LookDev remains Eevee, yet Eevee settings are nowhere to be present unless you switch back to Eevee. So for a new user for example, it's not obvious that LookDev mode actually supports things like AO and SSR, if he switched renderer to Cycles and discovered LookDev mode afterwards. There's nothing implying that those effects are controlled by the settings set up in a renderer which is not active.

Another big issue is that there's little parity between Eevee and Cycles output. So it's hardly ever possible to use Eevee to lookdev assets for Cycles. It's very dangerous as one can spend hours working on shading that ends up looking very different once switched to Cycles. As long as this is the case, the only safe way is to always lookdev assets using the renderer you will be using for final. Also, if someone is doing scene for Cycles, or Eevee, they have to be done from both renderers from scratch, especially in scenes with more complex shading and lighting, such as environments. Just switching from Eevee to Cycles almost never works. They require unique setup.

Lastly, Cycles still, to this day, does not support Local View, which makes LookDev Cycles support all the more useful.

In a nutshell, as long as there is not proper visual parity between Cycles and Eevee, it doesn't make sense for LookDev and Rendered modes to use two different renderers. From the user confusion standpoint, mixing them in any way is also worse. The only worse solution than that I can think of would be adding unique renderer settings for LookDev and Rendered views individually. x_x

The issues you mention are unrelated to this, they are to be solved separately. Being able to use Eevee when Cycles is the active render engine is important for texture painting, we are not going to change LookDev to always be Cycles, that's not on the table.

The issues you mention are unrelated to this, they are to be solved separately. Being able to use Eevee when Cycles is the active render engine is important for texture painting, we are not going to change LookDev to always be Cycles, that's not on the table.

I never suggested LookDev should be always Cycles. I suggested LookDev and Rendered views should always use the same, active render engine. If it's Cycles, both would be Cycles, if it's Eevee, both would be Eevee.

I think this is the big part of why these issues appear - that you are solving them separately, with lack of unified vision or a model workflow. The point about necessity of Eevee for texture painting is certainly valid, but if I understand it correctly, you are wanting to sacrifice the entire LookDev viewport mode and turn it into Eevee view mode instead.

I think LookDev mode should remain just that. LookDev mode. I've spent almost all my 3D career doing mostly lookdev, and the basis of the workflow is following:
All you really want is to isolate certain object from the scene, and view it under some neutral, calibrated HDRI with interference of other scene objects and scene lights, and then once you are done tweaking the materials, viewing the tweaked object in a scene with atmospheric lighting, scene lights and other objects should be just a matter of single click, in case of Blender switching from LookDev mode back to Rendered. Instead of a chore of manually unhiding all the lights, swapping environment map, etc...

Such convenient LookDev workflow is almost in place in Blender, except of 2 issues, one being blurring of environment map in LookDev mode, and other one being inability to use desired renderer in LookDev mode, which directly concerns this task. Once these two would be resolved, user could switch between neutral HDRI calibrated environment and scene lighting with a single click.

On the other hand, I indeed don't have any good idea where would the workplace for texture painting be then... and it would also mean that both Cycles and Eevee render settings have to be available at the same time.

Sorry if you also find this off topic, but I don't think it's really possible to discuss feature design without the context in which it relates to other features. I don't think banning any contextual discussion and designing the feature with completely tunnel vision can lead to success.

Switching between using scene lights and neutral lights would be a single click in the Viewport Shading settings, regardless if that's in LookDev or Rendered shading mode. The question here is if switching between those should be the same as switching shading modes (whatever they are called, they can be renamed). And I don't think that's needed here.

There are a lot of renderer specific settings that could be added, like showing render passes or using full render resolution instead of viewport resolution, etc. I think it's a more clear design if those are all part of the same shading modes, instead of being awkwardly spread between Rendered and sometimes LookDev depending on the settings.

Switching between using scene lights and neutral lights would be a single click in the Viewport Shading settings, regardless if that's in LookDev or Rendered shading mode. The question here is if switching between those should be the same as switching shading modes (whatever they are called, they can be renamed). And I don't think that's needed here.

Alright then. Fair point.

YAFU (YAFU) added a subscriber: YAFU (YAFU).EditedJul 31 2019, 1:58 PM

LookDev mode also works as fast Material/textures preview, as Material view mode in 2.79. You can see materials with textures, it's fast, without noise. Eevee was thought from the beginning as a quick/fast preview mode for Cycles. So I think devs are doing well, faster and cleaner mode should be by default (Eevee), and if the user needs LookDev for Cycles, simply enable Use Scene Render Engine.

I'm not sure this is the best way to arrange these options. I think it's much more clear for users if "LookDev" is always Eevee and "Rendered" is always Cycles. And then "Rendered" can get options to disable the scene lights or use a custom background.
The name "LookDev" is then not really accurate, but still I think it's better to keep that separation between engines more clear, rather than "LookDev" shading mode using a different renderer depending on the settings.
@Julien Kaspar (JulienKaspar) and @Andy Goralczyk (eyecandy), do you have a preference on how this would work?

I absolutely agree with this notion. LookDev is a quick way to preview your shaders without having to wait a long time. It should always use eevee or something that previews as quick as possible. Having Cycles render the LookDev seems counterproductive.

I'm not sure this is the best way to arrange these options. I think it's much more clear for users if "LookDev" is always Eevee and "Rendered" is always Cycles. And then "Rendered" can get options to disable the scene lights or use a custom background.
The name "LookDev" is then not really accurate, but still I think it's better to keep that separation between engines more clear, rather than "LookDev" shading mode using a different renderer depending on the settings.
@Julien Kaspar (JulienKaspar) and @Andy Goralczyk (eyecandy), do you have a preference on how this would work?

I agree with @Ludvik Koutny (rawalanche) on:

All you really want is to isolate certain object from the scene, and view it under some neutral, calibrated HDRI with interference of other scene objects and scene lights, and then once you are done tweaking the materials, viewing the tweaked object in a scene with atmospheric lighting, scene lights and other objects should be just a matter of single click, in case of Blender switching from LookDev mode back to Rendered. Instead of a chore of manually unhiding all the lights, swapping environment map, etc...

For me this is the case for both Eevee & Cycles so the switch between them in LookDev is a very welcome addition. This is especially the case sometimes when the shading is actually quite different between the 2 render engines (like with unsupported shaders & nodes).
Sometimes I really want to have the perks on the LookDev mode for Cycles, especially with some of the planned features I discussed with @Jeroen Bakker (jbakker) where you can switch between rendering passes, etc.

So I'd say: Definitely make LookDev features available for Cycles, no matter how exactly the implementation should look like.

Absolutely LookDev should be able to work with Cycles. As I see it, part of the issue is that we are asking LookDev to perform very different tasks:

  1. A tool for previewing your material outside the current scene with temporary lighting
  2. A fast preview mode for Cycles

Those are, IMO, to very different things. The confusion is compounded by the fact that, when you use Eevee, LookDev then is definitely for the 1st purpose, so in effect the view mode takes different roles depending on the render engine.

To me the solution is simple:

  • LookDev should ALWAYS use the current render engine
  • for the ‘fast preview of Cycles scenes’ use case, we could add a separate view mode for that, which does use Eevee to try and approximate your Cycles scene.