Hi fellow Blender artists!

I am working on a procedural planet generator that I would like to sell as a commercial product. My focus is on usability and that is where I currently face a problem:

I have a planet object and it has child objects such as "Ring", "Atmosphere", "Moon", "Clouds", etc. All of which are objects without own geometry but a single Geometry Node that creates and manages their respective Geometry. By example the "Atmosphere" child has a GN that creates a sphere slightly larger than the planet itself that is a volume. You can adjust the GN values and therefore change the attributes of the Atmosphere. When resizing the planet, the atmosphere should resize as well, so the atmosphere sphere size is calculated with the help of the planet size attribute from its parents.

Currently I am using drivers to carry over the planet size to its children since they all scale relative to their parent planet in GN.

The problem with drivers is, that when I duplicate the ring child to create another planetary ring, the new ring child needs a new driver connection to its parents planet size done manually.

Is there a way of "hardwiring" the planet size of the parents GN down into the GNs of its children without using drivers? Named Attributes won't work, since the GNs are not on the same object but child objects.

If you know better ways to do it, please let me know. I would prefer doing it in python, but I have almost zero python experience in Blender and don't know how to write plugins for Blender. Would you consider this a necessity for a commercial asset or can I assume that users are smart enough to know how to duplicate and parent objects in Blender? At least I would like to ease the burden on them of having to past the driver each time they duplicate a child object for eg. another moon, ring, etc.

  • $\begingroup$ i just don't understand why you cannot make all these objects in just one geometry nodes tree? Then you won't have all these problems at all... $\endgroup$
    – Chris
    Commented May 1 at 17:57
  • $\begingroup$ @Chris I had them all attached to a single object before, but I ran into the following problems: When having more than one moon using the same moon shader and moon GN, the attributes stored in the geometry get overridden for the second moon since they use the same Output Attribute names. But putting everything on one object forces my hand to attach the named attributes to the geometry instead of instance because otherwise volumes cause problems when combined with normal geometry. No matter how I tried it, the complexity doesn't allow me to place everything on a single object. $\endgroup$ Commented May 1 at 23:58
  • $\begingroup$ Could you provide, using blend-exchange.com, a simplified Blender file with "parent" and "children", illustrating where attributes are and where instances are ? $\endgroup$ Commented May 2 at 5:49
  • $\begingroup$ @StefLAncien Sure, here is the file: blend-exchange.com/b/ls0RrYoe Basically I need a better way of getting the parent objects GN attribute in the childs shader, if possible via the GN of the child. Drivers will break when I duplicate the child and parent it to the parent. $\endgroup$ Commented May 2 at 10:34

1 Answer 1


(Using Blender 3.6.8)


Take advantage of Named Attributes stored in Instance domain to expose "public" variables to other objects and to shaders, mimicking Push & Pop operations on a stack.

GeometryNodes of Parent - Push

Parent GN

1. The value of the attribute to share by the Parent object is recovered through a socket of the Group Input node.
2. It is stored as a Named Attribute in the Instance domain (Push), as shown in the Spreadsheet editor.
3. To do so, the input geometry is converted beforehand to an instance, using a Geometry to Instance node.
NB: Conversion is not mandatory. Storage could be in Point, Edge or Face domain, but storage in Instance domain is limiting duplication of the same global data.

GeometryNodes of Child - Pop/Push

Child GN

1. The "Container" of the variables to access by the Child object is recovered through a socket of the Group Input node as an object, then as a Geometry thanks to an Object Info node.
2. The Value of the Named Attribute stored in the "Container" is recovered by a Sample Index node set in Instance domain (Pop). The Index parameter is irrelevant in this case.
3. Because an object shader could not access its parent object, the newly sampled value is stored (as for the Parent object) in the Instance domain of the Child object (Push).
4. For the demonstration, an other attribute defined at the Child level only is also stored (nodes in dark blue).
NB: Duplicating a Child object is creating a copy that is sharing the same Parent object, but also same GeometryNodes modifier, with same inputs. As a consequence, the "Container" does not have to be updated after duplication.

Shader of Child - Pop

5. The shader of an object can access stored named attributes of this object only, through Attribute nodes.
6. Because named attributes are stored in the Instance domain by previous GeometryNodes modifiers, the Type of the Attribute nodes is set to Instancer (Pop).
NB: For the Geometry Type, storage must be in Point, Edge or Face domain.


Duplicated parent and children

1. In Object Mode, after using the menu entry Select > Select Grouped > Children and ticking Extend, a parent object and its children can be duplicated using the menu entry Object > Duplicate Objects. The parenthood is maintained.
2. It is to notice that the "Container" input parameter of the Child GeometryNodes modifier is updated to point to the newly duplicated Parent object, and not to the original one. As a consequence, the "Container" does not have to be updated after duplication of the whole hierarchy.



You must log in to answer this question.

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