The C4D material system is definetly one of the weakest points of C4D. We are not even able to load textures in all channels which is necessary for advanced shading (textures for reflection blurriness for example). Also referencing is not possible without plugins.
cmNodes Plugin Preview [C4D Node Material System]
Zendorf
#22
Not that I have ever used it, but they did add the Slate material editor a few years back:
http://www.youtube.com/watch?v=CLar6qhZKUY
The Octane C4D plugin dev is also working on a nodal system:
On a slightly related note, since Blenders’ Cycles renderer has recently changed to a more permissive license(Apache), an enterprising third party dev could actually port it over to C4D. It is a very sweet renderer somewhere between Arnold and Octane and can use the CPU or GPU. Theoretically Maxon themsleves could integrate it much like they did with Bullet dynamics or Intel’s Embree…I won’t hold my breath though…
AdamT
#23
Cool, I didn’t know about that.
The Octane C4D plugin dev is also working on a nodal system:
Nice! Looking forward to that.
NiklasR
#25
Maybe there’ll be a version to render scenes using the cmNodes plugin, but not edit it? Just a suggestions which I liked to throw in at this point. 
neitrok
#26
Or to be able to “Make Editable” the node materials - which means, they will be converted to a normal C4D material.
ilay
#27
Runtime mode like Cactus Dan’s plugins?
But for single render-client or render-farm/cloud(team-render)
JoelDubin
#28
Out of curiosity, besides the ability to reuse a single shader, bitmap or group to effect multiple channels (like the reference shader does) what would be the advantages of a nodal shader system? That ability in itself is a biggie of course, but anything else?
I’m well aware that node base systems are now the standard (maya, XSI, nuke to name a few) but just wondering what other benefits a texture tree, and one that is separate from the built in xpresso system, brings to the table.
And by the way–looks like you did great job Chris. --not meaning to challenge you in any way. Been a longtime fan (and customer!) of your tools. My questions here are posed purely out of ignorance of the pros and cons. Thanks
ThePriest
#29
Seems it would benefit those who use layers/fusions/blend channels.
I can’t see myself using this heavily, the current system is fine for most of what I do.
But also can’t deny there are certain procedural materials I’ve created that would have been much easier to manage, if they’d been visible in a tree view, vs trying to recall where they exist within a layer structure.
I suppose it depends on how deep you dig with materials, as nodes would let you dig much deeper.
chi
#30
Nodal is most important in procedural workflows, but in some case like vray, where you might want many maps to control the various parameters of a material this is super helpful.
Especially since you can source 1 bit map, throw in some color corrections for each channel, and boom.
Now the client wants a different texture, drop that in and everything updates automatically.
It’s a sweet deal.
I think a runtime version would be fine.
c-montesano
#31
This basically provides a new way to work with the native shading system. It’s not for editing existing materials. When you drop an existing material onto the node editor it will “explode” the material, but only one level deep.
I’ve been exploring the idea of a “baking” function which would try to collapse the tree into material channels (for a perfect match this would require shader versions of all of the nodes), or as mentioned, a “runtime only” version of the node system. I think the latter would be much easier, but would leave you with non-editable materials. So to answer your question, I’m still trying to work this out.
I had toyed with the idea of making this into a separate material system, providing nodes for various illumination models which would open up plenty of room for layered specs and such. That may still happen at some point, but no concrete plans.
The nodes work through a special channel shader that points to a branch in the node tree, so you can use the node system anywhere that you can use a standard shader including Vray and Hair materials. I don’t believe the Sketch material has any shader inputs, so that will not work.
Other than reusability I think visibility is an advantage. I think the reference shader is awesome and went a long way in giving C4D’s material system some of that reusability. But I feel I get a better picture of what my data is doing when I can see how it’s all connected. It all boils down to personal preference.
dirtyharry
#32
for me the main question is, does it work with or in xpresso?
if anyone else did ask before, sorry i didnt read the hole thread
an integration within xpresso would be the most wanted thing i guess,
so you can drive materials depending on objects or collisions and so on.
but looks nice anyway, congrats
LucentDreams
#33
Your already can with our existing material system, so I imagine this should be able to. if you mean xpresso nodes right inside it’s nodal interface then I’d wager no probably not.
Zendorf
#36
Thanks for the feedback Chris. Looking forward to trying it out, especially nodes with the forthcoming Vray 1.8 will be a powerful combo 
LukeLetellier
#37
Here’s the Vray preview:
http://www.youtube.com/watch?v=Uxg9g41gjt0
Takes a little bit of time to set up; looking forward to drag and drop support.
ChrisCousins
#38
Been away for a week, and when I get back I find that my numero uno feature request has been answered. Made a point of asking every release since v7, it’s been a while. Awesome news, workflow looks great, this is exactly how I want to make materials. I’m all the way in 
jHofmann
#40
because then they would really have a feature for a new release. I still don´t get it why 3rd party developers (sometimes it is only one person) accomplish such great plugins as xparticles now as it seems cmnodes.
Don´t know why Maxon doesn´t buy it, like tp and many more before… MSA gives financial stability and a lot of promises were made with it´s introduction…
my 1,5 cent
j