I was wondering if anyone had the answer to this question :

If in the geometry node of an object I retrieve via the node object info another object which has a geometry node, sometimes the geometry node of the other object is calculated before and in this case everything works fine, but sometimes it's the geometry node of my first object which is calculated before and in this case it uses the geometry of the second object which comes from the previous frame

Is it possible to know the order of calculation of each object of the scene? or are they calculated at the same time and it is the speed of calculation that defines the order?

Thanks !

  • $\begingroup$ Interesting question, IMO.. had me looking to see whether we had a 'dependency graph' tag. $\endgroup$
    – Robin Betts
    Commented Mar 9, 2023 at 13:07
  • $\begingroup$ Your description sounds like a bug, everything should be figured out right now. Maybe you have a dependency cycle, which is why the behavior is not defined. $\endgroup$
    – mod nop
    Commented Apr 3, 2023 at 11:04
  • $\begingroup$ Just ran into the same problem in Blender 4.0 (specifically, grabbing a collection of curves via Collection Info info node, which themselves are constructed via geo nodes – so there is a dependency, but not a dependency cycle). Added a bounty to give this more attention. $\endgroup$
    – Fii
    Commented Dec 3, 2023 at 11:48
  • $\begingroup$ Hi Valentin. Your description is not very clear. Instead of rushing it, please try decomposing your single sentence description. Make it more understandable and well structured by using simple sentences. Also it is better to demonstrate what the issue is if you already have experienced it. For example, by posting screenshots of your scene set up. $\endgroup$ Commented Dec 4, 2023 at 13:21

1 Answer 1


Can you provide an example that confuses you? The ordering is pretty simple: Blender assembles a scene, analyzing each element, and connects those elements into a dependency graph mentioned by Robin Betts in the comment: it's a tree, where the scene is the root (evaluated last), and objects used by the scene are the branches going out of this root. When A uses B, the B is moved from being directly connected to the root, to being a branch going out of the A. If B then also uses A, Blender detects a circular reference and reports an error. The evaluation order is then to evaluate the leaves first (the elements that don't have any branch coming out of them - they depend on nothing), then evaluates elements that only depend on the leaves, then evaluates elements that only depend on just evaluated elements (and leaves) and so on.

What could be confusing about this, is that an "element" is not just an object; the granularity is finer, meaning that you can drive default cube's $y$ position with Suzanne's $x$ position, and at the same time drive monkey's $z$ position with cube's $x$ position:

You can see the Suzanne jumps at the end of movement, showing that Blender struggles to properly limit the driven field in case of such quasi-circular reference. I wouldn't be surprised to see more bugs like that, which may be the cause of your problems.


You must log in to answer this question.

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