Blender 5.0 breaks the `generate` function in MCprep

[StandingPadAnimations]

Did the issue happen after restarting Blender?

• Yes, the issue indeed continued after restarting Blender

Check known issues

• I have checked known issues, and my problem is different

What happened?

In Blender 5.0, when spawning rigs or blocks, or prepping materials, the following errors are thrown

• Block spawning:

File "/home/mahid/.config/blender/5.0/scripts/addons/MCprep_addon/materials/generate.py", line 1221, in generate_base_material
    node_diff["MCPREP_diffuse"] = True
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^
TypeError: bpy_struct[key] = val: id properties not supported for this type

• Rig spawning (though the spawner seems to be able to gracefully handle this):

File "/home/mahid/.config/blender/5.0/scripts/addons/MCprep_addon/materials/generate.py", line 564, in get_textures
    elif "MCPREP_diffuse" in node:
         ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: bpy_struct: this type doesn't support IDProperties

• Prep materials:

File "/home/mahid/.config/blender/5.0/scripts/addons/MCprep_addon/materials/generate.py", line 564, in get_textures
    elif "MCPREP_diffuse" in node:
         ^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: bpy_struct: this type doesn't support IDProperties

This is due to a recent change in Blender in how properties can be accessed. To quote the release notes

Removal of (Unsuported) Access to Runtime-Defined Properties Storage Data¶

Properties defined by the bpy.props API are no longer stored in the same container as user-defined Custom Properties. As a consequence, it is no more possible to access them directly through the Python 'dict-like' syntax.

E.g. bpy.context.scene['cycles'] will not give access to Cycles' scene settings.

Based on what I can tell in the accompanying issue thread, the new changes in Blender 5.0 massively restrict what addons can modify at runtime. I've yet to do a deep dive on how this impacts us specifically, but we should be expecting some massive refactoring at the very least.

What steps are needed to produce the bug?

1. Run Blender 5.0
2. Use either the block spawner, rig spawner, or prep materials functions

What version of MCprep are you using?

3.7-MB-3, which is everything currently on the dev branch (though I would assume this impacts the latest stable release)

What version of Blender are you using?

Blender 5.0

[StandingPadAnimations]

So it looks like we can't assign custom properties to nodes anymore, which generate uses to distinguish between different image nodes for textures...

EDIT: and even if we do find a workaround, handling older node trees generated by prep materials is going to be a pain in 5.0

[zNightlord]

So far the only thing I can look forward to is moving those node_diff["MCPREP_diffuse"] to "system properties" registering bpy.types.ShaderNodeTexImage.MCPREP_diffuse = bpy.props.BoolProperty() and use node_diff.MCPREP_diffuse instead. since that works with 5.0 and also earlier versions.

[TheDuckCow]

The other option here I guess is just directly renaming the node or display name to the value we need. Though if what @zNightlord suggests works and is backwards compatible down to 2.83 then yeah, that seems like a better solution. If it's not possible in 2.8x, then it would be good to know what the next minimum support level is so we can decide the tradeoff of support levels.

[StandingPadAnimations]

Alternatively we could also write some wrapper functions that use both the old method and zNight's suggestion, based on the Blender version.

Assuming Blender 5.0 doesn't erase the properties in older files, it could also be used to handle backwards compatibility with files made pre-5.0

[TheDuckCow]

I like the idea of falling back to reading the old way, but not necessarily a fan of 'writing' both ways, as it just makes the codebase more expensive over time.

So, if either of you end up getting a snippet to work in Blender 5.x, I'd be happy to check the lower versioncompatibility levels.

[StandingPadAnimations]

Ok so looking further, while zNight's suggestion works, the main issue is it adds a property to system properties, which, as far as I can tell (correct me if I'm wrong), while not read-only yet will become read-only in the future (see below comment from 123232)

System defined data will then be only accessible through a dedicated path, instead of being directly subscriptable from the IDProperty owner. They will also be read-only by default

I'm also currently inspecting node attributes, and so far, we can use node.items() for backwards compatibility (for the MCPREP_* props, but also the SATURATE prop). But it doesn't look like we can set properties easily anymore

[StandingPadAnimations]

@snzhongcheng on the MCprep server noted a possible workaround (haven't had the chance to test it, but it looks like it should work). Essentially, the idea would be to create a property group:

class MCPREP_node_props(bpy.types.PropertyGroup):
	texture_type: bpy.props.EnumProperty(
		name="Texture Type",
		items=[
			("Diffuse", "diffuse", ""),
			("Specular", "specular", ""),
			("Normal", "normal", "")
		]
	)

And then when registering, assign them to bpy.types.Node:

def register():
	bpy.utils.register_class(MCPREP_node_props)
	bpy.types.Node.MCPREP_node_props = PointerProperty(type=MCPREP_node_props)
def unregister():
	del bpy.types.Node.MCPREP_node_props
	bpy.utils.unregister_class(MCPREP_node_props)

Then from there use it as normal:

node.MCPREP_node_props.texture_type = "diffuse" 

(Code example modified a little for our use case)

I would have to do some further checking and see if it A. works and B. wouldn't be impacted by read-only properties in the future (I think it won't, since we're adding properties through the API in a normal fashion, but it does feel weird), but from the looks of it, this suggestion would be a good solution to our issue.

[zNightlord]

Yeah it's the same as what I suggested but store under PropertyGroup, nicely ogranized.
On that using bpy.types.Node doesn't make sense for me unless you want to store it on every Blender nodes (since it's parent of ShaderNode, CompositorNode, ...) ShaderNodeTexImage limits down to only Shader Image Texture

*edit: beside doing on the Node to make it like the old way, I guess if you want to take it new different direction of storing this you can also store that on the Material or ShaderNodeTree.