while I am further setting foot into the unknown grounds of the Rhino-Python integration I quite often feel that I stumble, because I am lacking the knowledge of some general principles of the Rhino-Python integration.
The SporphSpaceMorph creator requires point2D types as input for some parameters. However, I couldn’t find a creator for point2D. I used a workaround by creating a point3D and then rs.coerce2Dpoint(…) to make it work. So, either I just didn’t find the creator for the point2D (which means that some explanation would be helpful where to find what, i.e. the general philosophy of the class structure) or the creator is simply missing.
I want to set the color of object I created. By default they have the color of the layer they’re placed in. Then you set the .Attributes.ObjectColor = System.Drawing.Color. and - nothing happens, because one has to set the ColorSource as well (which isn’t really obvious seen from outside). Then the search starts for the pre-defined property “ColorFromObject” which I finally found in Rhino.DocObjectsObjectAttributes.ColorSource.PropertyType.ColorFromObject.
This took a lot of guess work because the class tree in the Rhino online documentation doesn’t properly reflect the class structure in Python. In general: Quite often there are useful examples in C# but when I try to translate them into Python, the class structure doesn’t match.
Or another one:
When do I have to use .CommitChanges() to make changes visible after I changed something? Always after each change? Or possibly only after multiple changes to the same object? Do I always have to CommitChanges() for each object separately? Is there a general “CommitAll()”?
Is a Brep, for example, a RhinoObject? In some respect it appears to be (it has the attributes, for example), but with the geometry property I had difficulties. (The Python for Rhino5 introduction say that RhinoObjects have Object data, Object Attributes and Object Geometry.) The problem occurred when I got a list of RhinoObjects (that’s at least what the documentation says) using scriptcontext.doc.Groups.GroupMembers() and tried to access the Geometry object inside. This only worked using Rhino.DocObjects.RhinoObject.Geometry.GetValue(). I would have expected to access the geometry simply by “.(get)Geometry()”, for example. Having to go through a separate (static) method in a completely different class tree isn’t what I would have expected from an object oriented approach.
Thus, it appears that some general explanation why some things are implemented the way they are implemented would be very helpful.
Anyone feels up to the task to deliver something like that? Maybe a new version of the “Python for Rhinoceros 5” for Version 6? The cited text in my opinion focuses too much on Python basics (can be found elsewhere), special examples of limited use and general aspects of Nurbs etc. which can be found elsewhere too (however how to access the properties of Nurbs in Rhino-Python is of interest). The “uv” parameter space representation of 3D surfaces is probably useful since not normally known by users.
All the examples in this text are geared towards user interaction, but this is usually not what you want when you are automating things. Automating things usually means that you want to use a parametric geometry approach, i.e. defining geometry by parameters rather than by “point and click”.
I am sorry for writing such an extensive post, but I felt it to be necessary in order to explain what I meant with the “philosophy” behind the Rhino-Python integration aspects.