Suggestions for Making Rhino a Better Program

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.

3 Likes

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 :wink: So they buy it as a tool just to have, if needed… nobody cares…

2 Likes

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!

1 Like

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…

2 Likes

I like the idea!

1 Like

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!