[Bf-viewport] Unified Principled BSDF and Eevee PBR

Brecht Van Lommel brechtvanlommel at pandora.be
Mon Jun 19 14:11:52 CEST 2017


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/
Eevee#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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-viewport/attachments/20170619/19ae0f4c/attachment.htm 


More information about the Bf-viewport mailing list