[Bf-cycles] Bf-cycles Digest, Vol 11, Issue 13

Thu Mar 29 13:32:12 CEST 2012

Hi Everyone

I would hate to see the material nodal workflow being changed, an extra
node with everything combined wouldn't affect me I guess.

I would disagree strongly about the comment of Cycles materials not being
"artist" friendly. I have worked extensively with Mental Ray and Vray and
have never had as good an experience as I have had with Cycles regarding
setting up of shaders(The realtime feedback of cycles gives it a huge
advantage of course). Cycles is by far the most intuitive system I have
dealt with. That being said, I do understand that you need to know exactly
what you need to set up a particular material. So a shader with everything
combined as an extra node might help new comers.

I feel that the power of the node setup lies within its simplicity. You add
what you need as opposed to having a massive rollout of 50 parameters
whether you use them or not. It makes things very confusing and messy.

Christophe perhaps you should consider using material presets. I can put
together a node setup for a few materials into a blend file if you want?
That way you can simply just append the groups to your scene and use the
nodes, I will replicate the Vray and Mental Ray style and name all the
inputs so it would be straight forward.

As a character artist I can't wait for SSS and Hair in cycles.

Thanks Brecht for the most amazing renderer I have ever used!!

Dewald Swanepoel
The Empty Room

Phone: +44 (0)74 2515 7105
Email: dewald at theemptyroom.co.uk
Skype:  the_empty_room

www.theemptyroom.co.uk

On Thu, Mar 29, 2012 at 11:00 AM, <bf-cycles-request at blender.org> wrote:

> Send Bf-cycles mailing list submissions to
>        bf-cycles at blender.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://lists.blender.org/mailman/listinfo/bf-cycles
> or, via email, send a message with subject or body 'help' to
>        bf-cycles-request at blender.org
>
> You can reach the person managing the list at
>        bf-cycles-owner at blender.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Bf-cycles digest..."
>
>
> Today's Topics:
>
>   1. A Single "Cycles" Shader (Christophe Leyder)
>   2. Re: A Single "Cycles" Shader (Agustin Benavidez)
>   3. Re: A Single "Cycles" Shader (Stuart Compton)
>   4. Procedure for adding a new node/shader type (Nikhilesh Sigatapu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 28 Mar 2012 23:05:01 +0200
> From: Christophe Leyder <shotalot at gmail.com>
> Subject: [Bf-cycles] A Single "Cycles" Shader
> To: bf-cycles at blender.org
> Message-ID:
>        <CAM2KXPG_JFgwE34eqXeduDZiap-iieXrtrCw53UOz2qn_f9kdQ at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hey Brecht,
>
> Im really loving how Cycles is coming along, but I have a slight concern
> about the direction the shading workflow is taking.
>
> Currently, in the materials tab, the shaders presented with Cycles feel
> very "technical" and un-artist friendly, let me explain why:
>
> "Glossy BSDF", "Transparent BSDF", "Transcusent BSDF", "Diffuse BSDF" to me
> as an artist should be parts of a shader, not individual shaders.
> To elaborate, from using a whole lot of other engines these past few years,
> the one thing they have in common is they have unification. Unfication in
> Blender in general is seriously lacking, and I would hate to see Cycles go
> even further down that road. My suggestion is:
>
> Have a "basic" shader with the current "shaders" combined, (I really dont
> know the maths and stuff behind this though). Rather have the current
> scattered system as inputs in the nodes system, because by all means, they
> WILL be usefull there, if someone wants to use them individually, they can
> plug them straight into the material output. To add, in my experience, a
> Mix shader shouldnt be a "shader" at all, rather a function in the node
> tree. eg. Changing the colour of a texture, or placing a decal on a shader;
> and of course what it does now, mixing shaders.
>
> Or to be even safer, just add the "basic" shader to the materials list
> thats already there, and leave the shaders that are there as is.
>
> Just my 2 cents from an artists standpoint! :)
>
> Thanks
>
>
> --
> *Christophe Leyder*
> *3D Artist\Animator*
> **
> www.luma.co.za
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-cycles/attachments/20120328/742a128e/attachment-0001.htm
>
> ------------------------------
>
> Message: 2
> Date: Wed, 28 Mar 2012 20:28:21 -0300
> From: Agustin Benavidez <agustinbenavidez at gmail.com>
> Subject: Re: [Bf-cycles] A Single "Cycles" Shader
> To: bf-cycles at blender.org
> Message-ID:
>        <CADibYME7PbWc_x_+v9E0aV+gehJxFfvkV_56ocZ29O08N7gTLA at mail.gmail.com
> >
> Content-Type: text/plain; charset="iso-8859-1"
>
> Christophe , You are right, simplicity, faster workflow, and
> powerful possibilities is what all tools are meant to be, and in my opinion
> Brecht with His design is going straight in that direction, the issue right
> now is that work is still in progress, with Cycles you got
> powerful possibilities and faster workflow, only left is more simplicity,
> and that is part of the final stage where all those modular
> and powerful tools can be group together in simple to use presets and group
> nodes. I think what is really lacking to fulfill your need is an Asset
> Manager, where you can save your custom nodes setup, presets, images,
> meshes , label at will and re use them easily, while at the same time
> maintain and extend the low level/flexible workflow .
>
> Cheers.
>
>
>
> 2012/3/28 Christophe Leyder <shotalot at gmail.com>
>
> > Hey Brecht,
> >
> > Im really loving how Cycles is coming along, but I have a slight concern
> > about the direction the shading workflow is taking.
> >
> > Currently, in the materials tab, the shaders presented with Cycles feel
> > very "technical" and un-artist friendly, let me explain why:
> >
> > "Glossy BSDF", "Transparent BSDF", "Transcusent BSDF", "Diffuse BSDF" to
> > me as an artist should be parts of a shader, not individual shaders.
> > To elaborate, from using a whole lot of other engines these past few
> > years, the one thing they have in common is they have unification.
> > Unfication in Blender in general is seriously lacking, and I would hate
> to
> > see Cycles go even further down that road. My suggestion is:
> >
> > Have a "basic" shader with the current "shaders" combined, (I really dont
> > know the maths and stuff behind this though). Rather have the current
> > scattered system as inputs in the nodes system, because by all means,
> they
> > WILL be usefull there, if someone wants to use them individually, they
> can
> > plug them straight into the material output. To add, in my experience, a
> > Mix shader shouldnt be a "shader" at all, rather a function in the node
> > tree. eg. Changing the colour of a texture, or placing a decal on a
> shader;
> > and of course what it does now, mixing shaders.
> >
> > Or to be even safer, just add the "basic" shader to the materials list
> > thats already there, and leave the shaders that are there as is.
> >
> > Just my 2 cents from an artists standpoint! :)
> >
> > Thanks
> >
> >
> > --
> > *Christophe Leyder*
> > *3D Artist\Animator*
> > **
> > www.luma.co.za
> >
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-cycles/attachments/20120328/b0a5c2be/attachment-0001.htm
>
> ------------------------------
>
> Message: 3
> Date: Wed, 28 Mar 2012 18:03:00 -0600
> From: Stuart Compton <wanbli at crazybull.com>
> Subject: Re: [Bf-cycles] A Single "Cycles" Shader
> To: bf-cycles at blender.org
> Message-ID: <02349DFA-4B0E-47FA-BC68-ECB3E86469A7 at crazybull.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Agustin, I agree with your statements on workflow, and I actually find the
> separate shaders much more useful than the many other structures I've run
> across in other packages.  I don't want simplicity, I want functionality.
>  I am also an artist and I find the potential power in Cycles unfolding
> structure quite encouraging...except: At a some point I seem to run across
> a limitation when reaching a certain level of complexity within a shader.
>  I have two files that have consistent crashes when rendered with cycles,
> but are fully serviceable when rendered with 'old' blender.
>
> I have hesitated to bring anything up before this point for the very
> reasons you've mentioned; Blender Cycles is a work in progress.
>
> However, if Cycles can not reach the level of complexity I have found as
> it's limit--and surpass it--the workflow you mention will not be possible,
> no matter how much I would like to work with it in that way.
>
> In the interest in helping with solutions, rather than only presenting
> problems, I offer the problem files if they are wanted.  Let me know if
> this is the proper place to post them, or send me a private e-mail and I
> will send them along.
>
> A few details to help determine if the files would be useful...
> I am a highly technical artist. Technical to the point that I code as
> well, although I have not learned Blender's code well enough to make a
> significant contribution, yet.  I use a Macbook Pro and I often use a
> custom built Blender.  I have a successful, compiling installation of the
> source and have used patches, most notably the Volumetric patches.
>
> The files in question have a very complex node structure and (almost)
> universally crash on the release 2.62 build and forward.  I've tried many
> builds since 2.62, whenever I see a checkin that might have some bearing.
>  I have managed to render the objects in the scene about four times, but
> only by restarting the application cold and immediately rendering the
> scene.  If I attempt any other work, it invariably crashes.  My system has
> 8 gb ram and a quad core processor ( I am not rendering on GPU for obvious
> reasons) so system resources should be fine.  I've monitored ram usage
> while beginning the render and have never topped out.
>
> I've never run it in a debugger--I don't know the code well enough to know
> what I'm looking for--but the drop to desktop seems to happen right at the
> moment the BVH finishes, but before I see evidence of a render.  My
> inexpert guess is a stack problem, but it does seem to be systemic and
> structural.
>
> I hope this is of some small help. If not, ignore this and go about your
> very useful business ;-)
>
> --
> Stuart Compton
> Head Cook, Frybread Software
> wanbli at crazybull.com
>
>
>
>
>
>
> On Mar 28, 2012, at 5:28 PM, Agustin Benavidez wrote:
>
> > Christophe , You are right, simplicity, faster workflow, and powerful
> possibilities is what all tools are meant to be, and in my opinion Brecht
> with His design is going straight in that direction, the issue right now is
> that work is still in progress, with Cycles you got powerful possibilities
> and faster workflow, only left is more simplicity, and that is part of the
> final stage where all those modular and powerful tools can be group
> together in simple to use presets and group nodes. I think what is really
> lacking to fulfill your need is an Asset Manager, where you can save your
> custom nodes setup, presets, images, meshes , label at will and re use them
> easily, while at the same time maintain and extend the low level/flexible
> workflow .
> >
> > Cheers.
> >
> >
> >
> > 2012/3/28 Christophe Leyder <shotalot at gmail.com>
> > Hey Brecht,
> >
> > Im really loving how Cycles is coming along, but I have a slight concern
> about the direction the shading workflow is taking.
> >
> > Currently, in the materials tab, the shaders presented with Cycles feel
> very "technical" and un-artist friendly, let me explain why:
> >
> > "Glossy BSDF", "Transparent BSDF", "Transcusent BSDF", "Diffuse BSDF" to
> me as an artist should be parts of a shader, not individual shaders.
> > To elaborate, from using a whole lot of other engines these past few
> years, the one thing they have in common is they have unification.
> Unfication in Blender in general is seriously lacking, and I would hate to
> see Cycles go even further down that road. My suggestion is:
> >
> > Have a "basic" shader with the current "shaders" combined, (I really
> dont know the maths and stuff behind this though). Rather have the current
> scattered system as inputs in the nodes system, because by all means, they
> WILL be usefull there, if someone wants to use them individually, they can
> plug them straight into the material output. To add, in my experience, a
> Mix shader shouldnt be a "shader" at all, rather a function in the node
> tree. eg. Changing the colour of a texture, or placing a decal on a shader;
> and of course what it does now, mixing shaders.
> >
> > Or to be even safer, just add the "basic" shader to the materials list
> thats already there, and leave the shaders that are there as is.
> >
> > Just my 2 cents from an artists standpoint! :)
> >
> > Thanks
> >
> >
> > --
> > Christophe Leyder
> > 3D Artist\Animator
> >
> > www.luma.co.za
> >
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
> >
> >
> > _______________________________________________
> > Bf-cycles mailing list
> > Bf-cycles at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-cycles
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.blender.org/pipermail/bf-cycles/attachments/20120328/24633376/attachment-0001.htm
>
> ------------------------------
>
> Message: 4
> Date: Wed, 28 Mar 2012 21:57:21 -0400
> From: Nikhilesh Sigatapu <s.nikhilesh at gmail.com>
> Subject: [Bf-cycles] Procedure for adding a new node/shader type
> To: bf-cycles at blender.org
> Message-ID: <4F73C181.9080305 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello!
>
> I've been studying the cycles code for a while recently, and find myself
> quite interested in it since it seems, to me, to be rather neat and well
> written for the most part. It also has a small codebase at this early
> stage, which makes the structure easier to understand.
>
> I was wondering about how one would go about adding a new node type to
> cycles, say, a subsurface scattering node type, to represent the
> interface to a new internal shader type. It seems that there are a bunch
> of flags across multiple source files.
>
> Does one simply have to add the new node type in render/nodes.{h,cpp},
> write the corresponding kernel shader function, add to the switch
> statement in svm_eval_nodes to handle the new type, and accumulate into
> the respective pass?
>
> --
> Nikhilesh S
> http://www.nikhilesh.info
>
>
> ------------------------------
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>
> End of Bf-cycles Digest, Vol 11, Issue 13
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20120329/9d5e68ca/attachment.htm 