Hi,
Is there a way to transform the smooth points of a subd, using grasshopper? I see it’s simple enough to get the underlying mesh vertices, but don’t see a way to be able to move the surface points (rather than control net points).
Hi,
Is there a way to transform the smooth points of a subd, using grasshopper? I see it’s simple enough to get the underlying mesh vertices, but don’t see a way to be able to move the surface points (rather than control net points).
Try this:
Ah, perfect, so we need to use rhinocommon. Thanks Ricardo.
Hi Riccardo,
I didn’t manage to recreate it unfortunately. Have I got something the wrong way around?
I have a subd where the control net vertices are coincident with points on a curve, but I wish for the smoothed edge to have their points meeting the curve instead.
import rhinoscriptsyntax as rs
import Rhino
import System
pts = [ ]
pt = x.Vertices.First
srfpt = pt.SurfacePoint()
pts.append(srfpt)
count = x.Vertices.Count
print pts
print count
for i in range(0, count-1):
pt = pt.Next
pts.append(pt.SurfacePoint())
array = System.Array[Rhino.Geometry.Point3d](pts)
newsubd = x.InterpolateSurfacePoints( array )
Aha, I got it.I had to set the object to a new variable to generate.
newsubd = x.InterpolateSurfacePoints( array )
s = x
@piac , I wondered if you could maybe help me with explaining the use of this particular array datatype in python. Why does the InterpolateSurfacePoints, and some similar methods, not just return a python list? Requiring to then hunt on discourse for how to get this other data type, which I think I’d be right in saying isn’t very ‘pythonic’ ?
Thankfully the below topic helped me out, but I was just curious if there’s a reason for these specific cases not just returning a list.
Riccardo, I’m having an issue with InterpolateSurfacePointsMethod.
How does the method work, in respect to how it respects the ORDER that points are fed to it in the beginning and end?
is the order of the vertices data (controlnetpoint) the order that needs to be retained?
I am trying to do a more advanced operation, to move only a selected edge of points and keep the rest the same. But, at points I am wanting to use a dictionary but then concerned that I’m losing the order. Since I am using the Id property regularly to get at and change items.
The method SubD.InterpolateSurfacePoints() needs a list of points that are the same amount of the surface points of the SubD you are editing, and the order must be correct, indeed.
Editing only a sub-set of points from the whole list is trivial, use dispatch and then weave.
(you can trick it and make a polyline out of the whole list and then use point deform…)
Maybe attach something here so we can talk about the same situation…
Maybe my explanation is not the best, but.
The Python SKD (Software development kit) in Rhino is based on IronPython, which can use libraries written in C#. This means that sometimes you need to understand the output in C#, to use it in Python.
And in my experience the array-output is pretty much one of the things giving you a headache if you are not used to it.
What version of Python does Rhino use?
Rhino uses Python version 2.7. To be more specific Rhino uses IronPython which brings together the Python language and Microsoft’s .NET framework.
Hope that helps and maybe somebody might have a better explanation?
T.
Hi Tobias,
Yes, thank you for your explanation. It does basically give a headache, for example, from the point of view of a beginner. You learn the python data types, list, tuple, dict, set, and then you are handed this slight curveball for some unexpected methods. Does it suggest that this method is almost not finished in terms of being built for python? Why would some methods require the array data type when others are fine with a list, given structurally they’re kind of the same?
Just a peculiar one I feel.
Jon
@Jonathan_Hutchinson1
Well I think from a developers point of view the benefits of IronPython are, that they do not have to re-write everything in python, but can compile their (I guess it is C++) code to Python. Acutally IronPython does compile the C-Code to Python. So this way the whole thing is pretty much very sustainable.
How to know what returns what imho only can be seen in the documentation.
https://developer.rhino3d.com/api/RhinoCommon/html/M_Rhino_Geometry_Curve_JoinCurves_2.htm
For instance here you will learn that joining curves returns
Return Value
Type:Curve [ ]
An array of joint curves. This array can be empty.
For me reading this, when I had a problem helped pretty much. Of course learning C# will be best, but I guess reading will do the job as well. And I am pretty sure you will get a feeling for it after using it!
Oh for sure, the return type then made it very clear to me, and of course these things are specified in the rhinocommon API documentation.
I guess it just seems odd that the ‘compiling to Python’ step would not just uniformly refer to lists. maybe it’s just a basic kind of restriction that is a stricter list, i.e. a strict list of curves.
When you see these kinds of surprises (that are not covered in tutorials/lessons) it just means you are then on the guard for the next unknown/mystery thing thankfully Discours eis here for that.