What I am trying to do is to create a cutting brep to split a surface. After I succeed to create the brep I would like to delete the ‘edge1’. But for some reason I cannot delete edge1. I guess because it was created by a grasshopper method. When I use print to check its id it doesn’t the id (see attached).
ghpythonlib uses RhinoCommon, therefore it gives “real objects”, not Guids as results. You can use print(type(variable)) to see the RhinoCommon type of a ghpythonlib data variable.
Thanks for your reply. When I print(type(edge1)) and it returns <type ‘PolyCurve’>.
When I print(edge1) it returns <Rhino.Geometry.PolyCurve object at 0x00000000000000C4 [Rhino.Geometry.PolyCurve]>.
I know how to resolve it without using ghpythonlib, but I am just curious how does ghpythonlib works. Try to understand the basic of using ghpythonlib in Rhino Python.
Does ghpythonlib never create geometries which is visible and selectable in Rhino?
Even if I try crv = rs.coercecurve(crv) I still cannot create a geometry in Rhino.
You can only see and select geometry which has been added to the Rhino document. RhinoCommon geometry - like Grasshopper geometry - is “virtual” until you “bake” it. GH trickery allows you to see the virtual objects as a preview, you can create a special display conduit to see virtual RhinoCommon geometry if you want. However if you want to be able to select and manipulate objects, you need to add them to the document. This is done via scriptcontext.
import Rhino, scriptcontext
#obj=some RhinoCommon object you have created, say a curve or brep
objID=scriptcontext.doc.Objects.AddCurve(obj)
#or
objID=scriptcontext.doc.Objects.AddBrep(obj)
The object will be added to the document and its ID is returned so you can reference it. After adding an object to the document, you need to redraw the views so you can see it:
It is not a typo…but something missing.
Don’t why all the texts with “< >” disappear.
When I try print(edge1), it returns "Rhino.Geometry.PolyCurve object at 0x00000000000000C4 [Rhino.Geometry.PolyCurve]"
When I print(type(edge1)), it returns " type ‘PolyCurve’ "
You said we can create a special display conduit to see virtual RhinoCommon geometry.
Could you explain a bit how to do it?
I think it may be the best way to save the system resource while using ghpythonlib.
I guess if no geometry add to rhino, I don’t need to delete it after I finish using it and I can see it so I know what is actually going on with the object I am dealing with.
Yes, that is a definite advantage, as often the slowest part of a script is adding objects to the document; plus the risk of having temporary geometry get “stuck” in the document if the script bails before it gets to the part where it is deleted.
if you write code using ghpythonlib and then create a conduit to then show it, you might be way better off just using Grasshopper from scratch, because these actions are essentially what it is made for since the beginning!
In other words, ghpythonlib.components is running Grasshopper to evaluate code. Therefore, if you then show it, these are the same actions Grasshopper perform anyways.
It’s not really such an advantage because if your script stops before the conduit is deleted at the end, the conduit will live forever. Because there is no manual way to pick a conduit, if this happens, the only way to fix it is to restart Rhino.
I was only referring to the advantages of using virtual geometry for intermediate results and not actually adding objects to the document unless necessary; not to the use of display conduits. I agree, you can easily shoot yourself in the foot there.
Happened to me very often There is a workaround, always save the conduit in a dedicated sticky before drawing, then check on each start of the next script run if it is still present, if yes, clear and dispose the conduit before creating a new one. (And do the same once the script is finished)
I guess a display related method in RhinoCommon to just clear all remnant conduits would be very useful.
Yes, understood using grasshopper maybe easier…but the problem is, grasshopper can only add geometry(bake) to rhino. In some case I would like to modify or delete geometries. Say, I have 100 pieces of aluminium panels, they have some attributes ( group, layer, material, hyperlink… ) if I just want to assign a panel NO. to it, I would prefer to do it in Rhino Python because it can edit it without recreate a geometry missing the attributes. Reading attributes in Grasshopper and assign them to baked geometry would increase workloads…
Seems either using ghpythonlib in Rhino Python or using Ghpython in Grasshopper has some constrains and limitations…
I guess I would just use a little bit of conduit when I am debugging – just to help me understand what is going on…I probably won’t leave it there when my script is done. Guess it would be less issue?
In that case, during the debug phase, with a couple of additional lines of code I would just add the object(s) to the document and force a redraw. Then you can simply comment those lines out later. I do this all the time.
There is a workaround, always save the conduit in a dedicated sticky before drawing, then check on each start of the next script run if it is still present, if yes, clear and dispose the conduit before creating a new one. (And do the same once the script is finished)