Remove legacy instancing

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:

From the user’s point of view, it looks like this: Copies of the attached object are created at all points of the parent.

  1. All copies are clickable and are considered part of the parent.
  2. They do not disappear when ALL modifiers are applied.
  3. If you remove the parent setting of an attached object, it will immediately disappear from the list of parent instances.
  4. You can hide the original geometry.

The problem №2 can be solved later, it is only indirectly related.


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 :slight_smile: .
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.


  • It’s still part of the parent for clickability and hiding.
  • The original geometry belongs to us and we can hide it.


  • 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.


  • 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.


  • 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…

This is my sample file where you can explore both options and compare with the current implementation.

So, what’s your choice, maybe you have your own ideas?


Ah, I forgot about child instancing when I made this task! Since there are a known number of child objects, it could be fine to add the same number of object info nodes. To just keep the behavior the same in existing files that seems like a fine approach to me. Nowadays collections can do a better job of grouping objects for instancing like that anyway (for new files).

Another option might be a node that adds all of an object’s children to a new geometry as instances, but that seems more complicated as a design level, and we might not want to commit to that.


The collection idea really intrigued me.
We can create collections that are not bound to a screen. Their names will point to the name of the parent, and all childrens will be added there. This collection would not affect rendering, but it could still be edited.

I just want to point that legacy instancing has one advantage over GN - instancing metaballs on a parent vertices to make one mesh. This is not possible in Geometry Nodes right now.


I suppose that’s true, and I’m not sure if the differences would be large or small, but volume from points would technically do the same, or at least somewhat similar, and more VDB nodes will come in eventually im sure. But instancing metaballs would also probably be nice thing to have

Volumes converted to a mesh in GN do not have the same surface smoothness as metaballs. And smoothing mesh position after Volume to Mesh distorts and shrinks the mesh. Just give it a try.

1 Like

Yep you’re right I’m sure, I had that in mind when I said it was probably similar but note quite. Really we should in the future just be able to instance metaballs in the future. It’s not often used…but having the options would be nice. More VDB tools in the future could probably fix the the above mentioned issue, but I mean, whatever gets there first.

1 Like

If you’re lucky, maybe someone for the GSoC will add metaballs to the geometry nodes … hah
And just do, before the complete removal of the functionality for a long time. So far, just automating the transfer of old projects

1 Like

I think geometry nodes are superrior to metaballs anyway…

When this is possible, does blender need metaballs at all?

Metaballs are implemented as a set of geometric primitives, each of which has several functions for implementing various geometric properties, due to which it is possible to quickly generate geometry. Much faster than volume. So as a kind of parametric surface, it’s still an important part that just hasn’t been added yet :frowning:


Metaballs has two key advantages over the voxel remeshing technique: variable influence on each primitive and negative influence. Both make it a good organic modelling tool. At least, unless a proper VDB toolset is released (smooth, shrink/erode, booleans, etc…)

UPD: support meatballs in Geonodes not only as primitives but also as the way it works on the Object level (with all features mentioned above), would be just awesome!


He’s much faster.
Believe me, the volumes are much worse when you need surfaces and a lot of details. Of course, everything depends on the implementation, but I would not put a function on the 3d rasterizer when there is a builtin version.

Because volumes can kind of give barely a visually similar look does not mean that volumes can replace metaballs. Metaballs are primitives and can be used in various ways, also different metalball shapes can be merged and manipulated in different combinations.


These are 2 options with which we can recreate the old behavior (options for how to know about children now)

Now the question is, which is simpler / more extensible / clearer?

The collection is not related to the scene, it is not visible in the scene. But it still combines objects.

This is my example of how versioning of your projects can be implemented using the collection variant:
Object Instancing test collections.blend

do they render as real instances on the gpu now?

(like game engines, in eevee next?)

I don’t know what this question is about. All that’s happening is changing how you tell child objects to be instances. Now not with the help of an object operation, but with the help of geometry nodes. And for porting old projects, I’ll ask for your opinions on the versioning organization decision.

No functional or technical changes.

I added an example file for make it more clear.

Today, the idea came up not to create all groups of nodes with code, but to make them a new built-in asset. So far, this is not certain.
This is my example file, where I tried to bring groups of nodes to a reasonable level. I hope you can study and test them. Maybe they will become an asset one day Legacy instancing.blend.

I think it might be best to create the node groups with code, since otherwise the design of our node group assets has to be the same as the old instancing panel, which might not be the best. (Or maybe the design is just fine!)

Did the developer do performance tests before deciding to remove this option? I also regularly use the old instancing method and I find it to be fast and easy to get implement in a scene. I did some perf tests long time ago and in some occasions the original instancing rendered faster than the particle system.