[Bf-viewport] Unified Principled BSDF and Eevee PBR

Mon Jun 19 19:06:46 CEST 2017

On Mon, Jun 19, 2017 at 2:45 PM, Clément FOUCAULT <foucault.clem at gmail.com>
wrote:

> The Specular output node is here to support Unity's (the game engine)
> specular workflow, which is the old workflow born before the metallic
> workflow spread.
> The specular input has an other meaning in this case and it's the specular
> intensity of the whole material (reflective layer) whether it be metallic
> or dielectric.
>

> If we choose to not support the Specular workflow out of the box then I
> don't see the need for a separate BSDF node.
>

Unity seems to support both workflows now, so unless there is a compelling
reason I think we should have only the Metallic node? Seems that would make
things simpler for everyone, users don't have to make a choice,
importers/exporters only need to handle one node, etc.

> Having the possibility to mix BSDFs would require a different parsing
> method for generating the shader though. All bsdfs nodes should be parsed
> first and then and only then the rest of the tree should be evaluated (thus
> making only one loop evaluating all bsdfs).
>

Mixing support in Eevee would be great, but could be added later of course.
Some special parsing logic for this case seems ok to me, we also do
something similar in Cycles SVM.

I don't think it's a good idea to hide inputs depending on active engine
> since it will disconect existing links.
>

Unsupported linked sockets could be greyed out only perhaps? Certainly we
should not be making any actual changes to the nodes when switching
renderers, it's only only a visualization thing.

I think having a special output node for Eevee that takes surface / volume
> / displacement / AO / pixel depth offset, makes sense and clear the
> confusion on which output would be used. This also ensure the clear
> separation between engines.
>

I think most of the time users want to have the same shader in Cycles and
Eevee. Typically a user is targeting one renderer and then using the other
for e.g. baking or viewport preview. Setting up separate shaders is extra
work, also to keep shaders in sync afterwards.

If a user wants to adapt a Cycles material to Eevee (e.g. adding an AO
map), then they would have to either add an additional output node, or swap
the existing output node. The right choice would not be obvious I think.
I'd rather have separate output nodes be something that the user explicitly
chooses to set up, instead of getting a different output node depending on
the renderer the user created the material under.

2017-06-19 14:11 GMT+02:00 Brecht Van Lommel <brechtvanlommel at pandora.be>:
>
>> Ok, thanks for the explanation.
>>
>> In this design Cycles should also implement fallbacks for Eevee nodes,
>> for baking or rendering in higher quality. But then what's the purpose of
>> separate node types?
>>
>> It's also unclear to me why Metallic and Specular (Dielectric?) are
>> separate nodes, when the Disney BRDF model (that I think we are trying to
>> follow) unifies then.
>>
>>
>> On Jun 19, 2017 11:27, "Dalai Felinto" <dfelinto at gmail.com> wrote:
>>
>> Hi Brecht,
>>
>> Before discussing your suggestion let me elaborate on the original
>> (partly uncommitted) plans:
>>
>> 1) Make the Metallic and Specular nodes shader nodes (as oppose to
>> output nodes as they are now). And connect them to material outputs.
>>
>> 2) Have an Eevee material output. So if a material has both a Cycles
>> material output and an Eevee one, it uses the Eevee, even if it's not
>> the "active" output node.
>>
>> 3) If a material has only Cycles material output (no Eevee), Eevee
>> uses a "fallback" glsl version of Cycles nodes. For the principled
>> shader the internal code will literally be the same as Eevee's. For
>> other nodes not so much.
>>
>> 4) Apart from the Metallic and Specular nodes, we may (time/dev power
>> allowing) get a Hair shader node in the future.
>>
>> What you are proposing is a step further on that and literally use the
>> same Output node, and principled node. I will think about this, but my
>> initial impression is that we are better off keeping things separated.
>>
>> Either way I wanted to make sure we are all on the same page as the
>> current design, before diving further in this discussion.
>>
>> Cheers,
>> Dalai
>> --
>> blendernetwork.org/dalai-felinto
>> www.dalaifelinto.com
>>
>>
>> 2017-06-18 2:32 GMT+02:00 Brecht Van Lommel <brechtvanlommel at gmail.com>:
>> > Hi,
>> >
>> > Regarding the plans mentioned here:
>> > https://wiki.blender.org/index.php/Dev:2.8/Source/Viewport/E
>> evee#UI.2FUX_solution_for_multi-engine_material_outputs
>> >
>> > My hope is that we can have a single uber shader node type for both
>> Cycles
>> > and Eevee, as well a single material output node for
>> > surface/volume/displacement shaders. However from reading that page and
>> > testing the blender2.8 branch it's not clear to me what the plan is.
>> >
>> > Having a single node type would simplify material importers/exporters,
>> as
>> > well as simplify building higher level material/texture layering,
>> texture
>> > painting and baking tools. Unsupported properties and sockets could be
>> > hidden depending on the renderer.
>> >
>> > The current Principled BSDF and Eevee PBR nodes can be unified since
>> they
>> > have matching parameters. Cycles would hide the AO socket because it
>> can't
>> > use baked AO maps, and Eevee would hide a bunch of sockets it does not
>> > support (yet). Future hair and volume uber shaders could also be
>> unified I
>> > think.
>> >
>> > It is useful to be able to create different materials for Cycles and
>> Eevee,
>> > or simplified viewport materials for animators. But I think it's a
>> > relatively minor change, maybe by adding more sockets to the material
>> output
>> > node, or by supporting multiple material output nodes with each
>> indicating
>> > the target renderer.
>> >
>> > Thanks,
>> > Brecht.
>> >
>> > _______________________________________________
>> > Bf-viewport mailing list
>> > Bf-viewport at blender.org
>> > https://lists.blender.org/mailman/listinfo/bf-viewport
>> >
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>
>>
>>
>> _______________________________________________
>> Bf-viewport mailing list
>> Bf-viewport at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-viewport
>>
>>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20170619/37d04851/attachment-0001.htm 