Task: Remove legacy instancing panel for 4.0
Hello. Since geometry nodes are increasingly replacing old things that are poorly controlled, a new task has appeared about this.
I took it up and already I see a list of things that artists would do well to speak about.
Old stuff
Now, if you bind an object to another, the below settings will be relevant for the parent:
https://docs.blender.org/manual/en/latest/scene_layout/object/properties/instancing/index.html
From the user’s point of view, it looks like this: Copies of the attached object are created at all points of the parent.
- All copies are clickable and are considered part of the parent.
- They do not disappear when ALL modifiers are applied.
- If you remove the parent setting of an attached object, it will immediately disappear from the list of parent instances.
- You can hide the original geometry.
The problem №2 can be solved later, it is only indirectly related.
Implementation:
For artists, only the simplest part of the theme is important:
Code that would replace the old instance settings with a node group modifier for instantiation.
You can change everything at any time. But the essence of versioning is that you should be able to get a project with nodes and easily remake it, and maybe live with it further, as acceptable.
Geometry nodes limitation:
There is no list of all children of an object. Not even lists 
.
And if someone offered, I would most likely be against it. Operation with parameters of objects, their interaction, positions, object color, properties, … . This is the object node level. Not geometry. It’s even closer to driver nodes than geometry.
In the future, it would be nice if the object would have a list of children as a result of the operation of the node graph for processing object parameters. But not now.
Across everything, do it the way it was:
It is possible to generate for each object its own individual group of nodes, which would have a bunch of nodes Object Info for each of the children.
Achievements:
- It’s still part of the parent for clickability and hiding.
- The original geometry belongs to us and we can hide it.
No:
- You will manually edit the parent each time you edit the child’s parent data
Another variant:
Geometry nodes can be created for each child.
Achievements:
- No need to make 100+ node groups for every object with instances.
- Each group of nodes will be simple.
- When editing a child, its modifier setting will immediately be at hand.
- Solving the problem by applying ALL modifiers of the parent object.
No:
- Select all as parent.
- Hide parent.
In other words, the question can be formulated as follows:
Parents versus Children!
There may also be an exotic variant in which all trees from children and parents are expanded in the root object. But I’m not sure if that’s what we want to do…
So, what’s your choice, maybe you have your own ideas?
