Grasshopper but not Rhino users?

Any guesses on what fraction of Grasshopper users never use Rhino directly via commands (typed, via icons, etc)?

Whenever I use Grasshopper I tend to use only Grasshopper.
At least I try to do so. That’s why I have suggested before GH to be a separate application.

I honestly believe if GH is independent application it will be used more by programmers and it will boost its popularity worldwide.

1 Like

You might be right, but I don’t think that it would be a good strategy in the longterm.
Also, you’d still need some sort of viewport for geometry rendering and I/O functionality, which I imagine is already a big chunk of what Rhino actually is.

It would be great though if different workspaces were available, like in other CG programs.
I could for instance imagine a modelling workspace for Rhino use, a Grasshopper workspace with a slimmed down Rhino interface and viewport and maybe some kind of coding workspace.

It could be another business model for McNeel (or David independently :stuck_out_tongue_winking_eye: ).

GH looks like it has an isolated “ecosystem” it only relies on geometry calculations using RhinoCommon. What if this link was an IO api (as you mentioned). This will allow other 3D applications to be hooked as well and benefit from GH instead of struggling to develop there own visual programming plugins (e.g. xGen in 3DX)

Update:
Especially as I continue to see a lot of engineers resisting to learn programming. This will be a great opportunity.

1 Like

If its in rhino it was baked in. Granted i was giddy when i realized Pull & Orient3Points were rhino commands as well.

1 Like

LOL :wink:

GrasshopperInside or GHInside for Revit, ArchiCAD, Blender, Maya, zBrush, etc.! :wink:

1 Like

I always find this question amusing… If you are using Grasshopper, you are using Rhino. Grasshopper does not exist without the Rhino geometry library and functions running underneath it. It’s just sort of a different interface (perhaps an oversimplification, granted). And, you need to own a Rhino license to run it, whether you are running locally or with Rhino.Inside.

What is also funny is people trying to figure out why GH doesn’t do what they want because they haven’t taken the time to understand the Rhino geometry engine (both its function and limitations) running underneath it.

5 Likes

If you’re using GH, you’re using RhinoCommon certainly. But the usage of the RhinoApp is kinda forced on you. Because McNeel has decided that RhinoApp will launch GH.

It may as well be a different case. What if RhinoCommon.dll and all the other relevant DLLs are loaded in GHApp (having an independent launcher)?

Currently most calculations are pulled out of Rhino, but if you remove that you’ll still have a GDI+ (or OpenGL) based interface of components that are capable of connecting outputs to inputs. All running in a game loop of a sort. Implementing everything a simple programming language could do.

image
In the image above do you see Rhino (or RhinoCommon) mentioned? No! GH Kernel could certainly be an independent application.

I know that which is why I asked about people using Rhino directly via commands rather than only through the Grasshopper interface.

That is my impression also. And sometimes it would be much simpler and quicker to initially explore the feasibility of a concept using simple Rhino commands than by creating a Grasshopper network. After the basc method is established create the Grasshopper network to apply it.

RhinoCommon is not the Rhino core. RhinoCommon is just a common base for various programming languages like C# or Python to call the geometry core functions (via C++?) as far as I know…

As far as I understand GH is not referencing the C++ library it is referencing the dotnet library.

My understanding is it would not be possible to completely reproduce the geometry functions of Rhino using only RhinoCommon.

Which is referencing the core geometry library…

Difficult perhaps to translate and/or reach the same performance. But why wouldn’t it be possible?
Perhaps also they are keeping part of the direct C++ calls in order to keep their IP.

Irrelevant. I am talking about if you completely remove the geometry calculations you don’t need it, just the pure programming stuff.

There is definitely some stuff in the core that is not exposed in RhinoCommon.

So basically you just want to connect boxes with wires, you don’t actually want any geometry.

That is also my understanding.

with the capability to add my own .net assemblies [dlls]