UI/UX implement per engine material outputs #53214

New Issue

Dalai Felinto · 2017-10-31T16:10:43+01:00

Dalai Felinto commented

2017-10-31 16:10:43 +01:00

In most cases, users will use the same material for multiple engines (e.g., Eevee and Cycles).

However, in some cases users should be able to have different Output nodes in the same material datablock, so that different engines can have different nodes. We need to figure out how we will expose that to the users.

The current proposal is to refine the behaviour of the active output node :

We set it (and save it) manually per engine.
We should restrict active output only to supported output type (we can't have active Eevee's output in cycles if cycles does not handle it).

You can read the original discussion here: https://lists.blender.org/pipermail/bf-viewport/2017-June/000314.html

In most cases, users will use the same material for multiple engines (e.g., Eevee and Cycles). However, in some cases users should be able to have different Output nodes in the same material datablock, so that different engines can have different nodes. We need to figure out how we will expose that to the users. The current proposal is to refine the behaviour of the active output node : * We set it (and save it) manually per engine. * We should restrict active output only to supported output type (we can't have active Eevee's output in cycles if cycles does not handle it). You can read the original discussion here: https://lists.blender.org/pipermail/bf-viewport/2017-June/000314.html

Dalai Felinto commented

2017-10-31 16:10:43 +01:00

Changed status to: 'Open'

Dalai Felinto commented

2017-10-31 16:10:43 +01:00

Added subscribers: @dfelinto, @fclem, @brecht, @JonathanWilliamson, @pablovazquez

Jonathan Williamson commented

2017-10-31 16:43:51 +01:00

To be sure I follow, the current proposal is to support a single Output node, with it outputting the correct data per engine behind the scenes? Such that the user doesn't have to change anything?

Dalai Felinto commented

2017-10-31 17:22:33 +01:00

@JonathanWilliamson You got it wrong.

In 2.79 if you have multiple output nodes, Blender would use the last selected one. This is the "active output node", and it's stored per material I think.
In 2.80 the proposal is to still support multiple output nodes, and have the last selected one as the active. However, instead of storing it per material, we would stored it per material, per engine.

So that the same material can have a different "active output node" for Cycles and for Eevee.

@JonathanWilliamson You got it wrong. In 2.79 if you have multiple output nodes, Blender would use the last selected one. This is the "active output node", and it's stored per material I think. In 2.80 the proposal is to still support multiple output nodes, and have the last selected one as the active. However, instead of storing it per material, we would stored it per material, per engine. So that the same material can have a different "active output node" for Cycles and for Eevee.

Dalai Felinto commented

2017-10-31 17:24:19 +01:00

One thing that is a common issue in theses cases, is to determine which engine to use at a given time. Should it be the scene one, or the workspace one? Same goes for when creating a new material and clicking on "Use nodes".
When trying to add a new node is a bit different because we can allow the "poll" to accept both.

One thing that is a common issue in theses cases, is to determine which engine to use at a given time. Should it be the scene one, or the workspace one? Same goes for when creating a new material and clicking on "Use nodes". When trying to add a new node is a bit different because we can allow the "poll" to accept both.

Jonathan Williamson commented

2017-10-31 17:31:56 +01:00

In 2.80 the proposal is to still support multiple output nodes, and have the last selected one as the active. However, instead of storing it per material, we would stored it per material, per engine.

I understand now. Thanks. That seems to make more sense as well.

One thing that is a common issue in theses cases, is to determine which engine to use at a given time. Should it be the scene one, or the workspace one?

Seems to me this would default to the workspace, since most shading workflows would have either Cycles or Eevee as the final output and the view engine.

It could get tricky quickly...

> In 2.80 the proposal is to still support multiple output nodes, and have the last selected one as the active. However, instead of storing it per material, we would stored it per material, per engine. I understand now. Thanks. That seems to make more sense as well. > One thing that is a common issue in theses cases, is to determine which engine to use at a given time. Should it be the scene one, or the workspace one? Seems to me this would default to the workspace, since most shading workflows would have either Cycles or Eevee as the final output *and* the view engine. It could get tricky quickly...

Brecht Van Lommel commented

2017-10-31 21:00:37 +01:00

Personally I would like to get rid of the "active output node" mechanism. It's really quite confusing and against Blender conventions that selection influences a final render. If it needs to say I think it needs to be controlled by a checkbox on the node instead of by selection.

I think that if there is an engine specific output node, the engine should use that. If there is no such node, the engine can find one that it supports, so Eevee and Cycles would use each others output nodes in that case. If there are multiple output nodes of a given node type, then all but one can be greyed out and never used be any engine. I don't think anything needs to be explicitly stored per engine, just per node type would be enough.

Personally I would like to get rid of the "active output node" mechanism. It's really quite confusing and against Blender conventions that selection influences a final render. If it needs to say I think it needs to be controlled by a checkbox on the node instead of by selection. I think that if there is an engine specific output node, the engine should use that. If there is no such node, the engine can find one that it supports, so Eevee and Cycles would use each others output nodes in that case. If there are multiple output nodes of a given node type, then all but one can be greyed out and never used be any engine. I don't think anything needs to be explicitly stored per engine, just per node type would be enough.

Dalai Felinto commented

2017-10-31 22:01:02 +01:00

Personally I would like to get rid of the "active output node" mechanism. If it needs to stay (...) a checkbox on the node

+1

I think that if there is an engine specific output node, the engine should use that. If there is no such node, the engine can find one that it supports

To clarify your proposal, we would have:

CyclesOutputNode
EeveeOutputNode

Then we have the following scenarios:

If only one node is there (Cycles or Eevee) things will just work for both Cycles and Eevee.
If we have Cycles and Eevee output nodes Cycles use the Cycles node, and Eevee the Eevee node.
If we have more than one of a single type, all but one of that type will be grayed out.

I like this idea. But I think we may also need to clearly indicate which Output node will be used (for workspace and/or scene?) in scenario (2), not only in (3).

> Personally I would like to get rid of the "active output node" mechanism. If it needs to stay (...) a checkbox on the node +1 > I think that if there is an engine specific output node, the engine should use that. If there is no such node, the engine can find one that it supports To clarify your proposal, we would have: * CyclesOutputNode * EeveeOutputNode Then we have the following scenarios: 1. If only one node is there (Cycles or Eevee) things will just work for both Cycles and Eevee. 2. If we have Cycles **and** Eevee output nodes Cycles use the Cycles node, and Eevee the Eevee node. 3. If we have more than one of a single type, all but one of that type will be grayed out. I like this idea. But I think we may also need to clearly indicate which Output node will be used (for workspace and/or scene?) in scenario (2), not only in (3).

Brecht Van Lommel commented

2017-10-31 23:09:42 +01:00

But I think we may also need to clearly indicate which Output node will be used (for workspace and/or scene?) in scenario (2), not only in (3).

I would just ensure the output node name contains the engine. If the workspace and scene engines are different, or if using multiple workspaces, it's not so obvious what some node being highlighted in the node editor means.

> But I think we may also need to clearly indicate which Output node will be used (for workspace and/or scene?) in scenario (2), not only in (3). I would just ensure the output node name contains the engine. If the workspace and scene engines are different, or if using multiple workspaces, it's not so obvious what some node being highlighted in the node editor means.

Brecht Van Lommel commented

2018-08-13 13:00:38 +02:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2018-08-13 13:00:38 +02:00

Brecht Van Lommel self-assigned this 2018-08-13 13:00:38 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI/UX implement per engine material outputs #53214