Attention Students- What barriers are you facing when learning Rhino?

Grasshopper documentation sucks.
python for grasshopper doc is totaly absent.
googling for a module, is not the best as you don’t ever get the right command, or you get into old and deprecated stuff. generative llms are usually worse as they allucinate/are based out of google. search through the docs sucks.
looking at random video about how people do stuff, is more than often a waste of time. I don’t want a hour long video for a single command, I want at max 1 minute thing that shows me the command I am looking for, not a dude ranting
Also from random resources online grasshopper blocks often do not have the full name display, so I have no idea what it was used to begin with

Also some improvement for the main sw:
rhino and grasshopper have the same functions under different namings why can’t they be the same? it should also be nice that whatever you do on rhino, grasshopper would automatically build node for it, as it happens in houdini or maya (the latter is a mess though)


thanks for this- I appreciate your feedback.

I agree on Grasshopper, it’s been a struggle to learn it well. Have to track down random YouTube videos that are not to the point makes it a challenge. I end up giving up on it and going back to normal Rhino or one of my other CAD apps to be productive.

No, I did not see these before. It must mean they are not often referenced here…
Some have nice explanations, like the “Small corner case”, but it’s not complete and we don’t see Pascal actually creating the fillets.
I feel like the most important notions are not explained in this playlist and a lot of time is spent in tools that are more traps than really useful. My thoughts about fillets in Rhino:
-FilletEdge is used often but only on the most simple prismatic geometry.
-Tools that tries to mimic the behavior of SolidWorks (and the others) are traps. Again, they will work sometimes, but not when they would be really useful and save time. Rhino does not have the hundred of edge cases, with code to handle them, as Parasolid has.
-FilletSrf can get the job done in all situations. It also help to create better models because errors are seen immediately (for example, non-tangent surfaces produces fillets which ends do not align). When you catch such errors this soon, it’s a lot of work that is spared.
-Specific techniques like when to use or not use the “Extend” option, when to trim the base surfaces (and how to detect when you’ll need to keep a copy of a base surface handy because it will be all consumed but still needed to generate another fillet)

What I mean is that posts like Why are fillets so bad? are coming in weekly.
McNeel can put all its ressources into adding cases to the FilletEdge algorithm but it will never compete with Parasolid.
Best is to use its strength to help user create clean simple fillets using FilletSrf. It’s a matter of knowing how and where to start and it’s not much more time. And it’s for better results (Parasolid often takes liberties and create problematic geometry that bites the user back downstream)

1 Like

Thanks for this feedback-

I haven’t seen much talk much about Layouts yet. I come from a mechanical engineering background, using SolidWorks. I promise this isn’t going to become a “make Rhino more like SW lol” request, (well… Maybe a little :sweat_smile:) but I do think that Drawings are something SW does well, and think that Rhino could take a few cues from the mechanical packages to make Layouts more accessible.

First, training material on the Rhino site and on YouTube. Having spent time viewing lots of guides and tutorials, I was reminded of a post I read made by @sgreenawalt some time ago in a thread about how to learn surface modelling, where he said words to the effect of “there is an ocean of material out there, it’s hard for beginners to filter the bad advice from the good, and there is considerably more bad advice out there than good advice”. I feel that applies to Layouts too. Having spent the last week researching and experimenting with how to format Layouts, I bet I could write more concise documentation about how to properly format Layouts than what currently exists. I’ve seen numerous guides where the presenter will start with a blank sheet, complete their drawing, then draw a quick and dirty title block. This, in contrast to my expectation where I would start a Layout, import a sheet with my border and title block on it (with intelligent fields that auto-populate with key information) and then begin my drawing. This is actually very easy to do in Rhino – but a student wouldn’t necessarily realise it looking at the training material out there. To give credit where it’s due, I thought the video from @mary (water bottle one) was great and covered lots of useful ground - but outside of that I learnt more from just experimenting with Layouts than reading training material. TLDR; the training material could do with a bit of spring cleaning - it’s a little bloated and I feel there is advice in there that might set students down the wrong path in some cases.

Next, annotations in Layouts. Rhino is missing a lot of annotation features that I would expect to find in any drafting package. This is another barrier I expect lots of students would trip over. Balloons, multi-leaders, GD&T symbols (to name just a few) – all seemingly missing. As with most things, I’ve found these can be worked around with a little creativity, but it makes producing Layouts needlessly fiddly and time consuming. My suggestion would be that McNeel simply takes a look at the annotation capabilities of any of the mechanical CAD packages and consider adding similar annotation features to Rhino.

Detail views. This took some getting used to, but once I realised how Rhino detail views actually worked and how to set the scale, I was on board with it. What I am less keen on is the lack of ability to simply project views from a detail. I am guessing this may be too much to ask and that it isn’t so simple, but I yearn for the ability to drop a view onto a sheet, and quickly project it left/right/up etc to easily get my first/third angle projections. This is how almost every other Layout/Drawing software seems to do it, even AutoCAD. Having to place multiple Detail views and then carefully align them to make sure my projection is correct can be a little excruciating, and I would not call it intuitive. Much harder to teach this to students who are used to the ability to quickly make third/first angle projection drawings by dropping one view and going from there. What’s odd is that the capability arguably does already sort of exist, in the form of Make2D. Speaking of which…

… Make2D. I think I understand why it exists, and see its utility. But the amount of training material I have seen out there suggesting you make Layouts with Make2D as opposed to Detail views with 3D is insane to me. I’m not saying kill Make2D by any means, only that in my opinion, it shouldn’t be seriously considered as the means of making a Layout – unless you really need to. Like when, for example…

… Bugs stop you in your tracks. In Rhino 8, when I print/save PDF Layouts in vector, I sometimes have lines disappear for seemingly no reason. Please fix this – any student coming up against software that won’t behave as it should is going to suffer :smiling_face_with_tear:

OK, I think that’s long enough. I should add that I am actually quite pleased with Layouts and underestimated Rhino’s capability. When I first started using Rhino I never even attempted to make drawings in it, as I had access to SW to do so. Now that I am doing it all under one roof, I have found Rhino is performing fairly well - though there’s no doubt in my mind that it’s easier to teach 2D documentation in other packages as opposed to Rhino. Hope the feedback is useful.


Hi Ruri -

Use the FromDetail option in the Detail command. I always create new layouts without any details and then use my custom “DD” alias to place a front view, and my custom “DF” alias to place a detail from that first detail.

Things generally don’t get fixed automagically, but need 3dm sample files that can be checked. It’s possible that what you are running into is already on the list, but, by not providing a sample, you are running the risk of an issue never getting fixed.

Apart from that, vector printing was added very late in the development cycle of Rhino 8, and, perhaps we should have waited for Rhino 9. For a lot of simpler cases, this is actually working quite nicely, though. This is also an area of Rhino that is very actively being worked on for improvements.


Please don’t say this.

We do appreciate all the effort that you guys are putting in.

If we are bashing you guys in the open, it’s only because of the space given to us by you guys and also due to the high expectations from McNeel team.

Vector printing was long overdue. Rhino 9 would have been too late.

My only problem with McNeel is the priority list in which mew features are getting out.

For example I could do with much better filleting and dynamic blocks than a script editor especially when people who do all the scripting stuff are already more accustomed to the more powerful hops workflow. Script editor seems to be the last thing on my mind.

One thing I feel McNeel can do is get a voting on features on discourse before alloting resources to it.


… Huh, well what do you know - this is exactly what I was hoping for. Consider me humbled - thank you for the useful tip! (Though in my defence, maybe this proves my point that the training material could do with some spring cleaning given that I missed this until now :crazy_face: )

Understood - much as I’d love to share the troublesome files, unfortunately I cannot as they’re under confidentiality. I’ll be sure to share other files where I can should the issue pop up again to help you find fixes.