[Bf-cycles] Disney BRDF Implementation in Cycles

Mon May 23 09:49:56 CEST 2016

Hi,

It might either be decoupled BRDF created by the compiler and merged with a
mix closure, or it might also be a glass-like closure where we create
reflection and refraction closures in svm_node_closure_bsdf().

Didn't check it all in details, so can't really tell what would be the
ultimate way to go here.

On Mon, May 23, 2016 at 8:28 AM, Pascal Schön <pascal_schoen at gmx.net> wrote:

> Hey Brecht,
>
> Thanks for your reply. You have a point there. That was also one of my
> thoughts.
>
> For me it is not 100% clear how to call multiple SVM closures. This is my
> current understanding of it:
> In the nodes.cpp and nodes.h, the node with its parameters is initiated.
> There I have to compile my node with the SVMCompiler in a way that the
> existing BsdfNode does? I have to add the parameters via
> compiler.add_node(...) so that I can access them in the
> svm_node_closure_bsdf(...) function in svm_closure.h. In the
> svm_node_closure_bsdf(...) I then call the three closures that I have
> created. Am I right with this?
>
> Regards,
> Pascal
>
> -----Original Message-----
> From: bf-cycles-bounces at blender.org [mailto:bf-cycles-bounces at blender.org]
> On Behalf Of Brecht Van Lommel
> Sent: Samstag, 21. Mai 2016 17:03
> To: Discussion list to assist Cycles render engine developers
> Subject: Re: [Bf-cycles] Disney BRDF Implementation in Cycles
>
> Hi Pascal,
>
> I think it should be exposed as a single node to users, it should not be
> necessary to create node groups, we should make this as easy to use as
> possible. Having a single node will also make it easier to import/export
> materials, by having a single standard. With node groups users can combine
> things in different ways and how it then maps to materials in external game
> engines or renderers is not always clear.
>
> Once that is done, we can consider exposing some of the building blocks,
> either by extending existing BSDF nodes with more options or adding new
> nodes, but that's secondary.
>
> Internally in Cycles however, a single ShaderNode can generate multiple
> SVM / OSL nodes, or one SVM / OSL node that generates multiple closures.
> You can do that in whatever way gives the cleanest implementation, it
> doesn't need to correspond to what is presented in the user interface.
>
> I'm very excited about this project by the way, I think a lack of this
> kind of node is the #1 usability issue in Cycles, great to see it being
> addressed.
>
> Regards,
> Brecht.
>
>
> On Wed, May 18, 2016 at 9:36 AM, Pascal Schön <pascal_schoen at gmx.net>
> wrote:
> > Hey,
> >
> >
> >
> > Now that the Disney BRDF is committed into a new branch of the Blender
> > git, I’m working on refining it. Currently it is a single node that
> > only OSL can process. But I want it to be like all the other shaders.
> >
> > Here I’m getting the problem to process it via SVM which seems to be
> tricky.
> > I think, for this a split version of the BRDF/BSDF would be the best
> > in the following way:
> >
> >
> >
> > Burley Diffuse: This can be included in the Diffuse BSDF node by
> > adding a new selection to the drop down menu.
> >
> > Sheen: I would separate this from the default diffuse part into a new
> > node OR also include it in the Diffuse BSDF node as a new selection.
> > Which one would be better?
> >
> > Subsurface Scattering: Here the default Subsurface Scattering node can
> > be used because it already implements the updated version from Burley.
> >
> > Disney Specular: This would be a new node because it has the metal and
> > dielectric part which would be hard to get into the Glossy BSDF node
> > (primarily because of the parameter names).
> >
> > Disney Clearcoat: This would also be a new node.
> >
> >
> >
> > What do you think? Would this be a better solution. One problem of
> > this is that artists have to create a node group that implements the
> > correct behavior. Is there a way of providing a node group that artists
> can use?
> >
> >
> >
> > I hope you have some suggestions on this topic.
> >
> >
> >
> > Pascal
> >
> >
> >
> > From: bf-cycles-bounces at blender.org
> > [mailto:bf-cycles-bounces at blender.org]
> > On Behalf Of Sergey Sharybin
> > Sent: Dienstag, 17. Mai 2016 09:29
> > To: Discussion list to assist Cycles render engine developers
> > Subject: Re: [Bf-cycles] Disney BRDF Implementation in Cycles
> >
> >
> >
> > Hi,
> >
> >
> >
> > Thanks for sharing the work!
> >
> >
> >
> > As for getting commit access to our git, think it's all reasonable to
> > move development of such feature under blender.org infrastructure (in
> > a branch initially, so we don't ruing master branch immediately). For
> > that you'll need to be registered at developer.blender.org first.
> >
> >
> >
> > Also, if you can drop by to IRC #blendercouders ar irc.freenode.net it
> > will speed up some communication. You can poke me in there (nick
> > hackerman), or just ask the guys around there if you'll have some
> difficulties or such.
> >
> >
> >
> >
> >
> > On Tue, May 17, 2016 at 9:09 AM, "Pascal Schön"
> > <pascal_schoen at gmx.net>
> > wrote:
> >
> > I have pushed my implementation in a bitbucket repository with the
> > branch name cycles_disney_brdf. You can clone (or add it as a new
> > remote) and test it, if you want:
> >
> >
> >
> > https://bitbucket.org/VanCantus/blender
> >
> >
> >
> > But now I have another question for committing to the original Blender
> repo.
> > I need commit rights but don't know how to get it. I've read that I
> > have to get in contact with one of the admins, but on the wiki I'm
> > always refered to the mailing lists. Thus I just wanted to ask, if I
> > only have to write to the bf-committers list or what do I have to do?
> >
> >
> >
> > You can answer directly to my mail address if is refered to my
> > committing question, because it doesn't have to be discussed here I
> > think. ;-)
> >
> >
> >
> > Pascal
> >
> >
> >
> > Gesendet: Donnerstag, 12. Mai 2016 um 13:54 Uhr
> > Von: "Pascal Schön" <pascal_schoen at gmx.net>
> > An: "Discussion list to assist Cycles render engine developers"
> > <bf-cycles at blender.org>
> > Betreff: Re: [Bf-cycles] Disney BRDF Implementation in Cycles
> >
> > Yes, that's excacly what it is. It's an approximation of the
> > glossiness of a clear varnish. It's described in the paper that Disney
> > published and I refered to in my first mail.
> >
> > Pascal
> >
> > On 5/11/16, 19:39 Zauber Paracelsus <zauber at gridmail.org> wrote:
> >
> > Pardon my asking, but what is clearcloat?  Is that a simulation of
> > having a thin layer of glossy/transmissive material on top of another?
> (eg:
> > simulating things like varnish)
> >
> > On 05/11/2016 01:36 PM, "Pascal Schön" wrote:
> >
> > Thanks for your quick replies.
> >
> > Some words to the implementation:
> >
> > I've already splitted the BRDF into three closures after trying to get
> > a single closure implementation to work correctly. But it came to my
> > mind that this would be against the cycles architecture of splitting
> > stuff into diffuse and glossy. And it made it also much more complex.
> >
> > The three closures are:
> > - disney_diffuse(...): Calculates the Burley diffuse term, subsurface
> > scattering and the sheen
> > - disney_specular(...): Calculates the "normal" specular highlight and
> > the metalness (also anisotropy is included here)
> > - disney_clearcoar(...): By this the clearcoat specular highlight is
> > calculated (less bright and no anisotropy)
> >
> > In an OSL script, which is also the script for the node, these three
> > closures are called correctly and added together.
> >
> > I've already seen the updated version of the Disney BRDF but I wanted
> > to focus on the more simple one that was proposed in 2012. The
> > additionals (like getting from a BRDF to a BSDF) would be one of the
> next steps.
> >
> > I'm going to commit my implementation to a new branch next week,
> > because this week is a bit stressful and as it is my first commit, I
> > wanted to take some time for it.
> >
> > Pascal
> >
> > On 11.05.16, 19:06 Stefan Werner <swerner at smithmicro.com> wrote:
> >
> > Eventually, it might be interesting to split it into separate
> > closures, so that one can still use separate ray counts for
> > specular/diffuse/transmission and get them to render into separate
> > passes. This will probably require to put fresnel back into the
> > closures (going back in history, it looks like Cycles initially had
> that).
> >
> > Stefan Werner | Senior Software Engineer; Productivity & Graphics
> > Smith Micro Software, Inc. | http://www.smithmicro.com
> > <http://www.smithmicro.com/>
> >
> >
> >
> >
> >
> > On 5/11/16, 4:18 PM, "bf-cycles-bounces at blender.org on behalf of Lukas
> > Stockner" <bf-cycles-bounces at blender.org on behalf of
> > lukas.stockner at freenet.de> wrote:
> >
> >>Hi!
> >>
> >>The Disney BRDF shader is actually pretty interesting for Cycles!
> >>I've played around with it for a while as well, but my code isn't
> >>fully working yet, so it'd be awesome to have your code around.
> >>
> >>Some notes:
> >>- There's actually a later revision of the paper you linked with a few
> >>more details, might be handy:
> >>https://disney-animation.s3.amazonaws.com/uploads/production/publicati
> >>on_asset/48/asset/s2012_pbs_disney_brdf_notes_v3.pdf
> >>- There's also a completely revised BSDF that includes actual
> >>subsurface scattering and transmission, and they note that it solves a
> >>few issues with energy conservation and path tracing in general that
> >>the original
> >>2012 BRDF has:
> >>http://blog.selfshadow.com/publications/s2015-shading-course/burley/s2
> >>015_pbs_disney_bsdf_notes.pdf
> >>- I'm currently working on energy-conserving microfacet closures,
> >>which would pretty much solve the issue that caused them to include
> >>the sheen stuff - at the cost of not being 100% compatible to other
> implementations.
> >>
> >>But that can all be handled later - in general, it would be awesome to
> >>have the Disney BRDF/BSDF in Cycles, and your code would certainly be
> >>welcome! Even if we go with the revised BSDF, it is pretty similar to
> >>the original BRDF, so it could be upgraded easily.
> >>
> >>Lukas
> >>
> >>
> >>Am 11.05.2016 um 15:57 schrieb "Pascal Schön":
> >>> Hey guys,
> >>>
> >>> For a few months now I’m implementing (on a private repository) the
> >>> Disney BRDF shader
> >>>
> >>> (https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_
> >>> brdf_notes_v2.pdf) as a new node in Cycles. By now there have only
> >>> been a few external approaches, where a render server (like in
> >>> Appleseed or Renderman) is accessed by a Blender plugin. But it
> >>> would be nice to get access to this without any additional software
> >>> to install.
> >>>
> >>> The current state of my implementation is, that the OSL closure is
> >>> finished and has also been tested against Renderman. Both acted the
> >>> same in my testcases (except for the rendering approches by the two
> >>> renderers, which cause some minor differences in indirect lighting).
> >>> Another step that I’ve taken was to implement the node to easily
> >>> access the Disney BRDF.
> >>>
> >>> Currently OSL has to be activated, because I haven’t done all steps
> >>> to include the Disney BRDF completely in Cycles. But I think that’s
> >>> only one small step to take. There I hope to get some help by the
> >>> community because it's a bit confusing where to add which code
> fragment.
> >>>
> >>> You can see some screenshots here:
> >>> https://www.dropbox.com/sh/j7w4v0bu9a5jhvz/AADSF3nm3LZCZnHgyPMwhrT6a
> >>> ?dl=0
> >>>
> >>> I would be pleased if you tell me if this would be nice to have or
> >>> if it is too special for Blender.
> >>>
> >>> Pascal
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> Bf-cycles mailing list
> >>> Bf-cycles at blender.org
> >>> https://lists.blender.org/mailman/listinfo/bf-cycles
> >>>
> >>
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> > _______________________________________________
> >
> > Bf-cycles mailing
> > listBf-cycles at blender.orghttps://lists.blender.org/mailman/listinfo/bf
> > -cycles
> >
> >
> > _______________________________________________ Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> > _______________________________________________ Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> >
> >
> >
> > --
> >
> > With best regards, Sergey Sharybin
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > https://lists.blender.org/mailman/listinfo/bf-cycles
> >
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>

-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160523/38ceb4e3/attachment.htm 