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

Replies to This Discussion

Permalink Reply by Damien Alomar on October 27, 2009 at 12:20pm

I wouldn't qualify one approach as being "better" than another, but each has pros and cons that you must weigh when deciding what technology to implement and use. All do what they do well, but invariably there will be some trade off between each of them.

Grasshopper (natively, with no .NET scripting) will always be the easiest and quickest to implement and use. Even people who have just started working with computational design find it pretty easy to understand, so the more people you have on your team that are not familiar with code, the more you'll find this useful. However, there are a number of downfalls about GH. In a collaborative environment, the biggest one is how do you get multiple people working together. If you can split the problem into completely separate parts, then you can have something going, but if you can't, then you're somewhat stuck, and invariably separate parts will have to come together in some way as well. Also, there are things that GH just doesn't do well. Now those things are relatively few, but if you need to do things like recursion, complex loops, or iterative solutions, you'll be hitting a wall with GH.

Rhinoscript is incredibly useful. You can do pretty much anything you can do within Rhino, if not natively through Rhinoscript, through scripting commands. You can keep better track of complex information and keep that information organized. You can also connect to other softwares in a relatively easy manner. Rhinoscript can also collaborate very well, since code can be split into separate functions and those functions can be called/used from other functions once they're finished. The big con with Rhinoscript is that you need people who know how to code in order to take advantage of it, and on top of that, people's familiarity with Rhinoscript may dictate what you can and can't achieve with it. Code can also develop at "unpredictable" speeds. IOW, certain things may take longer to develop and some might come together quicker than initially thought. Again, the experience level of the people coding will dictate how fast, but also how accurately any timeline for implementation might be executed. Lastly, Rhinoscript isn't nearly as interactive as Grasshopper when it comes to working with a variety of design solutions. This is somewhat of a push, but its worth noting that you'll likely need to find another way of evaluating those design solutions.

Coding VB.NET within GH has a number of positives, but comes with a bit more baggage. Of course, we all know the VB.NET will allow GH to do things that it can't do natively, which certainly extends the viability of using GH in the first place. This makes the code "accessible" to people who may not be able to code themselves, since they can more easily utilize it than a Rhinoscript that does everything. Also, because a VB.NET component is only a portion of the solution, it allows for less code to be needed than Rhinoscript, and allows for one person to be working on the code while another is working on the definition around it. Collaboration wise, complex issues can be separated into different functions just as you would in Rhinoscript. The cons with VB.NET are significant though. Coding .NET is going to be much more involved and something that fewer coders are familiar with. Unless you're working with someone who has a lot of experience with the RhinoSDK, code is likely to be slower to develop than a comparable Rhinoscript. There are some limitations with how the .NET components actually run code, so connecting to other software is more complex than doing so with Rhinoscript. Since the .NET components lack a debugging feature, errors are harder to track down*.

There are two other options here that are less enticing, but options none the less. It is possible to write a DLL with Visual Studio that can then be used within a .NET scripting component in Grasshopper. This might be useful if you're trying to implement some functionality outside of GH/Rhino or some specialized functionality in a somewhat easier way. This is more "extreme", but still an option. The last one is to just write it all as a .NET plugin. Again a more complex convoluted option, but if you're trying to work with other applications, this may just be the best way to do so. In both cases, these options require someone who is quite adept at coding, so these are something that's out of the reach, and beyond the needs of most users.

Personally, I think that there's no reason why any combination of the three can't work, but it will depend largely on the problems you're trying to solve and the people who are trying to solve them. Work with the strengths of your team, and that will generally produce the best and most effective work.

*the next public release will have line numbers when an error occurs, so that will help.

Permalink Reply by Benjamin Golder on October 27, 2009 at 10:56pm

Thank you Damien, that is a very thoughtful response. I agree that none are objectively better, but I am mostly curious about user's individual experiences and tastes, because those hold a lot of valuable wisdom on how to organize tasks between the three.

We have a variety of skills on our team, and I have been finding grasshopper really useful to a group project because I can slap huge labels on everything and visually organize the algorithm so that someone else can understand it relatively quickly. The connecting wires make the flow of information very clear to me, and it is easy to track where some data is missing or getting lost. But we run into certain walls on a regular basis and frequently resort to VB script components. It seems that for us the preferred environment is grasshopper, and that VB script comes in often, but only out of necessity.

I am curious to what extent experienced Rhinoscript users are enjoying the interface of grasshopper. Do you feel that it helps to intuitively work with the algorithms you are designing? Does the visual interface help to organize your algorithms more clearly and creatively? Does it feel too limited because it lacks the things you mentioned, "like recursion, complex loops, or iterative solutions", or is that easily overcome with a little VBScripting? When does an algorithm cause you to move your work into the native grasshopper environment vs. a VB scripting component?

Permalink Reply by taz on October 28, 2009 at 8:42am

Hey Ben and Damien,

Interesting discussion... mind if join in?

I think anyone experienced with RS will more intuitively appreciate what GH does. GH isn't really a true "visual" scripting language but anyone who has scripted will recognize that:

RS -> GH
variables -> geometry, primatives
arrays -> lists, data trees
looping, recursion, iteration -> scriptable component

As Damien mentioned, in RS the code is split into separate functions to create chunks of code in a much more manageable size. I believe this kind of thinking can help to manage GH definitions (at least for me).

(I would recommend that in addition to the GH primer people should also read the RS primer since it goes into more detail about NURBS geometry and is the original source for a lot of information duplicated in the GH primer...)

I think the most powerful combination of skills would be:

_someone who is experienced enough with GH to know what it can't do
_someone who is experienced enough with VB.NET to know if what GH can't do can be scripted

I imaging a team with those two types of people could work simultaneously in an efficient and productive manner.

Permalink Reply by Damien Alomar on October 28, 2009 at 9:23am

By in large, code doesn't necessarily communicate well, unless you can understand the code (comments help, but only so much). In a group environment, communication is key, and therefore the visual nature of GH, and the organization that a definition produces are certainly of value.

I think the more experienced the Rhinoscript user, the more likely it is that they will continue using Rhinoscript. I don't want to use the word enjoy because they may find it visually or aesthetically pleasing, yet still not choose to use it for their work. To most scripters, I would say that GH puts another layer in between where they are and what they are trying to achieve. So why drag wires around and search for the right component, when I can just write the dozen lines and be on my way? There's a control, immediacy, and an effectiveness to doing exactly what you need to do with as few intermediaries as possible.

Again, I don't want to speak for other scripters, but the algorithms are what they are, and they need to be clearly organized in your head before they go into code, and for me the same goes for GH. There may be other tools that you use to facilitate that organization, like some pseudo code, or a diagram or something, but a GH definition is neither of those things. The reason for this is because an algorithm should be agnostic. Its about an approach and process for solving a problem. Although GH is visual, its still a tool that performs individual operations. If you want, algorithms are meant to be high level, where you worry about abstractions of the problem. Whether its code or GH, you're dealing with the low level nuts and bolts of getting the problem solved.

@taz
GH definitions can certainly be organized into "functions" if you will. I do that all the time, and we say Sameer's definitions and Gill/Ronnie's definitions doing that on Monday. Its more of an issue that these "functions" are not entirely separate, that they still require being put into the same definition in order to be utilized. With code functions can be kept completely separate and not really worry too much about the logistics of things coming together.

I definitely agree with Taz and recommend going through RS 101 in addition to GH tutorials. It exposes a bit more of what's happening behind the scene, and I think it also allows one to transition back and forth between GH and RS if that ever becomes something that's needed.

Lastly, if you've got the variety of skills on your team that it appears you have, then workflow should really be a primary driver for what and how you use each technology. What allows for achieving the most/highest quality output with the least effort and the highest utilization of your team? It may be that VB.NET only pops up when its beyond GH. It maybe that VB becomes more significant to cut down on components and facilitate organization. It maybe that a portion of your production gets split out into Rhinoscript because it doesn't need to be as dynamic as something within GH. It can be a constant mix that evolves with the project, the team, and the team's skills.

Permalink Reply by taz on October 28, 2009 at 11:19am

@Damien

(This is probably too much of an aside for the actual topic of discussion...)

I understand what you mean about "functions" as "separate" in RS and how there isn't really a 1-to-1 translation of this to GH, but I think (for better or for worse) some people may have used clusters as way to move pseudo-functions between definitions, I think that's why there was such an initial uproar when clusters went away.

Thinking of clusters in that way could be potentially dangerous and lead to using GH in a very inefficient way. If I see all the GH components on the screen I find I am continually thinking of how to make as many of them as possible go away (eliminate redundacy). Sometimes it's a trade-off between eliminating redundancy and managing the data "flow" which is not really a concern with RS (because functions are separate...).

As you bring up from Monday, the issues of canvas organization are also interesting. Keeping track of one's own work may be one issue, but passing off a definition to a colleague or end user may mean organizing things in a different way. This is a concern only with GH (because of it's visual nature...).

Permalink Reply by Damien Alomar on October 28, 2009 at 12:45pm

I agree that there were certainly some advantages to clusters along with some disadvantages. Yes, the migration of clusters made them very useful, along with keeping the canvas a bit more "tidy". However, I know that I would constantly have issues when I needed to go back and edit clusters, since they didn't go "expand" and "collapse" very well, and each cluster was its own unique entity (ie updates in one cluster didn't affect the rest of the instances of the same cluster). I think these are two important aspects that hindered clusters from working more like "functions".

When clusters come back however, I think that they will begin to actually allow things to be truly separate in a way that can be useful in environments where multiple people need to be collaborating with GH. David has said that he'd like clusters to be more like a definition within a definition, which separate out aspects of creation, editing, and even possibly solving (although much farther in the future). When hopefully clusters come back, this will allow for a more "programmatic" workflow to GH by allowing "functions" to be truly separate.

It will be interesting how clusters will really change this, and I think that's largely a part of how they wind up being implemented. i.e Would it be possible to drag a cluster onto the ribbon and have it just as accessible as a regular component? Would clusters offer some opportunities for recursion/iteration without the need for code? Who knows...

Permalink Reply by taz on October 29, 2009 at 8:30am

Clusters: The next GH game changer!

You heard it here first...

(The next GH game could also be a component SDK, as the Mode men have shown...)

Permalink Reply by Damien Alomar on October 29, 2009 at 9:22am

The SDK is there, its just a matter of access. McNeel/David have come to the conclusion that now isn't the best time to allow that access and I certainly agree with them.

I'd vote clusters before an SDK. At least at the start components are just going to be glorified scripting components. But who knows where they'll eventually go.

Permalink Reply by Suryansh Chandra on October 28, 2009 at 12:37pm

I'd say even for people adept at Rhinoscript, a visually organized structure with wires representing the flow of data appeals because it is just so much easier on the eyes, and more intuitive to how we think. Also, its easier to catch an error because the malicious component simply turns red/orange (in most cases). However, if you are adept at scripting, you are probably very used to recursive looping & conditional evaluation which you miss majorly in GH (it is possible in very limited ways through using series components or comparer components). So an adept scriptor may soon end up switching back to Rhinoscript unless they find the shift from VBscript to VB.net really fast & smooth (which is rare).

GH ofcourse has the advantage of keeping it all 'alive' and changing things with sliders/graphs/image painting, compared to Rhinoscript which is a run-once operation -- so that's where one makes a choice between recursive looping (in RS) & live interactivity (in GH). I'd say RS mostly wins the battle because interactivity is fancy, but recursion can be a necessity.

Now to VB.net. The one barrier I have hit most often with GH is speed. If you were working on a fairly large data set, or doing a number of surface/polysurface/brep operations, you hit the performance ceiling real fast, which is when the interactivity becomes almost useless -- because its nowhere close to real time anymore even if you had 12gb ram. Thus steps in VB.net (A bit of clever scripting can make a really significant difference).

Working a series of geometric operations in a code component is much faster than doing it through native GH components due to the fact that each native component comes with tonnes off error trapping code, preview generation (I think even if you turn it off, its still being computed, only not displayed), etc. while with VB, you can circumvent a lot of that.

If GH were to handle geometry even remotely comparable to what GC/Catia* can do, it would have a long way to go -- I am not sure if that is even the objective. For instance, I am currently working on a tower where all geometry is only meshes and polylines - no degree 3 curves, no surfaces/polysurfaces. This is because if the entire tower is to stay 'alive', Meshes are the lightest option with the amount of geometry being generated. And most of it is through code... there's only the sliders and a couple of other components that are GH native -- and its still in GH due to the interactivity. (I think there's a vast potential with Meshes that GH/Rhino are really not tapping into. There are all the building blocks, but no significant implementation. Giulio's weaverbird plugin is just a small example).

*GC/Catia cost significantly more than Rhino itself, and GH is a free plugin to Rhino. Morever, these softwares were written to be parametric modelling softwares from day1, unlike GH which is an add-on over the RhinoSDK, which was never developed from such a perspective. So a very very unfair comparison there, but GH is becoming so significant that its got a forum of its own -- gaining an almost 'independent software' status. I just hope the McNeel marketing people are not listening :)

Permalink Reply by taz on October 29, 2009 at 8:27am

I agree with the first part of what you are saying. After a certain point, speed wise, GH will bog down and sliders can't be used as sliders (unless you want to wait around all day) and thus the definition isn't really interactive anymore. The clever use of VB can make a vast difference in preserving interactivity.

From your comments in the last part, I'm curious as to how much you use Rhino as mesh (or polygon) modeler. Rhino is marketed as a NURBS surface modeler and that's what GH is piggybacking on. Animation software seems much more centered on polygon modeling and I'm not sure if Rhino wants to compete in that arena (I have no idea really, I'm just speculating...).

Permalink Reply by Damien Alomar on October 29, 2009 at 9:39am

Great points...I think the talks of speed and geometry handling are certainly valid, and proof that you can't have you're cake and eat it too. The odd question becomes (and I'll agree that I'm taking this very far) is that if you've reduced everything to a bunch of VB.NET components, then what's the point of doing it all in GH? If its almost all code, why not just throw it into a plugin, make a windows form with a slider or two, and hopefully circumvent some of the "overhead" related to GH. Its a bit extreme, but in an extreme situation, I could certainly see that being a solution to be considered, if not a viable one.

In regards to meshes and GH, I think that this is the biggest area where GH shows that its not truly a visual scripting language. The big issue with meshes is variable topology, which GH doesn't really have the tools for dealing with at the moment. Pair that along with GH's in ability to manipulate lists in a way that is necessary for meshes, and you've broken down the ability to create complex meshes as well. Over all I think meshes are Rhino's sore spot. They've had to deal with them, but they certainly aren't given the kind of treatment they deserve. So I can't automatically pin all of this on GH. Very interesting that you've found a way to utilize them though.

Permalink Reply by Suryansh Chandra on October 29, 2009 at 4:35pm

Nurbs is most certainly the strong point of Rhino, and so much so that sometimes it feels like Meshes are just thrown in to keep it compatible with other platforms. And I think that is one of the main reasons why Rhino Mesh modelling greatly lacks sophistication or ease of use.

But often enough, you end up conceiving geometry that can be modelled in Meshes, doesn't need the precision of Nurbs, and needs the quick simplicity of Meshes. As an architectural workflow issue, I have been involved mostly in a cycle where conceptual stages are majorly in Maya due to the ability to sculpt out quick sketchy models with polygons and vastly capable SubDs, and Rhino steps in to the process only when precision is required, and one needs to do things like sectioning or precise construction drawings. Since Rhino already has the foundations for an elaborate Mesh engine, it perhaps could become vastly more capable with a little bit of push, saving people a lot of trouble with transferring geometry between platforms and more importantly purchasing multiple licenses and training staff -- but that is a more strategic decision McNeel needs to take as to what they want Rhino to become.

Damien, I certainly agree with you on the plugin bit, where after a point it makes more sense to code a plugin instead of doing it in GH, and it is a leap I intend taking very soon.. as I get more and more comfortable with code.

This is something that I am even looking for some guidance on -- is it worthwhile continuing with VB.net and graduating to writing plugins or is it perhaps a wiser long term goal to do that with C++. On one hand, VB.net is something I am very comfortable with, and its something that can be directly used in GH as well, but it is a runtime compilation language which makes it slower than C++, and since it is all in the .NET framework, it will always be Microsoft dependent.

On the other hand, I believe C++ is directly compiled 'machine instructions', making it faster and also platform independent, and under the hood, Rhino is C++ anyway. There is a whole lot of learning to do (migrating for VB.net), and I speculate that the way to use C++ code would be to perhaps make dlls and then refer them into GH coding components - so maybe this stays useful on the Mac platform as well when GH and Rhino are completely ported? This last paragraph here is mostly speculation (and maybe not even completely true), and I'd like to know what you guys think about this. And maybe this is already drifting quite far away from the original discussion.

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