rhinoCommon

Replies to This Discussion

Permalink Reply by Damien Alomar on April 29, 2010 at 9:57pm

FWIW, you might want to check out the following page... http://wiki.mcneel.com/developer/rhinocommon ...its got an overview as well as links to online documentation and a downloadable chm/help file.

For me, I'm familiar with the current SDK, so although it is quirky, I understand it and its no biggy to keep using it. If I was starting from more of a blank slate I could certainly see how RhinoCommon would be easier to understand. Secondly, I'm not sure what is and isn't implemented in RhinoCommon, and there are several things that I need from the SDK. Granted these are for writing plugins, not a scripting component, so you may be able to get away with it. Since the old SDK isn't going anywhere, I think its a good idea to understand both. I'll probably play more with RhinoCommon once more gets solidified with it and I'm not smack dab in an plugin that relies on the current SDK.

I would probably say yes with the array question, although I don't have any actual basis to confirm or deny it. In the current SDK you had one of 3 situations, arrayOn3dPoint, On3dPointArray, or On3dpoint(). I'd imagine that Steve consolidated all those (if he didn't, then there's my first wish), so if there's no explicit type I'd say Point3D() would be good... I could posibly see it being List(of Point3D) though, but then....

Permalink Reply by robert cervellione on April 29, 2010 at 10:15pm

great link. one thing i read (and noticed) was that grasshopper .7 came with its own rhinoCommon.dll. so if we reference that version does that mean the gha's we create will be rhino 4 compatible but not rhino 5 like the grasshopper itself. also i guess grasshopper will have to have two builds one for the 32 bit and one for 64 bit of rhino 5.

Permalink Reply by David Rutten on April 30, 2010 at 5:34am

Hi Robert,

this is a temporary state of affairs. RhinoCommon was lacking some functions I needed, so I hacked in some quick-and-dirty implementations. I didn't expose these in the 'official' RhinoCommon version that ships with every Rhino5 Beta, so until Steve writes a proper implementation for these Grasshopper will not run on Rhino5.

There will not be separate builds of Grasshopper for 32 and 64 bit. Grasshopper carries it's own RhinoCommon but it only uses that one when running inside Rhino4 (of which there is no 64 bit flavour). When running inside Rhino5 it will use the default RhinoCommon.

It is likely that there will be a special installer for Rhino4 on one side and Rhino5+RhinoMac on the other. Reason being is that I cannot load Grasshopper in Rhino4 via RhinoCommon, as RhinoCommon needs to be loaded by Grasshopper. That is why Grasshopper.dll is a pure RhinoCommon dll while GrasshopperPlugin.rhp is an old-skool Rhino_DotNET dll. I'll need to write a different loader plugin for Rhino5 and RhinoMac.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Jon Mirtschin on April 30, 2010 at 3:16am

Hi everyone,

I'm just taking a look at the upgrade of the Geometry Gym Grasshopper plug-ins for the new Grasshopper version.

I'm still looking through RhinoCommon, is there any legacy support to convert a Curve to an old OnCurve?
I for one would really appreciate it, as I could phase into RhinoCommon over time. Points I can easily use the constructor with coordinates fields, but curves etc will be more difficult.

I'm sure this conversion might not succeed in some circumstances, but in the short term it would cover most situations my tools encounter.

Cheers,

Jon

Permalink Reply by David Rutten on April 30, 2010 at 5:38am

Hi Jon,

RhinoCommon is necessarily unaware of RhinoDotNET. However, we did manage to add some translation functions, but they are somewhat awkward because of this limitation. In the meantime, we are also adding translators to Rhino_DotNET, since we can pollute that SDK as much as we want.

Have a look at Rhino.Runtime.Interop, it contains conversion functions to and from Rhino_DotNET types, but they are all handled as System.Object.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Jon Mirtschin on April 30, 2010 at 6:11am

Thanks, that's great. I'd done a few basic types (it's a good way to become familiar with the new SDK), but was not looking forward to doing all flavours of curves etc.

And the Rhino_DotNET additions sounds good. At moment I'm nearly done with translating my grasshopper wrapper, but the translators will allow me to upgrade the core plug-in code over time.

Cheers,

Jon

Permalink Reply by David Rutten on April 30, 2010 at 5:29am

Hi Robert,

Here are some of the major changes:

- Single top level namespace "Rhino". There is no more mention of OpenNurbs or RhinoCore
- Atomic objects such as Points, Vectors, Arcs, Lines, Transforms, BoundingBoxes etc. are now valuetypes and have been completely implemented as pure dotnet code. Meaning they are faster to use and they should require much less GC cycles upon destruction. This actually makes it somewhat difficult to port 'old' code, since:


Dim pt As Point3d = GetPointFromSomewhere()
If (pt Is Nothing) Then Return


is no longer a valid operation. pt is never null. pt cannot be null. I had to seriously restructure a lot of grasshopper core code to make it work on value types (structs) instead of reference types (classes).

- No more RhUtil or OnUtil odd sock drawer classes. All the static functions are now on the objects where you'd expect them to be.
- The new classes use DotNET inheritance, so PolylineCurve really does inherit from Curve. No more Class_ID and clunky Cast(), ConstCast() and IsKindOf() methods.
- No more faux-const objects. There is only Curve now, the whole IOnCurve and OnCurve approach has been abandoned. Each object knows whether it is mutable and if it isn't it will typically copy itself internally when you try to change it anyway.
- We use Events a lot more now rather than overridable functions in base classes.
- We use enums almost everywhere instead of cryptic integers.
- We try to support IEnumerable(Of T) in function input parameters instead of a specific array type (like Point3() or On3dPointArray or ArrayOn3dPoint). However, we do have a special list class Rhino.Collections.RhinoList(Of T) (and it's derived types Point3dList, CurveList etc.) that we recommend you use. But that's purely a performance issue, not a compatibility issue.
- We use Properties now instead of method whenever that makes sense, so you can have a much better idea of your data when looking at it in the debugger.

But note that RhinoCommon is still lacking a lot of methods and even some rhino geometry types. This is still very much a work in progress.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Damien Alomar on April 30, 2010 at 6:39am

That chunk of code is interesting, and in a way that makes it a little disconcerting. Can you talk a little bit about working off of Value Types instead of Reference Types?

Permalink Reply by David Rutten on April 30, 2010 at 8:17am

A ValueType works very much like an Integer, or a Double. When you say:


Dim i As Integer
Dim d As Double


They both have a default value of zero. You cannot have a null Integer. In fact, you cannot even have an invalid Integer, unless you define what that means. You can have invalid doubles, namely:


Dim d As Double = Double.NaN


Similar types to this would be the Drawing.Point and Drawing.Rectangle structures. The second you declare one (or rather, the nano-second you declare one) it already exists and all the fields that define that structure have been set to zero.

So, let's have a look at some actual RhinoCommon code:


Dim ln As Line = GetLineFromSomewhere()
Dim pt As Point3d = GetPointFromSomewhereElse()
Dim pp As Point3d = ln.ClosestPointTo(pt, False)


Since both Line and Point3d are Value Types, neither of them can be null. If you cannot trust the GetLineFromSomewhere() and GetPointFromSomewhereElse() function to return valid data, you must check the returned data like so:


Dim ln As Line = GetLineFromSomewhere()
If (Not ln.IsValid) Then Return

Dim pt As Point3d = GetPointFromSomewhereElse()
If (Not pt.IsValid) Then Return

Dim pp As Point3d = ln.ClosestPointTo(pt, False)
If (Not pp.IsValid) Then Return


There are NaN-like constants for all these value types in RhinoCommon. So you can declare them like this:


Dim pt As Point3d = Point3d.Unset
Dim cr As Circle = Circle.Unset


If you pass a Value Type to a function as an argument, it will be copied, unless you specifically pass it by reference. Thus:


Public Sub LimitPoint(ByVal pt As Point3d, ByVal box As BoundingBox)
    pt.X = Math.Max(pt.X, box.Min.X)
    pt.X = Math.Min(pt.X, box.Max.X)
    pt.Y = Math.Max(pt.Y, box.Min.Y)
    pt.Y = Math.Min(pt.Y, box.Max.Y)
    pt.Z = Math.Max(pt.Z, box.Min.Z)
    pt.Z = Math.Min(pt.Z, box.Max.Z)
End Sub


Is no good. It copies the coordinates inside pt and modifies the copy.

You need to either:


Public Sub LimitPoint(ByRef pt As Point3d, ByVal box As BoundingBox)
    pt.X = Math.Max(pt.X, box.Min.X)
    pt.X = Math.Min(pt.X, box.Max.X)
    pt.Y = Math.Max(pt.Y, box.Min.Y)
    pt.Y = Math.Min(pt.Y, box.Max.Y)
    pt.Z = Math.Max(pt.Z, box.Min.Z)
    pt.Z = Math.Min(pt.Z, box.Max.Z)
End Sub


or,


Public Function LimitPoint(ByVal pt As Point3d, ByVal box As BoundingBox) As Point3d
    pt.X = Math.Max(pt.X, box.Min.X)
    pt.X = Math.Min(pt.X, box.Max.X)
    pt.Y = Math.Max(pt.Y, box.Min.Y)
    pt.Y = Math.Min(pt.Y, box.Max.Y)
    pt.Z = Math.Max(pt.Z, box.Min.Z)
    pt.Z = Math.Min(pt.Z, box.Max.Z)

    Return pt
End Function



--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Steve Lewis on April 30, 2010 at 8:22pm

How do RhinoCommon Classes/Objects interect with .NET objects? For instance could a user defined custom .NET class inherit from a RhinoCommon Class?

Permalink Reply by David Rutten on May 1, 2010 at 3:08am

Yes. Classes and Stucts in RhinoCommon are defined in exactly the same way as you'd define your own in a custom project. Unless the class has been marked with sealed (NotInheritable in VB) then you can derive from it.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by robert cervellione on May 3, 2010 at 7:41am

in the Curve class why is there no overload that accepts a Point3dList as the out for Curve.DivideByCount. it seams that the Rhino.Collections are not accepted in many places but they have some extra properties that make them useful.

i could just build a Point3d[] and then addRange to the Point3dList but it seams redundant.

also the Brep.loft has two inputs that are optional (start and end point). could you just make an overload that do not require these inputs.

i know grasshopper has not much to do with the rhinoCommon development but we are probably going to use it most and i do not know where else to post.

• ‹ Previous
• 1
• 2
• Next ›
• Page