Imported material node group IDs

[ifIMust]

When I import a CC4 character (with all logging enabled in the addon preferences), messages like this are logged:

   Processing Material: casual0_Hair_Transparency.003
      Creating new shader group: cc3iid_(rl_hair_shader)_v1.5.1_1083
      Creating new BSDF: cc3iid_(rl_hair_shader_BSDF)_v1.5.1_1084

If I save the imported character as a .blend file, the "cc3iid_(rl_hair_shader)_v1.5.1_1083" string is present in the file. I don't know where to find this data block in the editor, though.

In the Outliner->Blender File view, I see one node group for each shader type. The hair one is called cc3iid_(rl_hair_shader)_v1.5.1_1076. In the Shader Editor, all the hair materials refer to _1076 in the Hair Shader node. But, the _1076 node group wasn't mentioned by the import logging.

The character renders correctly after import, so the materials seem to be fine.
What I'm hoping to learn is why the logged output and the resulting shader node group identifiers don't seem to line up. The results are the same with material dedup on or off.

My end goal is import a CC4 character, then later export the scene using the Godot Engine Exporter addon (https://github.com/godotengine/godot-blender-exporter).
When I try to export the character as a .escn file using that addon, the exporter complains about all the materials, and they don't export correctly:

[INFO]: Exporting Blender object: casual0_Bang
[WARNING]: input node 'cc3iid_(rl_hair_shader)_v1.5.1_1083' not supported,use default value for socket 'Base Color'
[WARNING]: input node 'cc3iid_(rl_hair_shader)_v1.5.1_1083' not supported,use default value for socket 'Subsurface'
[WARNING]: input node 'cc3iid_(rl_hair_shader)_v1.5.1_1083' not supported,use default value for socket 'Subsurface Color'
[WARNING]: input node 'cc3iid_(rl_hair_shader)_v1.5.1_1083' not supported,use default value for socket 'Metallic'
[WARNING]: input node 'cc3iid_(rl_hair_shader)_v1.5.1_1083' not supported,use default value for socket 'Specular'

etc.

This might be a limitation of that exporter, but I can't find the mentioned nodes, either. The "not supported" nodes correspond to the node groups that I can't locate in the editor; but were mentioned in the CC import logging. I'm a newbie when it comes to Blender, so maybe I just don't see where the data ended up.

Meanwhile, the _1076 node group that is shown in the Shader Editor was not mentioned by any logging from either import or export process.

[soupday]

cc3iid_(rl_hair_shader)_v1.5.1_1083 is the name of the node itself not the name of the node group.

A node group node is two things: the Green coloured material shader node you see in the editor which is itself just a container reference to a node tree, which is listed under Node Groups in the outliner, just to confuse us.

So the name of the node group is node tree name.

So for a node group node in the material node tree:

group_node.name == "cc3iid_(rl_hair_shader)_v1.5.1_1083"
group_node.node_tree.name == "cc3iid_rl_hair_shader_v1.5.1_1076"

Everything the add-one generates is prefixed and suffixed like this with a unique number id, so I can identify the things that it creates and not mess with the things that it doesn't.

But, I don't think that's going to help you much. I've taken a look at the Godot-blender-exporter code to see what it's trying to do and the node inputs are way to complex for the exporter to understand. It's basically just looking for simple textures and/or normal & bump map nodes to build it's shaders.

But this is a common problem with exporting from Blender, all the exporters expect much simpler material structures, which is why I made the baking tool add-on: https://github.com/soupday/cc_blender_bake

Which basically flattens all the materials into simple texture sets for the exporters to understand.

I've updated it with a Godot engine target, which should be compatible with the Godot-blender-exporter.

Note: it's a bit slow to bake everything and can take 5 minutes or more to completely bake a character. (Watch the system console to see what it's doing.)

I'd be interested to know if it works. I know some people have used it to export characters to node.js using GLTF target bake (which may also work for Godot).

[ifIMust]

Thanks for the quick turnaround on answering my questions, and updating the baker!
I was not yet aware of your CC baking tool. This is awesome, and sure cuts down on the export issues dramatically.

Baked model in Blender:

Baking to a Godot target, and then using Godot escn export, works. A few of the shaders did not come out right on the Godot side (some facial details):

Baking the same character to a Godot target, then using gltf export gave me a good appearance in Godot with no ugly anomalies.
I also tried a gltf bake and gltf export to Godot, and looked the same as the [Godot bake, gltf export], when imported to Godot.

Some details are missing in the Godot render, such as the vertical ribs on the sweater.
I don't know which material properties hold the missing details, but the remaining work might be downstream from your tools, or limitations of the Godot import.

I'm happy, because even with some details missing, there exists a workflow for CC4 -> Blender (retarget animations) -> Godot.
Thank you very much for sharing these addons!

[soupday]

Looks to me like the godot-blender-exporter isn't taking the transparency settings into account.

The vertical ribs on the sweater made by the normal maps, however that scene in the Godot engine looks like it's entirely lit by ambient light. Normals will only show up under direct lighting (directional, point, spot or area lights) so it's probably good to go.

Edit: The GLTF export is probably better because it also handles the ambient occlusion maps. The godot blender exporter doesn't.

[ifIMust]

That was my issue. I had to add a light, and also do a full render (play the scene) to see the full effect.

I will stick to GLTF export for this use case. This is a very faithful reproduction in Godot, so I'm thrilled. Thanks again!