Great! What does the index accepting a field mean in this case? Can you create temporary collections dynamically?

In D14049#374168, @Tomas (Rusculleda) wrote:

Great! What does the index accepting a field mean in this case? Can you create temporary collections dynamically?

It seems to be a leftover from the original code, I should probably make it a regular integer instead

While I can see that this node can be useful, I'll probably not allow it without further consideration.
Having nodes that allow us to get one data block (ID internally) based on another might make dependency tracking significantly harder if not even impossible. Maybe some nodes like that could work, but it's unclear where to draw the line yet (e.g. a node to get the parent object might be much more problematic than this one, but maybe not).

A possibly better and more generic alternative would be a node that takes in a geometry that contains instances and an index, and outputs the geometry of the instance at the given index.

In D14049#374403, @Jacques Lucke (JacquesLucke) wrote:

While I can see that this node can be useful, I'll probably not allow it without further consideration.
Having nodes that allow us to get one data block (ID internally) based on another might make dependency tracking significantly harder if not even impossible. Maybe some nodes like that could work, but it's unclear where to draw the line yet (e.g. a node to get the parent object might be much more problematic than this one, but maybe not).
A possibly better and more generic alternative would be a node that takes in a geometry that contains instances and an index, and outputs the geometry of the instance at the given index.

At the moment I don't believe this node uses the ID data block. Instead it loops through each element of &collection->children or &collection->gobject, adds them to an array, sorts them by name, then returns an object from that array.

This is the same thing Collection Info does when Separate Children is selected. Collection Info also uses id.name for sorting, just as this node does.

I'm mainly talking about nodes that take some ID as input (e.g. object or collection) and output another ID. Don't think we have any node like that.

A possibly better and more generic alternative would be a node that takes in a geometry that contains instances and an index, and outputs the geometry of the instance at the given index.

This would be good too, although the goal with this node is primarily to make it easier to navigate collections, particularly subcollections, when dealing with lots of structured objects.
Maybe it could be done by introducing a "Collection to Instances" node which would then go into a "Geometry at Index" node, but this would only work for objects and not subcollections.

I can add checks for self reference like in Collection Info and Object Info if this would reduce the amount of possible issues.

(Also I tried to make a parent node, but it never seemed to return anything for some reason)

The Collection Info node with Separate Children already does already what you need afaik.

In D14049#374458, @Jacques Lucke (JacquesLucke) wrote:

The Collection Info node with Separate Children already does already what you need afaik.

The issue with Collection Info is the way it combines subcollections into a single instance, which is explained in more detail in the Right Click Select post:

Example: a procedural building is made up of 25 different collections with parts (roofs, corners etc.).
Now the user wants to change the building style. He'd need to change 25 collections to reference the other style.
It would be easier if one could just select a single "master collection" and the subcollections could be sorted out using nodes.

You wouldn't want to put all parts in one collection, because then you could not vary the number of part-variations per collection without breaking the node setup - so nesting collections is unavoidable.
(For example, one style might have more doors or walls than another)

However, right now all subcollections are joined into a single object, after one separation.

Also in the Object case, it's not intuitive nor fast to delete all geometry except for a single object.

The issue with Collection Info is the way it combines all subcollections

If I'm not mistaken, it does not "combine" all subcollections. The information about nested collections is still available. It's just not easily accessible currently. An Instance/Geometry at Index or Instance to Geometry node might solve that.

In D14049#374477, @Jacques Lucke (JacquesLucke) wrote:

The issue with Collection Info is the way it combines all subcollections

If I'm not mistaken, it does not "combine" all subcollections. The information about nested collections is still available. It's just not easily accessible currently. An Instance/Geometry at Index or Instance to Geometry node might solve that.

Ah thank you, I understand now. I will work on adding a different node, maybe "Separate Instance Children", to extract child instances from a collection instance.

In fact, I still think that this node is needed
I can offer the idea that not only collections, but also objects can have descendants
and you can also search for them using the name
In this case, this node will have more functionality and also give a convenient design.

In D14049#374752, @Iliya Katueshenock (Moder) wrote:

In fact, I still think that this node is needed
I can offer the idea that not only collections, but also objects can have descendants
and you can also search for them using the name
In this case, this node will have more functionality and also give a convenient design.

I totally agree.
I think it's more intuitive from a user's perspective.