Hello all!
This is a dumb question - first time poster, I’m a beginner in python and gh-python, so apologies! There is a lot of refactoring to be made in this code, but for now I just want it to work
I’ve looked at several topics with the same question but I can not quite figure it out. I think this is a problem that boils down to the differences of using methods/functions from rhino.geometry and rhinoscriptsyntax-
I am trying to create breps from rectangles created on perp frames (earlier in code, not included as I dont think it matters - works fine).
To extrude the rectangles I use rs.extrudeCurve with SDL-lines as guides. These SDL-lines are generated from the “rg.line” method. I think the issue is trying to use lines from rg.lines in rs.ExtrudeCurve because the rg.lines aren’t added to the document/rhino and as such don’t have GUIDs?
How do I fix this issue?
Many thanks in advance
extrusion_lines = []
for rectangle in rectangles:
iteration = 0
start_point = rs.CurveAreaCentroid(rectangle)
start_point = start_point[0L
direction = perp_frame_intersections[iteration].ZAxis #gets Z-vector from perp frames generetated earlier in script
line_sdl = rg.Line(start_point, direction, 150)
extrusion_curves.append(line_sdl)
rectangle_breps = []
for rectangle in rectangles:
iteration = 0
rectangle_brep = rs.ExtrudeCurve(rectangle, extrusion_curves[iteration]) #gets sdl-line from list extrusion_lines
rectangle_breps.append(rectangle_brep)
errormessage:
Runtime error (TypeErrorException): Parameter must be a Guid or string representing a Guid
This is probably not the answer you’re looking for. But if you’re writing geometry generation/analysis code in GHPython, you’re gonna have a bad time mixing rhinoscriptsyntax and RhinoCommon. While it might be contentious, I advise beginners to start using RhinoCommon as quickly as possible, for numerous reasons:
And to learn how to inspect rhinoscriptsyntax source code, to see how it implements RhinoCommon:
That said, rhinoscriptsyntax is still very useful in GHPython. Notably when interfacing the Rhino document (e.g. reading geometry from layers and adding things back into Rhino).
I don’t know if you are using Python in Grasshopper or just in normal Rhino - it is a bit different, especially concerning how GUIDs work - so I thought I would add the following with respect to using Python/rhinoscriptsyntax/RhinoCommon in Rhino (outside of Grasshopper):
Rhinoscriptsyntax works mostly with GUID’s of objects found in the active Rhino document. The GUID’s are used to find the objects so that their geometry or attributes can be used to do something. When new objects are created, in general they get new GUIDs and the objects are automatically added to the document.
RhinoCommon geometry methods work with “virtual” geometry - i.e. geometry objects that have not been added to the document and thus do not have ID’s. You can do whole serties of operations in RhinoCommon without actually having to add anything to the document, at the end you can simply add the result to the document (or not). (BTW, adding objects to the document is basically “Baking” in GH.
When you mix and match rhinoscriptsyntax and RhinoCommon methods, you need to be careful. Each generally wants different input, rhinoscriptsyntax is looking for ID’s as above, and RhinoCommon is looking for “pure” geometry objects.
Runtime error (TypeErrorException): Parameter must be a Guid or string representing a Guid
When you get this with a rhinoscriptsyntax method, it means that you have tried to pass something that is not a GUID as input object when that is what it is expecting. In this case you sent some virtual geometry and the rs method wanted a GUID of an object in the document.
Once you are in RhinoCommon with virtual geometry - as you are with your lines/rectangles above - it is best to stick with RhinoCommon methods. So instead of rs.ExtrudeCurve() you might want to look at one of the Rhino.Geometry.Extrusion.CreateExtrusion()… methods, or if you want literally to extrude a curve along another (path) curve, maybe Rhino.Geometry.SumSurface.Create(curve1, curve2)
Hi! Thank you for your well thought out comment! It was really helplful. I managed to solve the issue by ‘adding’ the rg.line to the document with scriptcontext.object.addline.
But concerning the larger question involving the ‘workflows’ of rhinocommon and rhinosscript I have a few questions/reflections after reading your posts @Helvetosaur and you @AndersDeleuran ) that I would like to get feedback on (and from anyone else reading). I’m trying to understand this , so apologies for the deluge of words.
Am I understanding it correctly that RhinoScriptsynax is a bit like using ‘visual scripting’ in grasshopper? What I mean is that in order for you to create a rectangle on a curve in ‘native GH’ you first create several geometries before your ‘end geometry/wanted geometry’:
Example: create line/reference line -->divide curve (points) → perp frames(planes) → rectangles (‘end geometry’). See screenshot below.
These components all reference/generate geometry (points and frames). Do these geometries have GUIDs even though they are not baked in Rhino? Do they exist in the rhino document even though they are just a ‘preview’ in grasshopper?
Does using RhinoScriptSyntax utilize the same type of workflow as shown above with the screenshot, where several ‘intermediate’ geometries are created (with GUIDs) before the final geometry is actually attained?
Alternatively, using RhinoCommon you don’t generate geometries until you ‘want’ to and return only the ‘end geometry’ with GUID to the Rhino document/workspace (I’m not sure about the terminology ). I assume this makes it faster than it’s RS cousin? As geometries in RhinoCommon don’t generate GUIDs and its functions take in more ‘abstract/conceptual’ parameters than RS which takes in actual GUIDS/ ‘real geometry’/‘preview geometry in grasshopper’?
2.I’m working only in GH so far. If scripting in GHPython, should I either stick to rs-modules OR rg-modules because they work differently? Or is it an acceptable workflow to use scriptcontext, which as far as I’ve understood it is a bridge between RhinoCommon and RhinoScriptSyntax. Is it a bridge between the two, or am I misunderstanding it’s function?
Can I do everything in RS that can be done in RC? Are all rc functions/methods wrapped in rs?
No they do not. Nothing is added to the Rhino document until you actually bake something in Grasshopper. The geometry remains ‘virtual’ although a preview is shown.
This will be different when running scripts in pure Rhino outside Grasshopper versus inside a Grasshopper script component. As stated above, when running directly in Rhino, GUIDs are created by rhinoscriptsyntax for the methods which add objects to the document. When running rs methods inside a Python component in Grasshopper, they act differently - I don’t know how it actually works behind the scenes, but the objects are not added to the document until you bake.
Only if you actually need the ‘end geometry’ in the document - otherwise it’s not actually necessary to add anything to the document.
They are not ‘cousins’ actually. Rhinoscriptsyntax methods are actually wrappers for routines written in RhinoCommon - the main purpose is to simplify coding by having a set of ‘higher level’ methods which allow you to code with fewer lines. Outside of Grasshopper, RhinoCommon methods may indeed be faster in some cases because you are not reading or writing to the document, which is a slow process.
Scriptcontext is not a bridge between Rhinoscriptsyntax and RhinoCommon, it is a bridge between RhinoCommon and the active document. In the case of running inside a Grasshopper scripting component, you can reference either the current Rhino document or the current Grasshopper document via scriptcontext.
You have that backwards. You can do everything in rhinoscriptsyntax in RhinoCommon - because it’s all actually written in RhinoCommon. OTOH, there are many things that you can do with RhinoCommon that you cannot do via rhinoscriptsyntax.
If you know what you’re doing, I guess you can mix, but it could lead to confusion. I think it’s best to stay in one, and running in Grasshopper I think I would go with RhinoCommon - but that’s just a personal opinion. Rhinoscriptsyntax is more suited to scripts that run outside of Grasshopper in a normal Rhino document environment (again in my opinion).
