some GhPython confusion

Firstly, a big thanks to the GhPython team!
I'm admittedly new to Python and don't code within Grasshopper often to boot so apologies if some of the following questions are a tad obtuse, however I didn't find any answers on the many resources and forums available for those using Python and Rhino. Hopefully I'm not the only one who will benefit...

The "ghdoc" variable and rhinoscriptsyntax target bear some explanation. I get the gist but would appreciate some notes on how to output for Rhino v. Grasshopper and, for Rhino targets, how that output behavior is intended to work with the Grasshopper solver.
Based on this comment I understand that RhinoScript use within GhPython may be less ideal than RhinoCommon use. Is this an efficiency/memory issue? Compatibility with future development? Other reasons? From this, it seems the methods should be compatible within the same component. However, are there circumstances in which it is advisable to one or the other?
Related to both of above points, is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classes?
Are there some RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometry? In particular I'm not able to draw/preview TextDots.
Any notes/advice/resources for working with Data Trees in Python?

Thanks in advance for any elaboration.
Nathaniel.

Replies to This Discussion

Permalink Reply by Giulio Piacentino on May 25, 2011 at 10:03am

Hi Nathaniel,

these are indeed very pertinent questions.
I'll try answering them one-by-one. I'll be glad if anybody else wants to add some input, or if you have further questions - I will be able to answer further on Friday.

The "ghdoc" variable and rhinoscriptsyntax
The ghdoc variable is provided by the component if you select it as "target".
You might ask yourself: "why do we need it"?
Its use comes from the very design of the established RhinoScript library. This library is imperative, which means it is build from a set of procedures or functions that act on various geometrical types. Additionally, there is one level of indirection: most of the time, the user does not work with the geometry itself in the variable, but rather with Guid of geometry that is present in a document. This is exactly what ghdoc is: it is the document that the RhinoScript library always implicitly targets with all AddSomething() calls (for example, AddLine()).
Based on this comment...RhinoScript use within GhPython may be less ideal
That comment is from a previous version of this component that did not have the ghdoc yet.
With the ghdoc variable, the standard Rhino document target of RhinoScript is replaced, therefore we can use Grasshopper while leaving the Rhino document unchanged. This saves uncountable Undo's, and makes it easy to structure ideas through the definition graph
...is the rhinoscriptsyntax target irrelevant if using solely RhinoCommon classes
Yes. If you create class instances (objects), you will need to create also your own collection objects to store them (mostly lists, trees). You can imagine the ghdoc as being an alternative to them, just that you do not access data by index (number), but by Guid. So you can use the RhinoScript or the RhinoCommon libraries independently or mix them. The RhinoScript implementation in Rhino is open-source and is all written in RhinoCommon. Also the ghdoc implementation is open-source, and is here.
RhinoScript and/or RhinoCommon objects which are not recognized as valid Grasshopper geometry
Yes, sure, Grasshopper handles only a portion of all available types. Basically, unhandled types are all the types that do not exists in the 'Params' tab. For example, there is no textdot and no leader, so on line 149 there is a throw statement and all TextDot calls (about line 350) are commented out. When/if Grasshopper one day will support these types, these calls will be implemented.
DataTree
Here is a small sample. However, I think that 80% of the times it is not necessary to program for DataTrees, as the logic itself can be applied per-list and Grasshopper handles list-iteration.