Page MenuHome

Cycles: quick hacky system for cycles shader node group presets
Needs RevisionPublic

Authored by Brecht Van Lommel (brecht) on Apr 20 2014, 3:23 PM.


Sergey Sharybin (sergey)
Group Reviewers


We need to make it easier to set up basic materials. The ubershader is one
option, but now I actually think that's not ideal. I rather have a system
where we have a number of node group presets bundled with Blender, with maybe
a dozen shader groups for typical cases.

These could be for example:

  • Basis Surface
  • Basic volume
  • Hair
  • Fur
  • Glass
  • Metal
  • Cloth
  • Skin
  • Smoke & Fire
  • ...

Some advantages are that we do not need to build these into Cycles itself and
can more rapidly do improvements without worrying about backwards compatibility,
as the node group would be copied in existing files. Users can then also break
open the node group and make their own changes. For a production like Gooseberry
per project presets could perhaps be defined with more tricks or specific
features. And from a development point of view, it's nice that users could
contribute to these presets without writing code.

We could still benefit from UI improvements to group node sockets for example,
but I think now that such a group system is the way to go.


So here is a very basic, hacky patch that adds a system like this through a
Python script. In the node editor you Add menu it adds a Preset category, with
two node groups that are scripts/presets/cycles_shaders/basic.blend.

The .blend file is compressed with this script to make it small:

Bigger Picture

However, we need to think about how this fits into the bigger picture too. There
is already a Python preset system (though that works with python scripts rather
than datablocks in .blend files). There is also the asset management system
planned that may well provide the same functionality eventually, at least I
think it would eventually have a similar convenient way to add a datablock
without opening a file browser). So how does this fit?

Still, it might be good to have a short term solution here for Cycles, as I
think this would increase usability a lot, and if it's just Python code then it
may not be so bad to have this? It could perhaps even be part of the Cycles
addon, especially if we move the material properties node link menu into Python
code as well.

Diff Detail


Event Timeline

(To be clear, I posted this here to get some feedback about the idea, not asking for a real code review).

Maybe simple add "Online Material Library" to standart plugins?

Brecht: I agree with your proposal, a set of Node Groups for the common use cases sounds good.

As for the long-term plan, when we do it with Python and a blend as you suggest now, nothing to lose and we can do something more sophisticated later still.

Sounds good to me!

I'd suggest we make the default shader a 'Basic Surface' group instance. This way people unfamiliar with cycles can make some simple materials and then if they look inside the group they'll have a nice introduction to how to make their own shader network.

I don't really think this would fit nicely into the existing Preset system - that's more suited to changing values and such, not creating and replacing whole node networks. Handling what nodes need to be reconnected where when you change the preset would be a nightmare, especially when someone has made their own presets.

Sergey Sharybin (sergey) requested changes to this revision.Dec 3 2014, 6:51 PM

Well, nice idea but i'd be a bore here and say it needs more generic approach.. Not as the work is wrong, just needs more work, so technically it's "Changes Required":)

This revision now requires changes to proceed.Dec 3 2014, 6:51 PM