PolyCurves

[ksobon]

I am looking at breaking down and extracting sub curves of a PolyCurve() class. When I query all of the curves contained withing polycurve.Curves() it returns a list of "Curve" objects. Why doesn't it return the actual objects that "curve" class represents here (Line, Arc, NurbsCurve etc)?
Is there a method that I am missing here to check if "Curve" is Line, NurbsCurve etc?
I can only seem to be able to convert them to Nurbs using ToNurbsCurve() but that's really a waste.

Ideas?

[ksobon]

@lukechurch this might be a comment for you. I am not sure about this, so please correct me if i am going in the wrong direction here, but wouldnt it make sense to make some of the geometry constructors public? In a case like I am talking about above, when I am trying to extract all segments of a polycurve, and it returns a generic curve object. If there was a public constructor available to test that curve by trying to use it to construct a line: Line(curve), then I might be able to find out if its a Line.
The obvious solution here is to add a few property methods to the Curve class. IsLine, IsArc, IsNurbsCurve etc.
Also, I know that what i am asking about here can be done by simply casting a curve to Line and seeing if it returns anything but that's not something that you can do with Python.
Well, that leads me to yet another thought. A VB node in Dynamo?
@pboyer @ikeough @kronz anyone?

[tatlin]

Adding geometry.Is* properties is more a question for Patrick, @HLP

Konrad your casting wish would granted if you'd only use c# :)

-matt

On Dec 21, 2014, at 12:44 PM, Konrad K Sobon [email protected] wrote:

@lukechurch this might be a comment for you. I am not sure about this, so please correct me if i am going in the wrong direction here, but wouldnt it make sense to make some of the geometry constructors public? In a case like I am talking about above, when I am trying to extract all segments of a polycurve, and it returns a generic curve object. If there was a public constructor available to test that curve by trying to use it to construct a line: Line(curve), then I might be able to find out if its a Line.
The obvious solution here is to add a few property methods to the Curve class. IsLine, IsArc, IsNurbsCurve etc.
Also, I know that what i am asking about here can be done by simply casting a curve to Line and seeing if it returns anything but that's not something that you can do with Python.
Well, that leads me to yet another thought. A VB node in Dynamo?
@pboyer @ikeough @kronz anyone?

—
Reply to this email directly or view it on GitHub.

[mjkkirschner]

you can also do type / inheritance tree checking in python if that will help?

http://stackoverflow.com/questions/1549801/differences-between-isinstance-and-type-in-python

[mjkkirschner]

and since we use iron python you should be able to do something like:

import clr

clr.GetPythonType(x)

apologies if you're already aware of this, I had some trouble using generic lists between python and c# at first

[lukechurch]

Hi @ksobon, @tatlin

The ability to tell what type an object is is really a language level problem, that we shouldn't be putting in the API -- as we'd have to put it in every single API which doesn't work. So you're right, this is my problem :)

Do I understand correctly that you're trying to work out what the type of an instance of an object is and do a dispatch based on that?

There really shouldn't be any need for adding Is properties just to tell what the type of an instance of an object is, there are ways of doing that in C# (is, as, typeof) and Python (isinstance). It's a bit trickier in DesignScript but is still doable.

In general you want to avoid casting things in C# just to see if they're type compatible or not. That's going to have nasty performance implications. Consider using 'is' checks first.

You can use VB from Dynamo today. The way we do library importing is at a .NET level, not a C# level, though we have only really tested the C# end of things. If you feel like it, give it a try and let us know what you find.

If @holyjewsus' answers don't work - then if you can give me a little more context where you're needing to do these checks, what library, what objects you have around, what language and how you're using it from Dynamo we should be able to find a way of doing it without adding to the API.

Please let me know how I can help more,

Thanks

Luke

[ksobon]

@holyjewsus @lukechurch @tatlin Guys you totally misunderstood my question it seems. My bad if i formulated it badly.
Here's the problem: When using myPolyCurve.Curves() method on a polycurve it returns a list of Curve() class objects, FOR EVERY SINGLE SEGMENT OF S POLYCURVE and that includes for lines, arc, nurbscurves etc.

Obviously on the image you can see that some of the segments are lines or polylines. What I am trying to do is check every returned "curve" for whether its really a line, nurbscurve or arc, etc.
If I do type(myCurve) or isinstance(myCurve, Line), well that just returns True/False and in this case when i compare any of myCurve (Curve() class object) to Line class then I am getting all false (no surprise here since its a "curve").
What you can do with other languages is that you can try to cast this "curve" into a Line class object and if successful it will return a Line. newLine = myCurve as Line
That is not possible in Python as far as i know...please do share if it is.
Hence my question. How does one convert all of the generic curves to their proper classes? I want this returned list to be consisting of Lines, NurbsCurves, Arcs etc and not generic "curve" objects.
Is that clearer?
The reason I am doing this is because I am converting them all to Rhino geometry and it would be helpful to know what they really are - not just "curves" since obviously they are not just that.
Hence, my request to add properties to Curve() class to check if such generic Curve.IsArc ? if that returns True than I know that my generic curve in fact is an arc and that i should collect from it start, center and end points so that i can re-create them in Rhino/Grasshopper. Unless its a NurbsCurve then i would collect controlPoints, weights, knots, degree etc. If they are all "curve" then I have to blindly try every combination for no reason.

[kronz]

@ksobon to put it in as simple as possible way, I think this is your issue: Arcs, Lines, Nurbs, and Curves go into polycurves, and only Curves come out when queried. You want Arc, Lines, Nurbs and Curves to come out of PolyCurve.Curves.

[mostaphaRoudsari]

@ksobon I agree with what @kronz said. As far as I understand your problem has nothing to do with Python or C#, it is just how Polycurve.Curves() returns objects. You can try to convert them back to line, arc, curve, etc.

I'm not sure if DS provides the methods but you can write your own. as tryGetLine, tryGetArc, and so on. For line and arc it should be pretty straight forward and the rest can stay as curves I assume or do you want to break down the curves into smaller groups.

Here is pseudo-code for line. For an arc you can create the arc using start, mid, and end points and do similar check for length. You can also check tangent of the curve at number of parameters and see if it can be a line or arc.

def tryGetLine(curve):
      # Find start and end point
      stPt = curve.StartPoint
      endPt = curve.EndPt

     # if the distance between the points is equal to curve length it is a line
     if stPt.DistanceTo(endPt) == curve.Length():
              return True, Line.ByStartPointEndPoint(stPt, endPt)
     else:
              return False, None

isLine, ln = tryGetLine(curve)

[ksobon]

@kronz @mostaphaRoudsari yes, this is exactly the issue. Thus if you read my original comment it was all about me requesting better Curve API. I asked for methods similar to rhinocommon to be added to Curve class (methods like IsPolyLine, IsArc, IsLine) so that i can avoid doing exactly what @mostaphaRoudsari suggests (breaking down each curve and trying to figure out what it "really" is using curve length, curvature, end points etc.). This makes for a ridiculous process for no reason. If you make a polycurve from actual Lines, Arcs etc then why it returns a generic Curve object when queried for their components? That's the gist of the problem here.

[ptierney]

The decision to return a list of Curves was intentional. This interface gives the PolyCurve method the flexibility to convert the input Arcs, Lines, etc into a different Curve type, if this produces cleaner, more maintainable code on the back end. Sometimes, for instance in the intersection between two PolySurfaces, the backing curve type is unknown.

That being said, in most basic instances, we don't convert your Arcs, Lines, etc to a different type. If GetPythonType doesn't work, it's likely due to one too many extra "glue" layers in our code base, and until that's refactored, there isn't much we can do.

[ksobon]

@HLP Patrick, you haven't addressed my request for more properties, conversion methods. Is that something that we can expect in the future? Building my own functions to tryGetArc(curve) is OK but a built in method curve.TryGetArc() would be that much more efficient especially that you stated that DS converts input Arcs, Lines to Curve object. It only makes sense to add some methods to convert them back.

[teocomi]

Just wanted to bump this issue, it's still happening in Dynamo 1.3.
It would be nice to get the original geometry when decomposing a polycurve:

[Amoursol]

Thank you for the submission of this Issue above - We very much do appreciate your time taken to look to improve Dynamo and help it grow and evolve into the future.

In order to better serve the active Dynamo user base and the evolving nature of Dynamo, the Dynamo team has made the decision to close any issue that hasn't had activity since 1st January 2019. This doesn't mean that these issues will not be addressed, but just that they are not being actively worked on as they do not align with our current Dynamo Public Roadmap.

If this issue is still relevant to you and your workflows, please do re-submit in a new Github Issue and link to this closed issue for historical context.

Many thanks,
The Dynamo Team

[aparajit-pratap]

This has finally been fixed. It should come in Dynamo 2.8. Removing the DidNotFix label.