Material Editor: Add Procedural Textures (Blender "Shells")

[GeneralProtectionFault]

I’m not sure people would find this useful or “good enough,” but I tried making a procedural dirt texture that could be added to skin:

The attached python file is the result of using the NodeToPython addon (delightfully useful to get a quick script of a geo/material node setup). This won’t be separated into the class structure the addon uses, but it should quickly reproduce the material.

Basically, it uses a mix shader with the Fac coming from a primary noise texture, in order to overlay onto the skin without affecting it.

The python script will reproduce the Procedural Dirt Shader here (the strength values are just bump strengths). It just takes in whatever the output was on the skin material, mix shader again to adjust overall influence. I’m not sure (without doing some research ) how to get the current/a specific material and grab that output and shoe-horn this in, but before I try that, I wanted to see if there’s interest in it.

Since we already have the material editor (and in this sort of case, the ability to select the skin materials), I thought it might be useful if we could add procedural materials like this as an option--such that you’d have a new menu section with a button for materials like this one, which could be added as shown in these last few nodes to the selected materials.

If it can be done procedurally, maybe some other stuff like blood could be added to this section (I’m confident there might be other folks more talented than me at creating these, but once we have a good setup, it could be applied/tweaked)

Anyhoo, if the juice isn’t worth the squeeze, no worries, but throwing the idea into the pot.

[Alessandro Padovani]

Of course blender already gets a set of procedural textures, I’m not sure what this one would add. Anyway I don’t think it is the purpose of the importer to expand the blender shaders, unless it is needed to import something.

‌

[GeneralProtectionFault]

Sure, but those are just generic. What I mean is pre-defined procedural textures that are specifically relevant to people/skin. The dirt shader I included via that python file is an example. I don’t think any of the out-of-the-box shaders would be of any use on figures, but if we can create some pre-defined material node setups, then one would not have to be a material expert to add some such common things to the figure (or not need to find a DAZ asset or deal with the headache of multiple geo shells, etc…).

And it might be that they wouldn’t measure up, I don’t consider myself an expert.

If it’s beyond the scope of what you & Thomas are interested in for the addon, that’s fine, like I said, just an idea. However, I think it would definitely add more than Blender’s vanilla procedural textures.

[GeneralProtectionFault]

Thought about this a bit. My basic intent is to find a way to use something like this and have it be community-based, like people could contribute node setups that essentially result in the ability to be like click “Add Blood” or click “Add Dirt”.

I didn’t realize that we can now actually save node groups as an asset as of 3.3-ish or so. A little annoying that it doesn’t save the name/color, but obviously minor. There’s also the Node Preset addon which I haven’t tried yet but looks similarly useful.

So, this might not be worth the effort for the addon, totally understand that. For me, personally, the only additional benefit of incorporating into the Material Editor (beyond saving my asset in the library) would be the ability to quickly add it to all the selected (in this case, skin) materials.

However, if me or someone much more talented than me creates something like this, it’s not available to everyone. If it’s generated in the Python, that enables the sharing, although at the cost of some flexibility and increased maintenance lift.

One thought I had was if uploading to BlenderKit, but that would be entire materials, and we wouldn’t want to actually replace the skin material, but add this node group to it.

Anyhoo, just food for thought. Might be a nothing burger, but in case someone has better knowledge than me how something like that might work.

If there’s nothing to be gained directly in the addon, what I might do is see if I can get some footing on the Diffeo Discord server where .blend files w/ node groups like that could be shared.

(Side note, it might be a cool idea if the blog/home page had a permanent invite link to the Discord server. Currently, there doesn’t seem to be any very natural way to know it exists)

[Thomas Larsson]

This is an interesting idea, but the DAZ Importer is not the right place for it. This plugin has already grown to be too large and unwieldy, and therefore I decided to move periferal tools to separate addons, see https://diffeomorphic.blogspot.com/2024/02/add-on-split.html. In particular, the Shell editor contains a set of tools that are probably only used by myself. That would be the right place for such a tool.

The implementation could be quite simple. It is the user’s responsibility to get the node group into the Blender database. The addon could then convert the nodegroup to a shell nodegroup and add it to selected materials.

‌

[Thomas Larsson]

This was quite fun to implement. It is added to the Shell Editor addon and works like this.

Create the node group by running your script. I changed the name of the node group to “Procedural Dirt” and added the lineimport bpy at the beginning.

‌

Select the mesh and Add Custom Shell.

‌

In the dialog, select the node group at the top and select the materials .

‌

At the end of each node tree, a shell node group is created. It has the same sockets as every other shell node. Depending on the settings of the global Shell Driver Type setting, a driver may be added for the influence.

[Thomas Larsson]

The shell node group consists of the node group created by the script and a node that mixes the output with the original shader according to Influence. The only requirement is that the first input and first output are the ingoing and outgoing shader. If you want to tweak the node parameters, you can do it here and all materials are changed. The UV and Displacement sockets could also be used.

‌

We can now change the shell influence in the Visibility > Shells panel as usual.

[GeneralProtectionFault]

Awesome, thanks Thomas. Couple of points:

Could we add a check if the shell already exists? Currently, if you add it more than once or, presumably, to a 2nd figure, it creates duplicates.

Other than that, totally agree it makes sense here. I’ve looked at the shell editor but didn’t fully grasp the workflow. This is probably partly because I’ve only done a little bit w/ shells in DAZ as well.

Where do we find that menu in your final screenshot? I tried importing a figure and added the custom shell successfully, but I don’t see where those sliders/drivers are. I do see the Shells menu in the Runtime tab under Visibility, but if I expand it there’s nothing in it (I’m not sure if, perhaps, this is because I didn’t already have other shells in there).

Anyhoo, another side note: Looks like assets for the “User” library are stored in a blend file if the path is configured in Blender’s options. This is a little annoying because we have to strip out all the unnecessary stuff from the file or it gets really messy. However, those blend files can be shared once people understand that (in my case, I saved the node group as an asset--have to drag into the scene once to be recognized, no biggie).

[Thomas Larsson]

Duplicates are avoided in the last commit. Moreover, if the node group is already a shell group, i.e. it has the same input and output sockets as a shell group, the group is added directly and no wrapper group is created. You need to update both the import_daz and shell_edit addons.

To create drivers the global setting Shell driver type must not be None. I prefer to use rig properties to drive the influence, because using mesh object properties doesn’t seem to work with file linking, but armature object properties do.

‌

[Thomas Larsson]

On second thought, I think that it is better to create duplicates. We may want to use the same Blender shell for several characters, but with different parameters. Currently, if we tweak the parameters of the internal node group for one character, the other is also changed. We could make a single copy of the shell node group in the second character, but then we would have to change the node group in all its materials manually. The cost of this change is also very small, because we are talking about duplicating the wrapper node group which only consists of two nodes (plus input and output).

In practice this doesn’t really matter, at least not with my own workflow. I make each character in a separate blend file which I then link or append into scene files, so there are no second character which could use the node group.

[GeneralProtectionFault]

I see what you mean, yeah. I don’t see any issue with that. I think the other change you made so that if it’s already a shell, it adds that in and doesn’t create another--that solves the “issue” I was originally thinking of--which is if we want to play around and remove/add the shell a few times, it does not obligate us to create dupes. If you put back the “duplication”/unrestricted creation, then we can create as many copies as we wish, but if we select the shell, we can select a “linked” shell if that’s what we want

‌

[GeneralProtectionFault]

Ack--crap, forgot to mention. One thing I noticed is that if we use the Remove Shell button on one of these, it removes the node group in question, but it does not remove the Base/UDIM that was added to the UV input. I can understand that might be an irritation, like you might need to add some naming convention to that node in order to know it’s not one of the original textures if removing it. Not a big problem, but FYI.

[Thomas Larsson]

Duplicates are back in the last commit. The Remove Shells tool now optionally (default enabled) beautifies the node tree after removing shells, which gets rid of the unused uvmap node. Note that you need to update the import_daz plugin as well, because I added a new keyword to the pruneNodeTree function.

[Thomas Larsson]

The beautification step has been removed again, because it caused problems for Load Shells as Images (this tool adds the shell textures to the material textures instead of adding them as a separate node group at the end. In some cases this works better IMO.) The problem is that the uvmap node is the only information about which uv map that the shell uses, and if the node tree is pruned after shells are removed, this information is lost.