ghPython - communication between two modules through classes

Goodmorning everyone,

I'm challenging a strange problem in ghPython.

1. There are two python component that communicate.

2. The first one's output is a class object in which many methods are described.

3. This output is the input of another ghPython component which calls the methods of the output class.

So the problem is that when I test the second python script, it does not work.
But when I recompute the whole grasshopper definition, it works.

If I look at the outputs when testing the single script, they appear Null.

I guess the problem lies in the tasks management of the software itself:
When I test the python component, it works only in the component environment, like everything outside does not exist (not even the previous ghpython component --> not even the class with the useful methods).
When I recompute the definition in grasshopper, the software reads and calculates all the components.

Find attached the whole script.
To show the error, first run the "DS" python script (F5). Then, quit the shell and recompute grasshopper definition.

Attachments:

ClassImport2.gh, 11 KB

Replies to This Discussion

Permalink Reply by Giulio Piacentino on May 19, 2015 at 8:09am

Hi Eduardo

I opened your script and understood what you are asking. By itself, you can use one script and pass classes down to other scripts. In a perfect world, the part that contains that class definition would not recompute for just a single point that is changed. That is possible, if you do not make that class dependent on inputs.

Also, like this, you have to make sure yourself that the class that is passed downstream is immutable or you'll get very very bad results with custom classes if they are modified by two independent components downstream. GH cannot duplicate your class as it does for all geometry items.

Finally, to fix the "Guid not found" error:

I changed SrcPts to Point3d. This was an issue with half-recomputing the solution in-between: the document did not contain the IDs because it was already flushed (it is flushed after the solution is computed).

Does it make sense?

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Attachments:

ClassImport3.gh, 14 KB

Permalink Reply by Eduardo on May 19, 2015 at 10:47am

Thanks Giulio for the thorough solution, I've understood the way it works and the reason of the communication issue.

The problems is that the issue occurs on others variable, which are input as string, and output as double or Point3d. So the variable type can't be set ex-ante.

It seems harder for me to get the general argument, and the general communication structure nested in the python behaviour. It seems that splitting the script into manycomponent, later connected by classes behave different from having one complete script, isn't it?

Permalink Reply by Giulio Piacentino on May 19, 2015 at 11:03am

>>The problems is that the issue occurs on others variable, which are input as string, and output as double or Point3d.

Can you post a small example, please?

>>It seems that splitting the script into manycomponent, later connected by classes behave different from having one complete script, isn't it?

It should be a matter of how things are placed. Each componenent is solved independently by Grasshopper logic.

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

Permalink Reply by Eduardo on May 19, 2015 at 11:27am

Here is a simple example of what is happening.
The mirroring operation requires a guID, but the input type is Poit3d, because we set it before. I tried the method coerceguid but it returns null value, I think for the issue we talked before.

How can i manage the variable type inside the script?

Attachments:

ClassImport3.gh, 13 KB

Permalink Reply by Giulio Piacentino on May 19, 2015 at 12:21pm

This is the same issue as before, but reversed. The rs.MirrorObject() function, being a rhinoscriptsyntax function, expects an ID (a "Guid"). If you have geometry, you can add it to the current rhinoscriptsyntax document using

import scriptcontext as sc
ID = sc.doc.Objects.AddXXX(geometry)

In general, the rhinoscriptsyntax library is procedural, and as such is not that well suited to work with OOP. You could rather use geometry directly, and use RhinoCommon methods all the time. If you are using points, the a mix of RhinoCommon and rhinoscript might work well, too.

Giulio
--
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

RSS