some GhPython confusion

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.

I hope this helps,

- Giulio
_______________
giulio@mcneel.com
McNeel Europe