In my team we have been using Rhino and Grasshopper to handle 3D objects in a robotic context (so our scripts create robotic trajectories from a 3D object).
Grasshopper allowed us to quickly develop something that works and we are going to keep using it. However it has its speed limitations and we want to integrate what we did in a proprietary application.
So what are the best ways to translate those scripts into C++ or C# code? Should I opt for C++ or C#? What are the librairies that would help me the most to handle 3D in C++/C#.
I havenāt got the chance to test Rhino Inside yet since I am still on Rhino6, but would that be a good way to integrate my scripts in terms of speed?
I am trying to be ready as much as I can before going into the unknown and possibly on the wrong pathā¦ So I would love if someone could help me with this!
I tend to implement parts of GH definitions in C# ScriptComponents. The benefit is that this can be done directly on the GH Canvas so you can test the code as you go. Then itās easy to move the code to VS and compile it.
Not working with Robots but at times I make IK-solvers to enable demo-animations of concepts. Pictured below a mobile crane Iām working on as a side project (will be used to demonstrate a new invention to be attached).
The crane has many joints (double linkage at red rings, moved with IK-calculations) and translations controlled in a āIK-fashionā by moving a point around (see Gumball) with the mouse. The tip of the arm has three extension cylinders, aso.
Over time I tend to replace the GH components with C# script components until performance is good enough. The component solving the double links (emitting Transforms) is the green-ish selected component.
When creating a Grasshopper script you are indirectly using Rhinocommon. A large proprietary .dll that ships with Rhino. You cannot simply reference or replace that. As mentioned, there is an open-source subset called āOpenNurbsā, but seriously, piping together some GH components is from a developerās perspective only a tiny piece of the cake. So unless you implement most of it by yourself, its even questionable to sell it as your intellectual property. Itās like going to a restaurant, buying a meal , putting some topping on it and then trying to resell it as yours.
What you want is a OpenGL or DirectX application. You can do that in C#, but anything in that domain is better solved by using C++. You could also use an engine like Unity and write in C#, but then you have pay license fees. Personally I believe C# is easier to deal with, but itās not the best choice for this purpose. So go for C++.
Yes, but itās much more than that. Itās basically a fully featured C++ geometry framework. It can do all the basic stuff that Rhino or Grasshopper can, and if something is missing you can always look it up and try to implement it yourself.
In C++ thereās also the boost framework, which has many neat geometry libraries that you can combine with OpenNurbs, if something is missing or you want to turbocharge stuff.
Pretty much everything that is written in C# can be easily decompiled, which means that you can look at the original code for inspiration. Now this might be illegal, and Iām not saying that you should copy and/or steal somebody elseās code, but thereās little harm in taking a peak for inspiration. You have to learn somehow.
@TomTom is right. What OpenNurbs doesnāt have is a multi media feature set that can build your app with a UI, or do mouse and keyboard interactions. You can use something like SDL, SFML, openFrameworks, or Cinder for that.
Also if speed is a requirement, absolutely go for C++.
Yes I totally agree with you, and that is how we have been using Gh for, just proof that what we do can work.
That was my guess that C++ was better suited for all this, but I asked for C# because itās easier indeed.
@diff-arch thank you for the libraries, Iāll look it up !
This is not guaranteed to be faster in my opinion. The Grasshopper components are basically DLLs (dynamic linked libraries) that are renamed to GHA. These are compiled, whereas the C# scripting component is only interpreted, and this should always make it slower. You can build your own GHAs though.
The C# scripting components are actually compiled at runtime, but I agree that this is not the best solution.
I wouldnāt recommend immediately jumping to C++ and opennurbs as the amount of extra work involved can potentially completely kill the project. Instead, I would recommend learning to make a custom grasshopper component in C# that can perform all of the logic that you are building up in your grasshopper definitions. Once you have all of the code in a custom grasshopper component, you may have enough to fit for your needs. If you want to take the project further, you will already have the code written by this point and can explore moving the algorithms to work in other environments outside of grasshopper.
Not really. A ScriptComponent is compiled the first time it runs (so watch out for the compile time at first run, typically around 250-350 ms IIRC)) After that first run they run like any other compiled components. Exception: The input & output params are slower than components compiled separately in VS.
Depending on problem to be solved, ScriptComponents is often a super boost when replacing slower GH components which tends to get complex and messy and the logic barely readable. Not to mention when loops and recursion is required (IK tends to require iterative fitting to constraints within tolerances, at least with my redneck approaches).
ScriptComponents is a very good first step to speed up and to clean up messy GH definitions, sometimes also enabling running code in parallel. Using the plugin Parasite you can transform the code to Visual Studio as you type your script and test it.
If already having GH definitions, hopefully well structured in logical groups (or Clusters), a ScriptComponent (+Parasite or Copy & Paste into VS) is a very natural next step.
If need be, make dlls with C or C++ for algorithms which needs that extra speed or for time critical cases where the GC may cause trouble.
