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
Parameters:
object_id = object's identifier
raise_if_bad_input [opt] = True or False
raise_if_missing [opt] = True or False
I guess the raise_if methods will raise an exception if the input parameter is missing/ cannot be coverted.
print help(rs.coercerhinoobject) should give you the docstring as well…
Yes, I see that too, thank you. I’ve just begun to use it to explore some of the mysteries that have me blocked with baking groups:
I’ll see what more I can learn with it, thanks again.
print help(rs.coercerhinoobject) is new to me as well but seeing the source is far more informative than just the comments.
I’ve never seen a situation like this where terms used in error messages (like “AttributedGeometry”) can’t be found anywhere, even going straight to Google?
That must be a sign that you are pushing into rarely explored areas 
Keep pushing !
The wretched pain of the experience is having the opposite effect. I’m not inclined to help anyone with standard GH anymore and very nearly ready to chuck the whole damn thing.
you are a long-standing user but I still ask you to, please, start new topics and not revive old ones. I gave your thread its own place here.
I am typing some answers now.
Old topics like this that haven’t been solved for many years deserve to be reopened again and again and again until there is some relief from the misery created by this sad state of affairs.
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?
It’s a bug that the tutorial mentions coerce. Thanks for spotting it. It’s probably my sample to some user that was copied to the page that did this. I answered here:
https://discourse.mcneel.com/t/python-in-grasshopper-guid-and-geometry/95578/11
I share your distaste for “coercing” (casting), yet that is the method recommended in official tutorials like this one for baking to layer:
How would you modify that bake to layer script to avoid using ‘rs.coercerhinoobject()’?
The not so funny thing is that extensive searching fails to find any reference to these coerce methods or what can be used in their place?
https://developer.rhino3d.com/api/RhinoCommon/search.html?SearchText=coercerhinoobject
(" Nothing found")
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)
print type(doc_object)
print type(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?
https://developer.rhino3d.com/search-results.html?q=AttributedGeometry+site%3Adeveloper.rhino3d.com
(“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.
Why are you searching in RhinoCommon api when you’re using rhinoscriptsyntax?
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.
I don’t want to be writing a “custom-tailored function” at all, I just want a native bake-to-layer solution that doesn’t require a plugin.
I’ve been posting on that subject for several weeks now and received virtually no help at all. Treating issues like this as “custom” scripting functions is a profound misreading of your user base.
It’s custom-tailored in the sense that Grasshopper already had a Baking functionality. You are re-creating it, tailored to your needs. That is perfectly fine and legitimate.
I also added RH-56763 so that the tutorial will not use that function any longer.
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.
I’m not finding real help in this thread either.
Come on!
You’ve gotta be kidding? This isn’t a joke. The point is to bake objects to layers without having to manually set the active layer in Rhino for each one and bake objects/layers, one at a time.
This is ridiculous. Truly a tower of babel.
You didn’t say this before and I cannot read minds. Sorry. Moving this off-topic part to your other thread.
