1
$\begingroup$

I have a type of PropertyGroup that stores some settings. My goal is to have a master collection full of instances of this group stored with the scene, and a list of slots that can be filled with these instances on each material. (Basically replicating Blender's material system but instead of slots for material on objects, it's slots for these instances on materials)

My current issue is that I can't figure out how to properly reference this data in the slots. Here's what I've tried so far:

  • Storing the instances directly through PointerProperties. This seems like the obvious solution, but since PointerProperties for custom types can't be re-assigned, you can't reference an item from the master collection in a slot.
  • Storing "references" to the items through StringProperties with their names. The items have unique names, so that's not an issue. However, problems arise when renaming, since the item in the master collection and all slots referencing it must have their strings changed. I tried using the getter/setter feature of properties to achieve this synchronization, but encountered lots of strange issues in the process. I think the reason is the threading issue described here, since I'm modifying data from materials (which hold the slots) and the scene (which holds the master list), which are from separate data blocks.

I found this question that has a similar end goal, but it doesn't really address this issue. Is there a known way to do this, or any other project that does something similar?

$\endgroup$
3
  • 1
    $\begingroup$ What is this for? What kind of settings do these properties store and why? What is it that you are trying to make? $\endgroup$ Nov 30, 2022 at 22:51
  • $\begingroup$ The addon overall is for editing an obscure model format. There are several things I'd want to use this for, one example being textures: for this format, there are images (which have image data) and textures (which have images w/ some other settings, like wrapping), and I want both to be reusable (so you could have an image in multiple textures, and a texture in multiple materials). I use regular Images for the images, but I need something else for the textures, and a PropertyGroup containing the image & the other settings seems like the ideal solution to me. $\endgroup$
    – hayden0729
    Nov 30, 2022 at 23:25
  • $\begingroup$ If this is for materials, seems like material node tree is the perfect place to store stuff... Node groups can be reusable. Why not use the functionality that is already there?.. $\endgroup$ Dec 1, 2022 at 6:15

1 Answer 1

1
$\begingroup$

Solved this by storing the references as integer indices into the master list. Much less of a hassle than the string thing I was trying to get working, since the indices only change when certain operators are used (so it's easy to update them in the operators rather than in a setter with limited scope).

Edit: This turned out to have some flaws. Final solution that's working great now is a UUID system, as suggested below, where items are given unique identifiers on initialization.

$\endgroup$
1
  • $\begingroup$ I think either integer or string property is fine, just don't use it to point to something that is ever going to change. Using the name is obviously bad but you can use for example a dynamically generated guid instead of an integer. Integers have an upper size limit, strings don't. Another benefit of using guid is you don't have to keep a global integer variable somewhere to keep track of how many items you have generated. $\endgroup$
    – Gorgious
    Dec 1, 2022 at 12:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .