KeyError for ColorEffect

[Azzy Limmons]

line 781, in buildColorEffect
effnode.inputs["Tint"].default_value[0:3] = tint
~~~~~~^^^^^^^^
KeyError: 'bpy_prop_collection[key]: key "Tint" not found'
Location: H:\3D\Blender\_BUILDS\Blender 4.2 K-Cycles\4.2\scripts\modules\bpy\ops.py:109

This is in version 4.2.0.2252.

Both the import_daz and the DAZ Export to Blender script are updated. This is preventing me from importing the character.

[Azzy Limmons]

I should mention here are my settings:

‌

[Azzy Limmons]

Looking at the “DAZ Color Effect” created in Blender after it failed, it does seem indeed there is no such input as “Tint” in the node. Only “Fac” and “Color”.

[Alessandro Padovani]

The addon doesn’t support k-cycles. Does it work with the standard blender distribution ?

p.s. Also please provide a test scene as simple as possible. See #2129.

[Azzy Limmons]

I have debugged the issue.

If the DAZ Color Effect node already exists in the Blender scene data that was generated from an older version without the Tint, the new version of that node group is not created.

The situation happened because I tried to import a new character into a scene of a character I imported a few months ago.

A more stable implementation could ensure that if new material manipulation code requires the latest version of every type of custom DAZ node group, that those new node groups must actually be created and prioritized over re-using old ones.

Either that, or users should be warned with an error if the groups already exist and encourage them to try again in a blank Blender scene.

[Azzy Limmons]

It can be easily reproduced by importing a character with the new add-on, manually deleting the “Tint” from the DAZ Color Effect node group that is created, and then attempting to import a new character.

[Alessandro Padovani]

The daz color effect without the tint input is ancient history, I recall it from the first tests we did with it. I’m not even sure it is in a stable version probably not. Tested 1.7.1 and it comes with the tint input. However I understand there’s a name clash with a previous version.

I’m opening the issue for Thomas to be aware but this looks like a unique case probably not worth to fix.

[Azzy Limmons]

I skimmed the code, and this is not a unique bug; it is a systemic issue with node group creation.

All node groups are created through an abstracted interface using class inheritance, and the Daz Color Effect does not have any unique interactions with the Blender API.

So the issue is really that node group creation interface in general does not handle name collision, and this can cause bugs in perpetuity anytime you change the I/O dictionary of any nodes going forward if the old nodes are present in the scene when the importer is run.

I’m not sure what you mean by “ancient history”. I’ve only been using Diffeomorphic builds for less than 2 years.

[Alessandro Padovani]

I suppose in general the name clashes are meant to be avoided with the “daz“ prefix, of course there can be clashes if others use the same names. That the code doesn’t handle name clashes is something Thomas may want to look at. But in this case you probably used a non stable version with the daz color effect still in development that’s what I mean for “unique case”.

p.s. Checked 1.6.2 it comes with two groups “daz color effect“ without tint and “daz tinted effect“ with tint. So that’s probably what you used, and what I mean for “ancient history“, anyway it’s a stable version.

[Midnight Arrow]

Might be solved by #2187, since wrapping essential properties inside a PropertyGroup is by far the best way to avoid name clashes. Node groups are datablocks, so they can have a single PropertyGroup attached to them containing all relevant information (such as versioning).

[Azzy Limmons]

I understand Alessandro, understand the use-case that triggers bugs “of this nature” (not just “DAZ Color Effect”) is if you import a character into a much older scene that may have had a much older version of Diffemorphic used in it.

Of course it can always be avoided if characters are always loaded into default Blender startup scenes, but users may not understand that is an immediate solution if all they see is a python error.

I have had many random errors in the past year importing characters with Diffeo that, now that I think about it, can be explained by me attempting to import characters into scenes where the daz importer was already used in the past.

[Thomas Larsson]

Fixed in last commit. The plugin used to check the socket names of the node group in the database, and create a new group if there was a mismatch. However, this functionality was disabled in Blender 4, after group inputs and outputs were replaced with a separate group interface data type which is accessed differently. Now socket checking is back. If you load a new character into a scene where the Daz Color Group is already defined, a new node group is created and the old one is renamed.

[Alessandro Padovani]

It is worth noting that this bug seems limited to blender 4. That is, blender 3 works fine and it automatically renames to .001 as expected.

steps:

1. use blender 2.9 with importer 1.6.1 to import a figure and save the scene.
2. load the scene in blender 3 then import another figure with importer 4.2.1, the old groups are renamed to .001 as expected
3. load the scene in blender 4 then import another figure with importer 4.2.1, there’s a crash as reported by Azzy

note. bad name. The last dfbf5d8 commit fixes it, but it renames to .000 rather than .001 as per blender standard. This is minor let us know if you want to fix or we can close as resolved.

p.s. Since blender 3 works fine this may also be a blender 4 bug, which the last commit works around.

‌

[Azzy Limmons]

I think the name of the node is unimportant so long the add-on is able to import characters without cancelling with an error.

[Thomas Larsson]

I changed the extension of the old group to .001, but it becomes .002 because the new group was still named .001. But as Azzy says this is not important. What matters is that the name of the new group doesn’t have an extension, so the plugin can find it when it makes other materials later.