~Four years later and I still can’t find an API reference for ‘coercerhinoobject’ anywhere? In particular, what are the effects of using the optional second and third parameters? Depending on where you start, using the search feature returns either zero or one result, neither of which answers the question:
In some examples found on the forum, the optional params are omitted, in others they are both set ‘True’ and in another example, “-1, True”:
doc_object = rs.coercerhinoobject(G, True, True)
This is far from a unique example of searching and failing to find terms referred to in (Python) script error messages. Example: where is ‘AttributedGeometry’ documented?
if you open utility.py you can find all info you need, or by typing the coerce methods in Rhino Python editor, you’ll see the same info. For example the coercerhinoobject:
def coercerhinoobject(object_id, raise_if_bad_input=False, raise_if_missing=False):
"""attempt to get RhinoObject from the document with a given id
object_id = object's identifier
raise_if_bad_input [opt] = True or False
raise_if_missing [opt] = True or False
The coerce* functions are not documented and that is intended.
They were written as internal helper methods (not written by me, if that helps, but I may have written them similarly, given time and circumstances) meant as a private implementation detail. It’s all just a long series of tests to see: “What did the user input? – in relationship with what the RhinoScriptSyntax function needs”. This is because Python is weakly typed, and does not carry any information about what variable is declared to be, as opposed to RhinoCommon, which being written in C#, is strongly typed. I am sure you know.
Then users discovered it and started using it. Rather than checking the internal functionality of the function, I guess it’s a legitimate option of a self-standing user to use anything available.
When we figured out that it was a legitimate need (as we didn’t know before), we started adding the Create* set of functions of RhinoScript, which deal with exactly the same idea: get some ungrouped or referenced data, and create some grouped data (such as Point3d, or Planes). I did add quite a few, and they are documented. If there is need for more, I or someone at McNeel can do that.
However, many users still use the old coerce* stuff, so we cannot take it away.
Now, this is the history… let’s focus on what you are trying to do. Can you please post a sample so that I or someone else can help you?
I eventually got most of what I wanted for bake-to-layer (with custom material), but it fails to handle groups:
I can recognize the type difference between ‘Guid’ when passing ungrouped geometry and ‘List[object]’ when passing a group. I can traverse the list object and see that it consists of type ‘Brep’ objects but so far, I have failed to find a way to get a ‘Guid’ or the ‘AttributedGeometry’ I want from the breps?
doc_object = rs.coercerhinoobject(geo)
if type(geo) is not System.Guid: #assume 'List[object]' for group
for G in geo:
print 'G =', type(G), type(rs.coercerhinoobject(G))
And like the coerce methods, good luck finding any reference to type ‘AttributedGeometry’ anywhere in the API docs! How the hell can that be?
(“No results were found for your query.”)
I have a hunch that even if I could bake the geometry in the group with this approach, it wouldn’t be grouped anymore, so this is probably all wrong anyway?
Really, I’d MUCH rather be focused on my GH model instead of scripting my own bake-to-layer component. All the more so because my experience with the Rhino API documentation and examples scattered throughout the forum has been utterly dreadful and frustrating.
The source of the coerce* functions is here: %appdata%\McNeel\Rhinoceros\6.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\rhinoscript\, in the utility.py file, line 1050 or so.
scriptcontext.doc.Objects.Find(object_id) can be used in place of the other line. If the geometry is needed, then the .Geometry attribute can retrieve it.
RhinoScriptSyntax however allows Guids also typed as strings, not simpler System.Guid objects. Then it needs to add a few more tests to make that also possible. You can probably skip that in your custom-tailored function.
And if you would have read my initial post then you would know that retreiving a guid from rhinocommon geometry base object (or a list of them) is not possible, because attributes such as as a guid is only part of “baked” geometry.
Grasshopper has “a Baking functionality”? Where? Since when? How could I have possibly missed that in the hundreds of pages I have searched the past couple of weeks on this subject? Forum posts, tutorials, Rhino API docs - nothing.