Yes that us what I was referring to. Linetypes with widths in non-pixel units are printed at those thicknesses. Only pixel widths get overridden by print widths when printing
Ah, excellent.
This is one of new features in R8 I havenāt fully explored yet (along with Layouts) ⦠looks like I have my next summer learning project for myself this week.
I think some of my drawing and MDES students will really appreciate these features!
+1 ⦠although I do think there is a huge amount of overlap at the beginner level.
As students branch out into more specialized usage then organizing by field / application could be a great way to structure the learning modules.
Absolutely Yes, agree on the overlap! And yet Iāve found my students get engaged much faster if I begin and continue with exercises related to their field. Somehow it generates that initial excitement that helps them dive into homework and the necessary practice time between my classes.
100% agree. We are having a lot of internal discussions about how best to do this.
How about making an official Grasshopper documentation / online help already ?
After 17 years, that would be nice.
How about an open-sourced documentation website where everybody could contribute with simple PR and it will be supervised/approved by mcneel? That would be amazing, for our course we did create a new documentation for those missing part but many are already existing somewhereā¦
I actually love that ideaā¦
Sounds like a wiki website.
@brian maybe knows if this is possible with the existing one.
Thatās how the Rhino Wiki was intended to work at the beginning. Unfortunately, with open enrollment, itās hard to keep people from posting junk and even ruining other peoples good info. So access to edit the current Rhino Wiki is now restricted to only a few people. They also havenāt updated the Wiki software for a long, long time, itās considered as āend-of-lifeā. Thereās still a lot of good info in there, but much of it needs updating with new info on the current Rhino versions.
Hi all, great to see all this feedback to create a more focused learning experience.
Some things Iād like to add based on my experience hiring designers with zero or minimal Rhino knowledge and then guiding them to become proficient:
-
Rhino Default, IMO and for our use, itās extremely limited and limiting. I would have never kept working with Rhino if it wasnāt for all the advanced tools, macros, scripts that allow us to be productive. A 1-STEP way to save, backup, restore, replicate your custom setup of Rhino is a must. Any kind of training besides the most basic will require custom toolsā introduction and installation.
-
Current fillets situation is a non-starter for a lot of people. When someone asks me to recommend them what 3D software to use/learn I can never recommend Rhino for this reason. Like Sky said: once you are a proficient modeler you probably never use fillets, unless itās for internal structures or fixtures, but still, the current functionality is just unviable for more user adoption.
-
Outdated training guides are outdated. I already brought this up and I was told I was wrong. I donāt want to argue about this with McNeel staff, just like I wonāt argue to that restaurant owner that insist in not updating their menu and ambiance, if I lose excitement about going there I just stop going. This old stuff needs to be put to bed and start over.
-
Quick snacks learning series is needed.
Look at what William Vaughan is doing with Plasticity, most videos are under 40 seconds each:
https://images.app.goo.gl/mMPjgs8wBUMEns8w8
Rhino should have something like this with embedded links right inside Rhino on desktop and iRhino. And a unique URL link for each video. There should be a good video for each Rhino tool/command.
- Professional/Corporate continuing education program needed.
Most users donāt hang out here on a Sunday or as they have their morning coffee, so they do not know what new tools are being developed. Especially people who learned with Rhino V4,V5,V6. When companies buy an upgrade for their team having an option to bundle (with an upcharge) a 1-day āwhatās new in this versionā training day would be nice.
I hope this helps.
G
Iām mainly a user (have been for over 10 years) - most of it in Grasshopper mind you. I do occasionally teach or help other users out.
The biggest issue for me is NURBS modelling. If Iām being truly honest, I donāt think I truly understand the best practices or even the requirements for a good model. If Iām surface modelling, things start out ok but quickly devolve into a bunch of weird trims and surfaces with terrible continuity. Iāve watched videos, read articles. Some of it sticks but I really donāt have a 100% grasp on it. I think part of it could be as far as strategies for how to approach slicing up the part into multiple surfaces and not painting yourself in a corner. Always feels like demos are so much less complicated than what Iām working on. Really solid content here would be helpful. Donāt know if the software could help point you in the right direction as well?
And yes, fillets. Itās not funny anymore. Such a big hurdle to completing projects or just getting excited about the software as a student.
great feedback thanks-
have you seen this serie? itās the best out there for learning Nurbs best practices.
Adding my 2 cents late to the party⦠talking about GH.
I could say more if we had similar thread like this one and the other āAttention Studentsā⦠but about Grasshopper.
The same way we would like to have a single global file to manage all Rhino settings and UI preferences, Rhino .3dm files should have a way to internalize .gh files.
Similar to what was done to textures, you set them up, and then you can even delete them in OS space, Rhino will keep a copy.
While I fully agree having the option for separate .3dm and .gh files is a must, Iād say very often my students forget to save the geometry bits used in a .gh definitions ⦠or to internalize them.
Having to manage another file (.gh) alongside with your Rhino project, is bothersome even for experienced Rhino users.
Even for my projects, .3dm have incremental 001 , 002 , 003 ⦠152 etcā¦
.gh files? I find myself manually synching its names to identical to .3dm ones to avoid future confusion⦠Not awesome.
Often .gh files are under the 1MB size.
Having my .3dm files ārememberā internally a copy of one/some .gh files should cause very few problems.
_Purge command will then have option (default false) to remove any attached .gh file, same way of textures/materials.
About teaching Grasshopper, we really need a way to translate the UI⦠Itās already difficult to grasp the logic, I can only understand students feeling overwhelmed if they also have to Ā« learn Ā» the language
I would love to see a mapping table between rhino commands, rhinoscriptsyntax, Grasshopper Components, Rhinocommon Functions / Datatypes
is this what you mean ?
or are you talking about really translating grasshopper into other languages ?
My one and biggest problem with Rhino/Grasshopper is exactly that, users need to manage a bunch of files, and if one is missing, or if one of the libraries used for the definition isnāt installed, then suddenly the file is missing geometry.
Making working on the same file from different computers, or by different users, something that has to be carefully thought through.
And if you are a compulsive modeler who constantly improve and alter your favourite scripts then suddenly old Rhino files who used an old version of the script wonāt work any more, because the new version is doing something different.
I have always supported the idea of having an option for embedded gh definitions, it could be as simple as having both, just like we use referenced or embedded linked geometry.
In many cases you are not interested in reusing your script in the future, you just want to solve something explicit for the project, and thatās when embedded gh scripts would shine the most.
My point is: Keep it as simple as possible for users to use and master, and it will be easier to teach. Same goes for materials, lighting, environment and rendering, keep it as simple as possible to use and master.
Regarding teaching I think the most important thing to do is to catch the users attention. Make them want to do the tutorial, the objects design must look good and always (for designers) end in a good rendering. Split the best tutorials up in modelling and rendering, and supply the geometry in case they just want to focus on the rendering. Most users use Rhino as a goto test-the-shape-program and then move on to another software for finalizing the design, so these early stage shapes needs to look great! If you can make the students dream then you can make them learnā¦
Hi everyone!
Iāve been teaching Rhino since 2010. I believe I took the Rhino Trainer course in Barcelona around 2013, but my journey with Rhino began in 2006. Over the years, Iāve noticed some common approaches to teaching.
Many instructors focus heavily on the software itself: āHereās what we need to achieve, so letās find the commands and start building surfaces. Weāll figure it out as we go.ā
I take a different approach. I prioritize teaching students how to think in 3D before diving into Rhino. We incorporate a lot of drawing and design thinking exercises upfront. This helps students understand the project before translating it to 3D, leading to fewer mistakes and a more efficient workflow. While this isnāt the only method, itās crucial in production environments where time is limited for trial and error.
Perhaps my explanation needs clarification. Letās discuss it further if you have any questions!
This is a good approach. I imagine other teachers wishing to follow similar approach can benefit from your insights. I have a question:
What would be a good channel/format to share expertise and resources with other teachers?
Maybe it can be a Discord server with different channels with clasified information. In there we can create text channels, voice channels, attach files and more. Itās just an idea.