Hello! I’ve been using both grasshopper and houdini for a few years now and I understand they both serve different purposes. However, for similar tasks, houdini is blazingly fast compared to grasshopper which I think is because it utilises multiple cores of the cpu whereas grasshopper is only single-threaded. Why can’t grasshopper be multi-threaded? I am working on large projects at the moment which need a high level of detail and resolution and fairly simple nodes take grasshopper a long time if the resolution of the command is pushed up. I think this also makes it less effective for it’s intended use for large-scale architectural projects. (Side-note: I love grasshopper, no disrespect intended)
Hi,
this question is asked quite frequently. The answer is not easy. There is multithreading in Grasshopper and Rhino, and the application works concurrent. There is room for improvement, without any doubts. But there is simply not always a real benefit for parallel computation. It can even slow things down.
That you see a difference in performance is rather because of the fundamental difference of both apps. Its a bit like comparing apples with oranges.
A Nurbs-modelling software represents a shape in parametric equations. That makes it computational expensive. Its also harder to divide operations into atomic pieces, which is required for running things in parallel. Performance gets worse if you work with overcomplicated geometry. Every degree, every controlpoint, a higher span-count makes a computation more costly. I have seen catastrophic models made in Rhino in terms of shape quality. It is rather the norm.
On top of that, people often don‘t know what is slowing the computation down, they guess with confidence, but often they simply don‘t know. You have the option to improve performance in many ways. But the most important formula is „garbage in = garbage out“
I could go on with list, but you know what. Many of older Rhino/Gh users her did fantastic work 15 years ago, when the computational power was much worse. Sure with a some tricks and hacks involved, but it worked. I‘m not against improving the performance, the whole ecosystem could be faster. But its fascinating that with every year, every improvement in hardware, Rhino becomes subjective slower 
To sum it up. Take it as it is, probably it won‘t change soon. Make the best out of it, and learn how to write your own performance optimized scripts, if you care. Or do something good for yourself while the computer is working for you…
4 Likes
I’m not sure what the fastest Rhino-canonical way to go about animation or rendering large jobs is (Rhino Compute?).
But FYI, multithreading looks like it will be a key feature of Grasshopper 2.
I understand the difference for NURBS based modelling, I guess my question is more related to mesh operations, as that is what I am using at the moment. Meshes are becoming increasingly used in the Architecture field and working with large meshes in kangaroo for example is slow/ doesn’t work. I’ve worked for two years as a VR developer so I understand optimisation to a very fine degree, but for complex and organic geometries it would be great if grasshopper would work with the same power as houdini!
Hi @joestoeger,
Do you have a specific example (or examples) of where GH is slow and you wish it were faster? Or is there a specific component (or components) you’re needing more performance out of?
Thanks,
– Dale
1 Like
Not that you asked me @Dale but if any components were to be sped up. My wishlist would be the boolean operations. Solid Union, Solid Intersection, Solid Difference, and I guess Solid Trim.
I’ve seen/used various plugins that attempt to handle these multi-threaded and thankfully the GH2 versions (when I last tested) seemed pretty zippy.
Any info you can point me to on speeding these components up would be greatly appreciated, thank you!
1 Like
I wish TriRemesh was faster.
2 Likes
I think we are mixing things a bit here. On a production model a parametric representation is always an advantage for various of reasons. E.g. from a surface model, you can calculate a mesh, and adapt the mesh for you needs. If you do VR visualisation you can dynamically tessellate, based on the importance of that surface for the viewer. If you simulate, you can convert it into a different type of mesh which is better suited for FEM. If you mill/print a model you can also tweak the density for your needs. You can also analyse geometry much better with a surface model. You can calculate sections, with proper curves etc.
If you calculate a boolean union for instance, doing that with a surface model is more reliable and can also be faster, in certain cases.
The reason why people in architecture are preferring meshes over surfaces is of different nature. If you create a fancy free-form shape, there is a lot knowledge involved to that. As someone with a partial background in architecture, I have worked in automotive R&A for quite a while now. I’m pretty sure the average architect doesn’t have the time, nor the tooling and the knowledge to produce proper surface models. Working with meshes is a trade-off. Producing meshes in a Nurbs modelling software is a trade-off, and using a Node editor (=GH) which simplifies automation is a trade-off. I’m pretty sure there are better and more efficient ways, like using Houdini, to produce mesh geometry. But a lot of how you experience performance and compare it to other tools, is biased by an untypical workflow. Why should Rhino become so much better with Meshes, if its purpose is to create Nurbs models?
3 Likes
Meshes aren’t simply a way of avoiding the complexities of NURBS.
There’s another significant architectural application of meshes this misses, which is panelisation.
Much architecture is built up from discrete non-curved elements such as beams and panels, and there are stages of the process where modelling these with NURBS would have no benefit and meshes are more suitable.
There are also many types of optimisation for such discrete structures that have no analogue in NURBS, for example much of the work of Bobenko and Pottmann (and which have tools to do in Rhino, but not in more animation focused tools like Houdini).
3 Likes
Interesting.
I’m at home at the technical side of product design. Many of my projects start with a 3D scan. I wouldn’t describe my workflows as typical. One reason I’m using Rhino is because it allows untypical workflows and going back and forth between different types of geometry. And as you mentioned, pretty much whatever we do is a trade off…
3 Likes
5 Likes
Is that course publicly accessible? I’d love to peak 
Afraid not, but I’ve been meaning to at least get the third course slideshow out there (on GHPython). Thanks for the reminder 
2 Likes
As a Python newbie benefitting immensely from your help I would love to see that, thanks!
1 Like
I mean in the end Rhino is the Swiss army knife of CAD. It can do a lot, but its probably not your best tool for your job. And because Rhinos most important feature has shifted from Surface Modelling to CAD automation, I would guess that somehow the mesh tooling is becoming more important for a certain group of people an their tasks, nowadays. Still, when we talk about importance why meshes are preferred in architecture, I still believe its to avoid the complexity when dealing with surface data and not so much the redundancy when dealing exclusively with non-curved geometry. Anyway, this all is not really related to the initial question. I just think when you put a lot of attention to proper modelling and detail, you can indeed create shapes quite efficiently in GH. Definitions become slow, when you do more than you should do, and when you don’t understand what is happening under the hood. You always find ways in improving performance, but of course you need to understand where the bottleneck is. I have seen a lot of slow definitions, because of inefficient data piping.
Not everything can be multithreaded….
Nine women can’t make a baby in a month!
8 Likes
I use meshes to have approximation of surfaces, to pre-build topology, to detect collisions, for fast visualization, etc etc etc… all this, as you said, while my final target is still a Nurbs model! Indeed!
That’s the difference from having a tool that compute and display real-time from a tool that lags at any input change and feels on a 386.
(By the way, imho, Rhino is already more than good with meshes.)
Could we do everything with pure nurbs? Maybe, but it would really unwise programming-side (extremely slow performance and sort of unreliable/unpredictable results). Happy 386 performance!
Faster mesh methods would be gladly welcomed by all, because we happens to use meshes to create nurbs. Look at SubD: SubD are meshes … but SubD are also nurbs!
(I’d really love to have SubD methods on par with Meshes. Currently SubD rhinocommon is a joke…)
Me too. Faster and more reliable.
Is this true?
Anyways.
I recall back in the early 00’s, when SubDs became the preferred option in the CG industry. Folks liked using it for better UV mapping, and for its multiple subdivision levels, which were essential for sculpting with ZBrush, for example. Sure, they compute much faster than NURBS. But they often have a different use case.
I think some confusion may arise when use cases overlap. There are many scenarios in AEC in which you could use either NURBS or SubDs. But as a rule of thumb, if you don’t need double floating point accuracy, than maybe you don’t need NURBS (yet). If you’re not designing something curvalicious, than why not just go with meshes? Rhino has gotten much better with meshes, and with time I’m sure it will only get better (hint hint). I use meshes more often than NURBS, and GH performance on large models is totally fine for me. Just saying.
and QuadRemesh to be faster (in grasshopper and Rhinocommon)
SubD surfaces are not NURBS surfaces. However a SubD surface us an exact NURBS polysurface equivalent except near any extraordinary/star/special points.
The equivalence does not work the other way. Many NURBS surfaces and polysurfaces do not have an exact SubD equivalent.
1 Like