[Bf-viewport] Unified Principled BSDF and Eevee PBR

[Dalai Felinto]

Hi Brecht,
I had a short meeting with Clément today and:

(2) We agreed that it can be fine to use the principled node for both.
It will be tackled soon.

(1) Clément is still against that. I will let him articulate. But
basically he foresees specific Eevee settings such as "Pixel Depth
Offset" that we will need in the future.

I'm personally fine with your proposal, assuming we can get the enum
property idea to work. But let's see if we can all agree here before
ruling one way or another.

Cheers,
Dalai
--
blendernetwork.org/dalai-felinto
www.dalaifelinto.com


2017-06-21 19:17 GMT+02:00 Brecht Van Lommel <brechtvanlommel at pandora.be>:
> 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
>
>
>
> _______________________________________________
> Bf-viewport mailing list
> Bf-viewport at blender.org
> https://lists.blender.org/mailman/listinfo/bf-viewport
>