I think that is what @ec2638 tried to say.
No, I wasnât trying to be a smart-ass this time. Iâve always appreciated the concise, tight, on-point documentation. Very effective and perfect, IMO.
Pretty clear none of you replying to my suggestions actually work for McNeel. Because of course the first thing the McNeel person would say is âThank you for taking the time to make these thoughtful suggestions.â
The documentation is very concise. True. It is also often incomplete and sometimes just plain wrong.
I have wasted hours because of these incompletes and wrongs.
And McNeel may be loosing sales. Iâll give you a scenario:
Mr Big is meeting with McNeel sales people. He represents a consortium that is considering buying Rhino - some hundreds of seats worth. He has his top tech guy by his side, who has now spent quite a few hours trying out Rhino. The tech guy says, âWell, there are a lot of good things about Rhino, but I think our people will waste a lot of time because of the low quality of the documentation.â
You are sitting on the McNeel side of the table. You can say âOh, I think the concise nature of the documentation is perfectâ. Or you can say âMillennials donât read documentation.â Or âŚ
âŚand for offline users Rhino 6 has no documentation at all.
⌠although that is being worked on, afaik.
Hello,
Do you think the discussion will even reach the stage of asking the question about documentation? If McNeel was interested in decreasing their substantial documentation load they would start changing the UX for the better. When a product is more usable there is less documentation required and fewer questions asked. Downsides? Short term pain and expense. McNeel is probably doing well enough that they arenât pressured to change. Problem is theyâve set themselves a pricing ceiling by doing so, if they are forced to increase end user cost they may find themselves playing in another product tier.
so what?
doing things wrong is never a waste of time, I would rather tell it learning. Its hard and time consuming.
If you know how to hold the brush its unlikely to know how to paint. If you know how to paint, you wonât
have a hard time learning to hold a new type of brush. I could go on with dozens more of these chinese fortune cookie advises⌠but its how this world works.
in my experience, its much more likely that mr big believes Rhino is not good, because its named after an african animal and costs only 800 bucks per seat⌠How can something so cheap be good? We all know better, but thatâs what my previous boss told me years ago So they buy it as a tool just to have, if needed⌠nobody caresâŚ
Care to share an example? I´m more on the âis just plain perfectâ side.
Hello,
The good news is you have options. Most of the modeling I do isnât in Rhino, for me there are more efficient tools, but it does have some very good third party plugins. I wouldnât hold your breath waiting for McNeel to polish the documentation or address the underlying issues that make that difficult, those are massive undertakings. Perhaps the way forward is to evaluate your tool set, add / subtract, and use Rhino in a limited sense for the tasks that will raise your output quality and efficiency.
Which Rhino plugins are very good?
Hello
Some years ago, going from polys to nurbs, Iâve learned Rhino along with its help system in days, not months. The auto-update feature as you use a tool is still very helpful for newbies or those who do not spend their life with rhino and have some memory leaks.
Otherwise, I found the Maxwell Render plugin very good on rhino 5.
Hello,
I like that VSR gives me the ability to easily create controllable curves and surfaces in Rhino. I like TSplines a bit less, likely due to more planning needed for the model and the UX being a mess. ScanandSolve is good for some FEA, although I think it may have been overshadowed by online services that are undercutting them. Mesh2Surface is very good for reverse engineering tasks. I like Thea for Rhino, itâs long in the tooth but it does what I need it to do.
âCare to share an exampleâ - well, I already did. Let me expand:
The Patch command prompts me to specify the U spans and V spans. Well, it turns it out it has some complicated limits on the numbers that can be used. So it changes the numbers I specified, to other numbers WITHOUT TELLING ME. The only way i realized this was that when I repeated the command (I was pushing stuff back and forth trying to get the shape I wanted), I realized that the values Patch was putting up from the previous use were different from the ones I had specified in that previous use.
The documentation says nothing about this.
I wasted time because of this.
Yâknow, when I worked at software, there were people who cared a very great deal about time and money. They would prefer that their programmers (we said âworker beesâ) didnât have to spend their time learning about undocumented idiosyncrasies in their tools.
For me i think Rhino must have a native Terrain generator, were have the option to choose between triangular faces or meshes or surfaces.
A built in tool for Roads were could be applied on terrains.
A better texture mapping for organic and complex 3d parts.
A make2d on meshes.
A better shadows calculation. Even in new Rhino 6, although shadows are a bit better then Rhino 5, could be more accurate, for output work presentations.
âŚ
Yep. There is/was a limitation on the total number of points (I donât remember how many or if the limits have changed or disappeared in V6) and Rhino would change the U or V count if the total number was exceeded - without telling the user. I remember having this discussion this a looong time ago, probably on the newsgroup before this forum existed. I havenât tested in V6 to see if this is still the case.
The patch command in Rhino is of limited utility, IMO, though there are instances where it is quite useful. It likely fudges somewhat to give you something that is not a complete cluster!@#$.
You appear want the documentation to explain that to you in some type of explicit detail. Thatâs a tall order.
Developers have limited visibility into how, specifically, one will try and use software of this kind. The user is provided a tool-set, and it is incumbent on each user to understand the merits, capabilities, and limitations of each tool, and to apply each effectively. Unfortunately, such is a process of time and experience. (and bugs and workarounds too)
Imagine if hammers and screwdrivers came with manuals that were verbose and detailed, and you had no idea what either were, or how to use each. Would that help? Perhaps, but to what extent? (And efficacy of such is likely specific to the individual, with those benefiting most, likely outliers.)
With regard to the application of a screw or a nail, how else, other than examination, experience, and common sense, would one know whether to:
A) bang the screw in with the hammer
B) carve a groove into the nail head and drive it in
C) bang the nail
D) drive the screw
???
As a control, go try and read the PTC Creo documentation; then tell me how informed you feel, and how much time youâve wasted parsing that doc?
None of the above in meant to proclaim that documentation can not be improved!
Curated wiki style manual to supplement the Mcneel documentation perhaps?
A lot of people spend a lot of time here answering questions: wouldnât be hard for someone to administer that advice/extra detail from a forum post into a wikiâŚ
I like the idea!
In a message dated 3/21/2018 15:32:10 Eastern Standard Time, mcneel@discoursemail.com writes:
You appear want the documentation to explain that to you in some type of explicit detail.
Thatâs a tall order.
No, I want something that uses the numbers I gave, or says something.
Imagine you hired a guy to run errands. You said âGo to the store and buy a loaf of breadâ. When he got there, the store was closed. He comes back ⌠and doesnât say a thing.
What would you think âŚ
That is full-time job for two McNeel employees. (One employee fixing bugs in existing documentation. The other employee writing documentation of new features.) There is no excuse for mediocre documentation!