<div dir="ltr"><div>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.<br></div><div><br></div>So my worries with a singular output node:<div><br></div><div>- 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.</div><div><div><br class="gmail-Apple-interchange-newline">- 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.<br></div></div><div><br></div><div>- 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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>This way :</div><div>- user don't have to care when switching engines with one output. It just work.</div><div>- if multiple output nodes exists use the one active for the current engine (support for specific nodetree per engine).</div><div><br></div><div>This idea offers the same benefits that the enum method, with the added bonus it's not mixing stuff into one node.</div><div><br></div><div>I hope I expressed my idea clearly and did not make it sounds really complex.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-06-22 18:21 GMT+02:00 Dalai Felinto <span dir="ltr"><<a href="mailto:dfelinto@gmail.com" target="_blank">dfelinto@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Brecht,<br>
I had a short meeting with Clément today and:<br>
<br>
(2) We agreed that it can be fine to use the principled node for both.<br>
It will be tackled soon.<br>
<br>
(1) Clément is still against that. I will let him articulate. But<br>
basically he foresees specific Eevee settings such as "Pixel Depth<br>
Offset" that we will need in the future.<br>
<br>
I'm personally fine with your proposal, assuming we can get the enum<br>
property idea to work. But let's see if we can all agree here before<br>
ruling one way or another.<br>
<span class="im HOEnZb"><br>
Cheers,<br>
Dalai<br>
--<br>
<a href="http://blendernetwork.org/dalai-felinto" rel="noreferrer" target="_blank">blendernetwork.org/dalai-<wbr>felinto</a><br>
<a href="http://www.dalaifelinto.com" rel="noreferrer" target="_blank">www.dalaifelinto.com</a><br>
<br>
<br>
</span><div class="HOEnZb"><div class="h5">2017-06-21 19:17 GMT+02:00 Brecht Van Lommel <<a href="mailto:brechtvanlommel@pandora.be">brechtvanlommel@pandora.be</a>>:<br>
> 1) This could be done with an enum property on the output node to restrict<br>
> the output to one renderer. A switch node is perhaps a bit too flexible to<br>
> visualize well in the UI or for exporters to handle. I think the important<br>
> thing is that by default users should not have to think about per-renderer<br>
> output.<br>
><br>
> 2) There is no need to get rid of approximations and slow down Eevee to<br>
> match Cycles exactly. We want the Cycles OpenGL viewport to be fast since<br>
> that what you'll use for modelling/sculpting/painting/<wbr>animation, there is<br>
> already a slow/accurate raytraced version. There are cases where Cycles<br>
> renderer supports additional features, but that shouldn't affect Eevee<br>
> performance.<br>
><br>
> I think the bigger conflict is between using Eevee for games and<br>
> stills/animation. For games you need more restrictions to get predictable<br>
> performance and compatibility with specific engines, while for<br>
> stills/animation you want the full flexibility of shader nodes. That's not<br>
> just about the surface shader but also about disallowing procedural textures<br>
> and other shading nodes, having layered materials pre-baked into texture<br>
> maps, etc. Still I think this could all use the same Principled BSDF node.<br>
><br>
><br>
> On Wed, Jun 21, 2017 at 3:36 PM, Dalai Felinto <<a href="mailto:dfelinto@gmail.com">dfelinto@gmail.com</a>> wrote:<br>
>><br>
>> I see two different points here.<br>
>><br>
>> 1) Use the same material output node for Cycles and Eevee<br>
>> 2) Use the same shader node for Cycles Principled and Eevee Metallic<br>
>><br>
>> 1) Use the same material output node for Cycles and Eevee<br>
>> ==============================<wbr>================<br>
>> The current design was to allow for material tweaks for different engines.<br>
>><br>
>> For now you would do it by having an Eevee and a Cycles output node<br>
>> side by side. An alternative is to have a switch node in the nodetree<br>
>> that runs different options depending on the engine.<br>
>><br>
>> If we use the same output node for both (and other) engines we either<br>
>> give up on allowing different outputs for the same material. Or we<br>
>> need to find a solution for this problem.<br>
>><br>
>><br>
>> 2) Use the same shader node for Cycles Principled and Eevee Metallic<br>
>> ==============================<wbr>========================<br>
>> Pros<br>
>> ------<br>
>> * Standard / exchange format<br>
>><br>
>> According to Blender Manual the principled node follows an industry<br>
>> standard model aiming at interchangeability [1].<br>
>><br>
>> * Simple for users to learn a single system<br>
>> * Easy to maintain (code-wise)<br>
>><br>
>><br>
>> Cons<br>
>> -------<br>
>> * We may have to choose between performance and accuracy.<br>
>><br>
>> UE4 mention in their paper about choices that they made for their PBR<br>
>> implementation based on Disney's [2]. Eevee shouldn't be slower only<br>
>> because it would be nice to support Cycles 1:1.<br>
>><br>
>> Did I miss any other core point here?<br>
>><br>
>> [1] -<br>
>> <a href="https://docs.blender.org/manual/es/dev/render/cycles/nodes/types/shaders/principled.html" rel="noreferrer" target="_blank">https://docs.blender.org/<wbr>manual/es/dev/render/cycles/<wbr>nodes/types/shaders/<wbr>principled.html</a><br>
>><br>
>> [2] -<br>
>> <a href="https://de45xmedrsdbp.cloudfront.net/Resources/files/2013SiggraphPresentationsNotes-26915738.pdf" rel="noreferrer" target="_blank">https://de45xmedrsdbp.<wbr>cloudfront.net/Resources/<wbr>files/<wbr>2013SiggraphPresentationsNotes<wbr>-26915738.pdf</a><br>
>><br>
>> Regards,<br>
>> Dalai<br>
>> --<br>
>> <a href="http://blendernetwork.org/dalai-felinto" rel="noreferrer" target="_blank">blendernetwork.org/dalai-<wbr>felinto</a><br>
>> <a href="http://www.dalaifelinto.com" rel="noreferrer" target="_blank">www.dalaifelinto.com</a><br>
>> ______________________________<wbr>_________________<br>
>> Bf-viewport mailing list<br>
>> <a href="mailto:Bf-viewport@blender.org">Bf-viewport@blender.org</a><br>
>> <a href="https://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-viewport</a><br>
><br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> Bf-viewport mailing list<br>
> <a href="mailto:Bf-viewport@blender.org">Bf-viewport@blender.org</a><br>
> <a href="https://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-viewport</a><br>
><br>
______________________________<wbr>_________________<br>
Bf-viewport mailing list<br>
<a href="mailto:Bf-viewport@blender.org">Bf-viewport@blender.org</a><br>
<a href="https://lists.blender.org/mailman/listinfo/bf-viewport" rel="noreferrer" target="_blank">https://lists.blender.org/<wbr>mailman/listinfo/bf-viewport</a><br>
</div></div></blockquote></div><br></div>