[Bf-viewport] Unified Principled BSDF and Eevee PBR

[Brecht Van Lommel]

1) This could be done with an enum property on the output node to restrict
the output to one renderer. A switch node is perhaps a bit too flexible to
visualize well in the UI or for exporters to handle. I think the important
thing is that by default users should not have to think about per-renderer
output.

2) There is no need to get rid of approximations and slow down Eevee to
match Cycles exactly. We want the Cycles OpenGL viewport to be fast since
that what you'll use for modelling/sculpting/painting/animation, there is
already a slow/accurate raytraced version. There are cases where Cycles
renderer supports additional features, but that shouldn't affect Eevee
performance.

I think the bigger conflict is between using Eevee for games and
stills/animation. For games you need more restrictions to get predictable
performance and compatibility with specific engines, while for
stills/animation you want the full flexibility of shader nodes. That's not
just about the surface shader but also about disallowing procedural
textures and other shading nodes, having layered materials pre-baked into
texture maps, etc. Still I think this could all use the same Principled
BSDF node.


On Wed, Jun 21, 2017 at 3:36 PM, Dalai Felinto <dfelinto at gmail.com> wrote:

> I see two different points here.
>
> 1) Use the same material output node for Cycles and Eevee
> 2) Use the same shader node for Cycles Principled and Eevee Metallic
>
> 1) Use the same material output node for Cycles and Eevee
> ==============================================
> The current design was to allow for material tweaks for different engines.
>
> For now you would do it by having an Eevee and a Cycles output node
> side by side. An alternative is to have a switch node in the nodetree
> that runs different options depending on the engine.
>
> If we use the same output node for both (and other) engines we either
> give up on allowing different outputs for the same material. Or we
> need to find a solution for this problem.
>
>
> 2) Use the same shader node for Cycles Principled and Eevee Metallic
> ======================================================
> Pros
> ------
> * Standard / exchange format
>
> According to Blender Manual the principled node follows an industry
> standard model aiming at interchangeability [1].
>
> * Simple for users to learn a single system
> * Easy to maintain (code-wise)
>
>
> Cons
> -------
> * We may have to choose between performance and accuracy.
>
> UE4 mention in their paper about choices that they made for their PBR
> implementation based on Disney's [2]. Eevee shouldn't be slower only
> because it would be nice to support Cycles 1:1.
>
> Did I miss any other core point here?
>
> [1] - https://docs.blender.org/manual/es/dev/render/cycles/
> nodes/types/shaders/principled.html
>
> [2] - https://de45xmedrsdbp.cloudfront.net/Resources/files/
> 2013SiggraphPresentationsNotes-26915738.pdf
>
> Regards,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
> _______________________________________________
> 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/20170621/d7a823b9/attachment.htm