[Bf-viewport] Unified Principled BSDF and Eevee PBR

[Clément FOUCAULT]

First of all, I see the pros of having a unified system because we would
not have to take care of which output type to use and all material could be
directly compatible across Cycles and Eevee.

So my worries with a singular output node:

- If each renderer is going to add their own inputs to the output node it's
going to be messy. Even if we greyed out to indicate which inputs are
actually used. Imagine having permanently all inputs of 4 render engines
even if you don't use them.

- Other render engines may not have the same inputs. Eevee and Cycles are
pretty similar because they are Physically based. But other engines may
want other types of inputs.

- Eevee will surelly need more inputs than cycles that can't be per bsdf
(only one value per pixel), like Pixel Depth Offset (used for Parallax
Occlusion Mapping), and for some effects IOR, SSR Normals, AO,
Lightmaps...(I don't know what future will bring/may require). We may use
first bsdfs input for some of them but then user may want explicit control.

Also, in my opinion, adding a selector on the output node will only lead to
confusion to what node is in use because all output nodes will have the
same look.

So my suggestion is : We make Eevee compatible with Cycles' output, and
Cycles compatible with Eevee's one. Then we 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).

This way :
- user don't have to care when switching engines with one output. It just
work.
- if multiple output nodes exists use the one active for the current engine
(support for specific nodetree per engine).

This idea offers the same benefits that the enum method, with the added
bonus it's not mixing stuff into one node.

I hope I expressed my idea clearly and did not make it sounds really
complex.

2017-06-22 18:21 GMT+02:00 Dalai Felinto <dfelinto at gmail.com>:

> 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
> >
> _______________________________________________
> 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/20170622/46e908dd/attachment.htm