1
$\begingroup$

I was trying to access attributes from objects outside of the node graph but I'm having some problems and I don't know if it's meant to work like that or not.

I have two different node systems. The first one is responsible to write custom attributes for each object on the scene, specifying if they're from group A, B, or both.

enter image description here

The second system instantiates these objects and reads the group they are in or not. But, I can only read these attributes when I import the objects individually as an object or when I realize the collection (and then I can access these attributes at the point domain).

enter image description here

But why can't I read these attributes directly from the collection node?

enter image description here

After trying some things, I discovered that when I transform a geometry (which is already an instance) again into an instance, the attributes are gone.

enter image description here

But, when I realize that instance, the attributes come back at the point domain. So, I guess what is stopping me from getting the attributes directly from the collection info node is that the collection node is acting like a "geometry to instances" node, turning my objects (which are already instances) into instances again. enter image description here

Is it possible to access these attributes directly from a collection node? Is it a bug? What do you guys think?

File:

Thanks!

$\endgroup$

2 Answers 2

1
$\begingroup$

at a first glance everything looks to be working as expected.

The reson you can't access the attributes is because they are on the instance domain, so it can't reach it.

When you convert instances to an instance you loss the attributes because an instance has a single attribute and doesn't have sub domains like a mesh dose, so when you combine multiple instances you don't retain it the same way an instance doesn't retain (/access) the point of faces attributes.

The Way to keep it is either to realize them (and/or transfer them back to the instances), or convert them to instances within each object then stored the attributes on the instances domain. Then when you use collection info you should still have the attributes on the instance domain.

Edit:
If that is the case use a setup like this: enter image description here What this dose is transfers back the attributes from the realized instances.

$\endgroup$
1
  • $\begingroup$ Agree, but this last option doesn't seem to work. Even if I convert each object to instances, then store the attribute in the instance domain, I can't access the attributes again when importing the objects through collection info. I updated the post with a file example $\endgroup$ Commented Apr 20, 2023 at 20:39
0
$\begingroup$

To explain what shmuel's node setup does, the important observation is that when you realize an instance, its attributes get assigned to vertices/faces/etc. If we can map instances to verts, we can copy those attributes over.

The part in the frame captures the instance index before realization, and then deletes all except the first vert for each instance (for the Delete Geometry node, 0 maps to False, anything else to True). The result is a vert for each instance, in the same order as our collection children.

Here's a slightly more self-explanatory image: Node setup

And here's how you'd need to do it if you want to include mixed curves and meshes: Node setup

Note that if you have subcollections, those will be treated as a single instance and get the same value. And if you want to access something other than integers, you need to copy the whole node setup and change it.

FWIW I do this is a bug, and wish Blender offered more control over instance realization and collection iteration.

$\endgroup$

You must log in to answer this question.

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