[Bf-cycles] A Single "Cycles" Shader

Stuart Compton wanbli at crazybull.com
Thu Mar 29 02:03:00 CEST 2012


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.htm 


More information about the Bf-cycles mailing list