Create an InterpCurve with a Data Tree Branch (VB.net)

Is it possible to use the RhUtil.RhinoInterpCurve function with a Data Tree branch (full of points) to make a curve? It works to create a Control Point curve: "crv.CreateClampedUniformNurbs(3,data_tree.Branch(0).ToArray, Nothing, Nothing,1)"...But trying something similar with the InterpCurve function has not worked for me so far.

Replies to This Discussion

Permalink Reply by Damien Alomar on June 3, 2010 at 7:28am

Not directly. You will have to translate that branch into an ArrayOn3dPoint before you can supply it to RhUtil.RhinoInterpCurve. Just create a new ArrayOn3dPoint, then loop through the branch and use the Append method to add each individual item in the branch to the ArrayOn3dPoint.

Permalink Reply by Justin Diles on June 3, 2010 at 10:19am

This was my solution as well, but I was hoping there was a one step method.

So far it seems that it is necessary to use:

On3dPointArrays for InterpCurves
Lists ( Of On3dPoint ) for Control Point curves
Data Trees for pushing everything back into GH in an organized way

So far my scripting knowledge is "bottom up" from jumping in and making things work. But, now I think I need a little "top down" overview of how everything is working to understand why, for example, we need to use 3 types of array structures to perform tasks that on the surface seem quite similar. I'm convinced there's a good reason, not complaining. ;)

Permalink Reply by Damien Alomar on June 3, 2010 at 8:13pm

The "reason" has to do with crossing the managed/unmanaged code "barrier" and object oriented programming concepts. All the dotNET sdk really is, is a wrapper around the Rhino C++ SDK. So that means that the dotNET method will call a C++ method that is pretty much the same name and does the same thing. In order to do this, all the information passed from dotNET to C++ goes from being managed code (ie code that the dotNET garbage collector takes care of) to code that is unmanaged (ie it becomes the responsibility of the programmer to discard of information that is no longer needed to be used). When this happens, all the data also has to be "translated" into something that the C++ SDK understands. Using a dotNET specific type (like List(of Something)) doesn't translate very well, so none of the methods use it.

Now most of the time just handing off arrays of Rhino specific objects would work, but compared to using Lists, arrays are much more of a handful (redimming, keeping track of the current index, etc). In order to get around this limitation, Rhino implemented several "list like" classes directly into the C++ SDK (since C++ doesn't really have lists). Thus you get classes like ArrayOn3dPoint and On3dPointArray. Now why there are two, and why one is used over another, I don't really know. They are pretty much congruent, but you can't use one instead of the other. They go back and forth fairly well, so its not the biggest issue in the world.

All in all, this is a whole lot of extra "bitch" work, so for RhinoCommon, the gurus up there in Seattle (Steve mostly) have taken a completely new approach. Now there are specific collection classes just like there were before. However, there's only one collection class (so just Point3dList, although there are specific X,Y,Z list classes as well if you want quicker access to those) and that collection class actually inherits from the dotNET System.Collections.Generic.List type. Long story short, this will be a more natural thing in the future and much less hoopla about it. HTH

RSS