What is the order of calculation of Grasshopper components?

Hi everyone,

This is a simplified mockup of a document I am currently working on:

When I adjust the slider, the building orientation changes and the camera also needs to change. I am using Horster's set camera to do this.

There are also calculations being done on the building. (Glare using Honeybee, if you're interested.) These calculations are dependent upon the camera location in the viewport.

It is very important that the camera location is updated BEFORE the calculations are done. Otherwise the calculations will be wrong.

I therefore need to understand how Grasshopper chooses the order of calculation. Is it possible to set the canvas up in such a way that I can guarantee that the camera will always be set before the calculations are done?

In the real version of this file, the calculations are being looped hundreds of times. Therefore I cannot check each result manually, meaning I need to be sure that Grasshopper is behaving as I need it to.

I am aware of this post from 2012 where Rutten essentially says it is random. But 3 years is a long time in development cycles. Is this still the case?

Thanks in advance for your help :)

Replies to This Discussion

Permalink Reply by David Rutten on April 29, 2015 at 5:23am

It's not actually random, it never was, but it is very complicated. Also, the fact that it is complicated is not considered a bug, so no attempt has been made to fix it in the past three years. The Grasshopper ideology states that if one object relies on another, it should be downstream from it. I realise in this particular case this is not possible, as the setCam component has no outputs.

The logic is basically this:

When a new solution starts, Grasshopper iterates over the list of objects in the file from bottom to top (this is the same as the drawing order, so you can put objects at the bottom of the list by selecting them and pressing Ctrl+B).
Whenever it finds the first object which has been expired, it will ask that object to solve itself. That object in turn asks all of it's source objects to solve themselves first, causing a shockwave of objects solving themselves all the way to the beginning of the network.

It's difficult to be sure, but if you put the setCam at the bottom of the stack using Ctrl+B (it should then also be drawn behind DoCalcs) then it will in all likelihood be solved before DoCalcs. I'm not willing to guarantee it, but I do think it will work.

If really important data relies on this (and you have no way to automate checking for correctness) there's probably ways to force solving order, but that'll involve a fair amount of scripting, and I've never tried it before so I'm really sure it will work.

Permalink Reply by James Ramsden on April 29, 2015 at 6:06am

Thanks David - this is much clearer now. I suppose my implicit question was 'what does the order depend upon', with possible answers including XY coordinates or input/output order, which I now understand are irrelevant.

Given that there's no easy way to enforce and guarantee order, I think for now I may just edit the camera myself - it's pretty simple and I've done it before. Then I can create a camera edit component which has an output into DoCalc.

For the longer term, is it possible to get/set some kind of Draw Order property of a component through scripting? Had a look through SDK documentation and can't find anything so far. (Even a 'get' would be useful as I can then verify if Ctrl+B has worked.)

RSS