Grasshopper 2

It’s a shame I didn’t make a screenshot of this cluster before the telepathy components, but this is how it looks now :

I guarantee you it’s much better.

Haha. Wow. That’s in a cluster?? I’m glad Telepathy has made your life easier. That said, a few things:

  1. You have a lot of logic repetition (6 copies of what looks to be the same/very similar logic on the right) – are you sure this can’t be done efficiently with data trees and single set of logic?
  2. It’s generally not recommended to have this much logic in a cluster for performance reasons. As you might know, a single change of an input of a cluster causes the entire cluster (and everything in it) to recalculate, regardless of whether it needs it. This differs from GH’s main canvas execution flow, where only the “dirty” components trigger a SolveInstance. This can result a pretty serious performance hit.
  3. Ever consider learning/doing this in C#?

:smiley:

2 Likes

A curious question on the side: why do you think that C# would help here? Because of increased performance? Or are there other reasons as well?

Just asking, because I have been playing around with C# here and there, but as soon as I have to script something for a project I always fall to back to standard GH, as I am much more fluent with it and there tends to be a certain time constraint…

Thanks a lot and happy easter!

Telepathy is one of the best tools out there. I use it for everything, only one problem I would like to see is the copy past with a option to break connections maybe with a automatic renaming.

1 Like

When looked at from closer, you might realize that they are quite different.

I had a discussion with David about this once, and he agreed it’s not always easy to tell if parsing the various cases and exceptions will not end in a terrible mess.

I also read that David had made some improvements on that.
My problem is that my definition is quite large already, and if I un-cluster, I might get the dreaded blood-splattered screen of death…

C# scripts have saved me on multiple occasions, but I’m very much a visual guy.
I don’t understand how some people rather have the text display on components rather than icons… So I really have no draw towards line coding, specially with a stickling language like C#, although I can sense the power emanating from it.

Instead of hiding the “Visuals” in Clusters, do the C# thing.

I tend to first do some prototyping on canvas, and when proof of concept has passed I do C# on bottle necks, or all of it.

// Rolf

2 Likes

Then in 5 years when I’ve managed to cram object oriented programming in my tiny skull, some folk will come over to me and tell me I really should do x86 assembly language programming
:slight_smile:

1 Like

Don’t believe in anything they say about programming languages… :slight_smile:

Truth is that no single language does everything in the most optimal way (except for assembly…:wink: ). But for CAD-geometry, which deals with limited number of static modeling objects, Object Oriented Programming (OOP) works quite well. It just so happens that Grasshopper components are OOP objects. Works well and thinking in terms of objects is fairly intuitive.

The OOP programming strategy otoh can seem a bit messy (some new languages tries to avoid some of it’s messier aspects). And the entire world of Dot NET, a kind of an eco-system which implements the OOP paradigm, is an abyss of excess complexity.

But one can keep it simple also with .NET. With C# components you don’t have care much about OOP. In most cases just type your code row after row and off you go, fast and simple.

Replacing Clusters with C# is motivated only if there’s performance problems.

// Rolf

3 Likes

The main advantage of using script components is better data access, branching and validation.
“If an input is invalid or out of domain please execute something different and tell the user about it. Branch it into another output”. “Compare it to another item and see if its meaningful”. "Repeat things until some condition is true (recursion). "10 lines of codes might replace 100 components. That’s the advantage. It gives flexibility and stability.
You can code this functional or object-oriented, doesn’t matter unless you work in a team.
In a team you have to organize and agree on a coding style/metric. But this is the same with plain GH scripts.

OOP is not good or bad. It’s a strategy to encapsulate logic into meaningful pieces. But if it’s a bunch of classes or a bunch of functions makes really no difference. You can write bad named functions and bad names classes. You can have super-classes and super-functions nobody can follow, and you can completely ignore documentation. The reason why the .Net Framework appears to be messy, is because of its large standard library. Of course some names follow certain code pattern concepts, which makes it hard to follow when you don’t know them. And yes you can over abstract and divide into infinity … but it is not that GH Script Components are a super large code base. You don’t have to master OOP to script some polylines and cubes together…

4 Likes

I would just like to commend what were @TomTom and @Dani_Abalde saying about organizing the definitions.

I have to say that after implementing Snapping Gecko, Telepathy and Showcase Tools in my workflow, I tend to stay much more organized and the definitions are much more “readable” and “sharable”.

This is a beginning of a definition where I’ve spent 5min top - grouping some stuff.

  • I like Snapping Gecko because “I’m one of those people”.
  • Telepathy enables me to have a single Control Panel on the side, and have all the necessary outputs always neatly named and I’m always able to rename “senders” where all the receivers will be renamed appropriately as well.
  • Showcase Tools - it’s blasphemy but I like straight connection lines more since I think they are much better for visually following the flow.
    Also the “visually differentiating wires” that Tom proposed, is a huge plus in my book. If Gh2 could implement a universal coloring convention so that I don’t always have to have the legend up on screen or create my own coloring schemes since the current categories are a bit of an overkill.

Also, what Dani said about clusters - opening and closing right there on canvas with different levels of abstraction - YES.

I’d also like to have the ability to make text larger on some components - ex. in Telepathy inputs/outputs, so when I’m zoomed out, even though the logic’s icons and texts are hidden, I can see the inputs and outputs.

And one last thing - it’d be nice if, in the “middle click” widget, we can have a subcategory to put our own components - something like the Axon Widget was doing.

PS. The new Hops component is brilliant, please keep that one.

Cheers.

3 Likes

Hey,

I just returned to Rhino 7 and Grasshopper for a Design Project after a couple of years mostly working in SideFX Houdini.
They have the node workflow down to perfection and I’d like to mention some of the things I find very painful in Grasshopper compared to Houdini to maybe see some improvements there or be made aware of solutions or workarounds, some I’ve already found here.

  • One very handy thing in Houdini I use all the time is shaking a node to disconnect it completely from all connections. That is something many node apps have these days and it’s very intuitive.

Showing some of the things I mention here in a little gif:
HoudiniNodes

  • I find disconnecting wires in Grasshopper a pain - I hope I’m missing something.
    In Houdini you hold down the Y key and get a scissor mouse pointer. When you now drag it over cables, they are cut. Awesome! :slight_smile:

  • You can also drag a wire into open space from a connection and it disconnects it. Very intuitive again - unplugging.

  • Interestingly, deleting a node in Houdini leaves the wire intact.
    But even more helpful is being able to drop a node onto a wire and it will try to connect to the ports that make the most sense. Inserting nodes in an existing wire connection is a major pain in Grasshopper it seems?

  • Another thing I found annoying is, that copy and paste always pastes the nodes to the place where they come from. In Houdini they land in the center of your current view instead. So you copy something somewhere, move to a different location and paste and there they are. You don’t go hunting them back where they came from. So simple but so much more useful.

  • Another thing I ran against all the time now is connecting far apart nodes. In Houdini, you can click an outlet and it’s wire will stick to the mouse pointer. You can then move the view and the wire will follow you. When you arrived, you click on the inlet you want to connect to. Works very very well.

  • The wire style in Grasshopper is the worst I’ve ever seen in any application using nodes. These gigantic arcing bezier curves are pure horror in a busy network. Thanks to this thread I found Showcase Tools and they make it better (with a cost in performance), but IMO this belongs in the main application. In Houdini you can have straight and curved lines, but the curved ones don’t overshoot, so it always stays readable and doesn’t overwhelm the whole thing.

  • Also snapping - thanks again for mentioning the Snapping Gecko - belongs into the main app since it simply makes things so much easier. It’s not just about OCD preferring orderly structures, but keeps things clean and easier to read. Houding has both a grid to snap to and automatically can align nodes. Snapping Gecko is almost overkill with all those lines and stuff, it could be much lighter and simpler and still help with keeping things together.

  • One thing I really struggle with is the viewing options. In Houdini, you always have one node active and that is what you see as your output. Every node has that blue toggle and that makes it the active one. This also means, that everything downstream from that node isn’t computed. Huge time saver!
    In Grasshopper, I never want to see everything. But the only other option seems to be, to have the “selected only” view active, which of course is getting lost all the time when working. I could probably do away with all the damn data dams - I never ever wanted or needed one in Houdini!

  • Another thing is, that in Houdini, every node can be disabled with another button every node has. In Grasshopper I got crazy with always hitting the right mouse for stuff one needs to toggle all the time. Some things make so much more sense to have always visible and directly accessible, since otherwise you multiply the clicks needed for the simplest things.

  • But the main issue with Grasshopper - and that is the very reason I left for Houdini many years ago - is the abysmally bad performance. All my cores but one are sitting there doing absolutely zilch, nothing, nada. In Houdini, everything is absolutely tuned to perfection to use all the computing power possible. Everything is multithreaded, there even are compile nodes that you can use to enclose a bunch of nodes and then those are compiled into one assembly to run even faster. I can have millions of points and curves and stuff in Houdini in realtime where Grasshopper chokes even on my current simple Network each time I change a parameter. Outch!

  • Speaking of parameters: I find it totally silly to have sliders and all the other input elements update on every move of the mouse with not even an input-delay that only updates every couple of seconds. Why on earth would I want that?
    It would be so much better to work with if updates would only occur on mouse-up. Or at least have that as an option.

I can really recommend having a look at Houdini to everbody interested in a very very good node system that performs brutally well even on a rather modest machine like mine.
But mainly the whole workflow is extremely well executed.

But of course Houdini isn’t a NURBS software so this is why I’m back :slight_smile:

Sorry for the wall of text but that is the result of my easter weekend… :wink:

Cheers,

Tom

21 Likes

That’s an awesome suggestion!
But you can paste in the center of the screen.

Paste In Center

3 Likes

increased performance by far. A C# component wouldnt need everything to recalculate each time if its not used, unlike this cluster logic which recomputed all the cluster all the time. Object Oriented Programming and loops can be dramatically more efficient.

I agree with most of this. The only issue is that Houdini gets away with a lot of these things (wires reconnecting on deletion, bypassing nodes without rewiring, etc.) because it deals with attributes rather than list matching. It would be quite difficult to resolve those things in a list matching scenario because how would you know what wire should go to what input etc. (not to mention all the data types in GH that aren’t as convertible as Houdini to other data types).

It would at least be more appropriate to compare Houdini’s VOP network interface to Grasshopper’s rather than Houdini’s Geometry network interface.

1 Like

I’d vote for parallel computing…

2 Likes

The problem with that is more on Rhino’s side. I think this is one of the earliest suggestions. Grasshopper’s canvas is perfect to display parallelism. You could handle parallel computation and (its ugly sister called “synchronization”) much better with nodes, as by code. This is actually one use-case where visual scripting potentially is superior to direct coding.

Parallelism is not a guarantee for performance increase, especially if the causes of a bottleneck are not identified correctly. Even under perfect conditions (=unlikely), if getting the full potential of an advanced CPU, it might only give a performance boost of factor 30. Sounds a lot at first, but if you consider the roots of evil, you can increase performance much higher if you care about algorithms and data.

I see performance issues in Rhino rather due to the fact that many users simply don’t care about geometrical quality. Fitting or intersecting thousands of heavy surface patches is just a dumb thing to do, but maybe it’s just the result of lacking surface tools. If you cannot properly match surfaces just as you would to directly in Rhino, people misuse patch components and then wonder why the definition and the document becomes unresponsive… Using a proper modelling approach definitely improves performance by equal or a much higher factor, without any further optimization required…

Although I had some cases where parallelization simply could have saved some hours of computation. I helped myself by just open multiple Rhino and GH instances and divided the task.

1 Like

I agree Michael, but the drop-on-wire works in the VOP interface too on a best guess basis.
I’d rather have it be right 95% of the time instead of 0% as it is now :wink:

And with easier dragging of a wire from one input to another that could be improved too.
I forgot to mentioin that in my list…
I just find the whole wire-dragging in GH to be really superclicky…

And don’t even get me started on list matching. After some years in Houdini, the list matching feels like being hit with a hammer on the head constantly.
Attributes are sheer bliss compared to this…
A complete secondary layer of computing instead of just giving things names that make sense…

Thanks @11159 Masaki for the tip, a bit convoluted for something I’d want as the default but will work!

Cheers! :slight_smile:

Tom

Personally I don’t care about the auto rewiring as I think it would honestly cause more problems than not in GH (a wrong guess could be detrimental to the process if the guesses lists don’t match properly, what if it is a list editing component you deleted?). It would be cool if you deleted a component and the wires kind of stayed there and you can then rewire from current location. Also, cutting wires would be fantastic :smiley: . Houdini gets away with a lot again because of attributes logic and pretty consistent auto data conversion. Lists are the main reason the best guess rewiring will never work in GH.

For instance, what if I deleted a graft component, now the flat data pre graft will plug into where the grafted data was needed and my computer will now need to do millions of calculations, and most likely will freeze or crash.

4 Likes

Well, it’s no wonder this happens, because many of the more advanced sufacing tools (match surface, blend surface, sweep 2 rails with continuity options, etc.) don’t exist in Grasshopper OOTB and some may not even be in custom components. I am only aware of a blend surface component, someone else made for me in another thread.

Drag and drop in between wires would be possible if the components are automatically disabled from computing with a HUD click to enable computation. And it may very well work if you use it on geometric components imo, input points > create curves, those relatively simple things. I am no programmer myself, but I can imagine checking data types and matching them with inputs (points to points, curves to curves, etc.) but yeah list structures could definitely cause crashes.

1 Like

I would ditch the C# script component and go for my own suite of compoments itself. Takes a while to get going but once you have a solid framework of your own most-used code snippets you can get them out very quickly and with way more functionality than you can with standard GH components. Think about not loosly attaching information to an item in a list but fully-fledged objects with properties and such like naming standards, fabrication rules etc straight from and to database and into different file formats to deal with clients.

Granted, that all is overkill if you project is just a single GH-document big. But given that the screenshot is just a cluster in what might as well be a abundance of many more different clusters, visual programming is quickly reaching its limits.

Also, if you have a good framework for your daily tasks, streamlining your projects might be worth it after the second or third.

Again, really depends on your project requirements and size, might not be worth it at all. The whole “i cant code” aspect solves itself once you write a couple of (ten)thousand lines. Its a question of practice.

2 Likes