Hi, I am a university teacher using Rhino + GH in architectural design courses. Interesting topic and many points that beget wider discussion. Other than what other contributors have already pointed out, Iād like to weigh in with my proverbial 2 small coins.
general considerations
For curriculum reasons, students in my courses do not have a prior introduction to the software, so I have to build a bespoke learning path aimed at putting them up to speed in a narrow part of the tool that is relevant to the course, with the minimum possible conceptual baggage (i.e. geometry, mathematics) attached. This does not mean to take away the primary means of climbing the learning curve (practice), only provide orientation and unlock as soon as possible the tool as a means of expression for (and not a barrier to) architectural-related concepts.
Iād like to point out that, despite my specific approach, I think learning paths and use cases of Rhino are incredibly broad (in scale, size and scope), so customization is key, and my considerations try to generalize a bit from my narrow corner (but I understand that others might find my suggestions counterproductive for their scenarios). For introductory purposes, the most relevant points of a good tool for me are:
- easiness of use and confidence (how fast it facilitates going from zero to a āHello worldā kind of output - good confidence at the start encourages going forward)
- the flexibility to build/customize a learning path.
Both of these instances depend on two things in my opinion (other than being robust and reliable of course): a well-structured, clear interface and well-structured documentation.
interface
Blender adoption made the biggest leap after its interface improvement (of course it was already solid enough at that point); I consider Rhino 8 a step in the right direction, but (as many other users have pointed out in the forum) thereās still room for improvement. Currently, Iāve noticed that many students are intimidated by the tool and are reluctant to open it (this drags practice). Window Layouts are a big step forward, maybe providing more presets other than Drafting and Rendering (i.e. NURBS modelling, Mesh modelling, SubD modelling, etc.), and also ābasicā and āexpertā default modes might improve the situation. One of the powerful features of Sketchup for example is the simplified interface: more complex commands are available (and can be revealed) but do not appear in the default interface. The persuasion of simplicity was maybe even too powerful, leading to the diffused preconception that Sketchup could not do certain things that were simply hidden. The center of my argument here is the impact of the interface, not the softwares I mentioned.
documentation
By āwell-structured documentationā, I mean (other than fast and easily accessible) a structure with these āverticalā levels:
- concepts
- tools
- techniques
- examples
Tools and Techniques are the landing pages one usually encounters from the command help; these should have links upward to higher abstraction levels (concepts) and downwards to practical use cases and examples (that can be gathered also from the forum).
Usually one enters the documentation at the point of tools (what a command does, ex. Control Point Curve) and/or techniques (ex. āhow to blend 2 NURBS curvesā) which are in a middle ground between the concepts (with both intuitive and mathematical explanation of NURBS curves, degree, what control points ARE and what they DO) and the examples.
Examples might range from technique-related (ex. curvature control with control points, ensuring continuity according to degree, etc.) to practical examples in multiple applications (ex. design of contours for a shoe, streamlining for an object, path in a garden for landscaping, etc.). Extensive case studies in relevant fields (such as the Morpheus Hotel webinar) are also very good references to include.
Concepts can be structured putting intuitive explanations in the foreground, but with links to the mathematics and/or deeper, more accurate explanations with links to dedicated pages (even external but well-established references such as Paul Bourke).
Ideally, one should be able (and somehow invited to) navigate this documentation vertically (from concept to examples and vice-versa, no matter the entry point), as well as horizontally (connected and/or frequently paired commands).
pain points
- (not strictly software-related) understanding geometry orientation and direction (especially for generated geometry via GH): why the normal of a surface or Brep face points a certain way (or why offset is outward or inward) and how it depends on orientation/direction of the lower-dimension geometry used to create it.
- separate unwelded vs welded vs smoothed mesh representation: right now, a welded mesh is also represented as smoothed (same smoothing group for all faces), and there is a confusing behaviour when editing unwelded meshes (overlapping vertices are treated as one but the mesh is still unwelded)