Grasshopper vs. VBScript vs. Rhinoscript, which tool is better for what and when?

I wanted to open a discussion about when each of these things is more appropriate than another. I am currently working on a project in which we are using all three, and must constantly decide whether an approach is better in VB.net scripting, Rhinoscripting, or with Grasshopper components.

I would like to hear your thoughts.

For the group I am currently working with, we have found grasshopper to be extremely helpful with rapidly developing and testing different algorithms, and we typically use VB.net scripting only when Grasshopper is unable to do something, or when doing something would cause grasshopper to get unreasonably slow or crash. I can't speak much to the differences between VBscript and rhinoscript, but we have been transitioning as much as possible into VBscript because it integrates so well with Grasshopper.

Replies to This Discussion

Permalink Reply by Damien Alomar on October 30, 2009 at 6:54am

Well making the jump to plugins sounds much harder than it really is. Once you're working with the SDK, that's really the biggest jump. The only difference is working with VS (which is easier than developing in GH as far as I'm concerned) and a few other plugin specific issues.

As for VB.NET vs C++, I'd just stick with VB.NET (or c# if that's your dotNET language of choice). First of all, VB.NET is a compiled language, so its not interpreted @ runtime in the same way a script/RS/Python is. Its compiled into MSIL (MicroSoft Intermediary Language), which is the executed by the dotNET frame work. Its not as "low level" as C++ is, but its pretty fast and a significant step beyond scripting languages.

Second of all, C++ is really a whole different beast than a dotNET language. You have to worry about memory allocation and garbage collection, and the syntax is much more involved. Currently, you can make dlls for reference in GH in either a dotNET language or C++. Also, if you ever want to make GH components (when that becomes available) it will need to be in a dotNET language.

In regards to the Mac stuff, at this point I don't think it matters which language you choose. Marlin has gotten all the C++ stuff to work pretty much natively on the Mac, but as far as UI goes you'll have to use a platform independent GUI solution (ie Qt or wxWidgets). With the dotNET stuff, the guys up at McNeel have been doing a lot of work getting things to run on Mono (which is the dotNET implementation on the mac) which is looking fairly good last I heard. One of the main issues is not necessarily UI, but custom drawn UI (like GH :( )

I think we've certainly drifted significantly far off topic, but its interesting, so I think its worth it. I'd certainly suggest trying to download the free version of Visual Studio 2008 and seeing if you can get started. The wiki has a page or two, and with the wizards that are in VS for a Rhino plugin, you'll be able to compile right from the start. Definitely worth a rainy afternoon.

Lastly, have you taken a look at T-Splines?...its like a "nurbs-i-fied" version of SubDs and its really very powerful.

Permalink Reply by Roland M on October 28, 2009 at 7:46pm

Hi,

When you say Rhinoscript do you mean the Rhino macro language?
If so I have ideas on how these might be classified and why you might use them.

Rhinoscript is easy since it emulates the way Rhino works internally. By looking at the command history after modeling one can see how to build things or what commands are needed if the user wishes to automate the process. One really needs to know this both for Vbscripting and VB.net.

The reason is certain commands like file searches etc are better achieved using the Rhinoscript macro language
Like
rhino.command "import yourfilestuffhere"

It's also needed when other Vbscript methods fail or when certain vb methods are too slow. Like intersection commands of many lines etc. Or say the join surf method in Vbscript can't deal with sorting too many surfs and this is where one would switch to Rhinoscripts rhino.command "join".

Also in a small way Grasshopper is exposed rhino commands in a spread sheet like environment. Instead of linking cells you use the wires. You could almost achieve these same effects using Excel with rhinocommand scripts that are made parametric by formulas in excel then the results are sent via send keys to Rhino where the model is built. It's a lot like the bake option in GH. Gh has many many more capabilities but again the macro language can be used this way too and in combination with Vbscript so it's a must learn and it's not hard.

Vbscript is great for many things but it's not great if you want to create a gui plugin for that use VB.net and Visual Basic.net a great combo.

GH I think is great for testing design options, inventing surfaces and making quickly things that are parametric. It's great for advanced users who can put all of the above together. But it's not great if you want to do this with a multitude of users who would need GH, the model, and the Gh def file in that case a Vbscript or dotnet plugin might be better.

RM