Curve to Model Curve Knot Size Error

Recieving an error regarding knot size, when attempting to convert curves extracted from solid geometry ( geometry recreated from double curved spline based loft in mass env.), into model curves or reference curves in the massing environment. Work around for this? Can nurbs curves be rebuilt within Dynamo?

Other threads on similar issue:

1 Like

isoCurveExtrude_161210.dyn (739.4 KB)


these errors are usually very specific to geometry that is being analyzed. it will help everyone if you can share the surface that you are slicing. often times you can solve them by changing how it was modeled to begin with. please share the original file.

161211_Core Form 03.rfa (672 KB)
a) loft from spline profiles

Ahhh, well in that case i would say please be more rigorous in how you model the original geometry. Like I have said here and in the original post the solution to this was to rebuild the curves to be proper degree 3 nurbs curves. That dynamo geometry library that they are using is the same as in inventor for example and its pretty strict about tangential end line connections. I don’t think that the Dynamo team has a say in how this gets handled. Last time i talked to them they didn’t have control over it.

1 Like

The end goal of this exercise is to generate curve references (extracted from new geometry created in dynamo) to create Form.ByLoftCrossSections in .rfa environment. To my knowledge, this is the only method to create Revit native solids (mass forms), which can be properly subcategorized, AND which also does not substantially rely on python … and/or published nodes which maybe embed certain types of unwanted hidden metadata…

Basic work flow
(1) geometry selected from model. (2) iso curves extracted from surface. (3) new solids created. (4) plan profiles extracted from new solids

Apparent Issues
(a) iso curves from irrational surfaces (b) no built-in nurb curve rebuild operation in Dynamo © no built-in nurb to spline OR nurb to arc/line operation in Dynamo (d) extracted points from nurbs knots, then curve.bypoints has tangency information loss (see “(3)” ).




…even if this workflow was successful, the fact that it requires the creation of reference curves (84k in this instance) almost could not be more memory inefficient. A vector to curve reference, stitching based on curve degree info, would perhaps be ideal.

Any thoughts from the community?