Superb. Zero oversteer.
Superb. Zero oversteer.
Mies would disagree with you!
|Flywheel power||18 kW|
|Drawbar pull||14710 N|
|Speed||20 / 25 km/h|
that is still too powerful even when you wear your protection suit. Alternative:
please wear your helmet.
We may need separate thread or forum to debate similar topics, e.g., which religion is the best. (My favorite religion is Lisp programming language. All other programming languages are heresies deserving inquisition.)
More is better than less…
Depends on what “more” refers to…
I’m sure he meant debt in bank.
I wish, one day we get paid for each control-point created. That would make Rhino the best program of all.
OK, that’s it. This thread is becoming frivolous.
In my previous response I struggled to find a good/funny metaphor, but surrendered.
The porsche-farm-tractor is SO RIGHT.
In this thread the helmet wears you - that is an improvement of the case where you have to remember to wear it yourself.
Indeed. But the analogy of Rhino beeing “the” tractor is to the point imho, i’ve never seen a Porsche pulling out a tractor out of the mud. Even when that vehicle appears to be slow, its can be endlessly powerful, if you’re willing to get involved into things which are not visually appealing.
In my everyday work, i get iges files where i only see the source app mentioned in the headers. To my surprise, many highly priced packages are often used to create the crappiest geometry, either because the user did not have the time to do it better or because the app just did not offer ways to do so.
A feature in regards to classical nurbs modeling to make Rhino a better program for a designer would be a command which works like T-Hotbox in the real world. I’d like to apply it to single surfaces and polysurfaces, especially across seams. Can you develop that ? It doesn’t have to be fast, just strong enough to pull out the dents.
Now, that’s better!
Yeah, I was thinking that the file I’m working on simplifying now (Step, from an unknown source) must, by @TomTom 's proposed system of pay, must have been made by a millionaire.
Thats perfect Pascal!
Skipping jokes about bridges, I have a some really substantial suggestions:
(1) I suggest you add a paragraph or two to the existing documentation of each command, called “Details”. For example: explain what you mean by the overlap of two curves, and how it affects the Curve Deviation function.
Another example: The limits and behavior of U size and V size (I don’t have Rhino here, and I don’t remember the exact words) of Patch. (Yeah, the limits in Rhino 4 have been changed.) I spent a bunch of time having to explore how this worked. Watching Rhino change parameters I specified, without saying anything. (Another violation of user interface rules.)
This kind of Details documentation would save me a lot of time.
(2) Also: make a list of user interface rules. Hang it on the wall. A second person, not the original programmer, checks. Code is not accepted if it AND ITS DOCUMENTATION do not comply with these rules.
(1) Use the parameters specified by the user. If you can’t, tell him, and tell why why. (Patch in Rhino 4 violated this rule.)
(2) If you can’t do what the user asked, tell him, and tell him why. (Line perpendicular to two curves violates this rule, at least in Rhino 4.)
God forbid! The succinct brevity of Rhino documentation is one of the true jewels of the CAD industry. Best in the biz IMO.
BTW - millennials don’t read documentation any more…
Fixed that for you…
Documentation is the worst part of Rhino. It has dozens or errors and over one hundred omissions.