Curve.NormalizedLengthParamater Bug

rhinocommon
bug

#1

I have come across an inconsistency in RhinoCommon when using the Curve.NormalizedLengthParam method with a subdomain. This overload seems to behave differently for polyline curves.

I have put together a python script to illustrate the issue

NormalizedLengthParamBug.py (823 Bytes)

For me the script produced the following output. Note the value of tSub for the polyline:

Line, domain=0,1, t=0.5, tSub=0.5
polyline, domain=0,1, t=0.5, tSub=0.25
nurbs, domain=0,1, t=0.5, tSub=0.5

I’ve tested on Rhino 5, and WIP 7


#2

It’s a bit hard to tell without running the actual implementation (i.e. are we talking about a Polyline or a PolylineCurve). But perhaps it is related to how Polyline parameters works in RhinoCommon. That is, where the “integer part of the parameter indicates the index of the segment” as seen for instance here:

http://developer.rhino3d.com/5/api/RhinoCommonWin/html/M_Rhino_Geometry_Polyline_PointAt.htm


#3

My test script compares LineCurve, PolyineCurve, and NurbsCurve representations of the same line. I imagine it could be something to do with the underlying polyline parameters but I would still expect a consistent response from the RhinoCommon API for any type of curve, which is why I’m classing it as a bug.


#4

Ah I see, yes indeed, I would expect the same results in that case as well. It can be a bit of jungle traversing/casting all the different curve types in there…


(Dale Fugier) #5

Hi @tom_makin,

Yeah, PolylineCurve seems a bit janky in respect to this function. I’ve logged an issue.

https://mcneel.myjetbrains.com/youtrack/issue/RH-45751

– Dale