Nope. I’m gentle and I mind my language.
I drink fresh kitten juice for breakfast and I curse.
To each his own.
I’ll have to agree with @osuire here:
for the first time I actually need to use Rhino for drawings and surprise:
It’s 2020 and this is still apparently not possible! AutoCAD probably has this even before Rhino was part of it.
Maybe I need to draw my drawing with gradient hatch?!
I am promoting Rhino as much as I can ever since I started using it, and I would continue to do so, but Rhino simply fails to meet the requirements of even a single complete workflow.
Please don’t use that lame ‘you can always return the product’ statement.
Fact is that Rhino is advertised as being user driven, but important issues and feature requests are being ignored, while features nobody asked for get added. It’s strange that they ask us the question what we expect to be in v7, while the features being added are nowhere near to the given answers.
Despite all the quirks this product has, I still love Rhino, but hate it pretty much for the same reasons mentioned by @osuire. We need to show our appreciation for Rhino (and I think most people that frequent this forum do) and part of that is to keep posting about the things that don’t work well.
I didn’t liked AutoCAD - dropped it, didn’t like SketchUP - dropped it. Didn’t like Word - dropped it. Didn’t like PowerPoint - dropped it too.
while features nobody asked for get added.
where is that information from?
Ok, I’ll take that back, of course I cannot be 100% sure that not a single person asked for features being added to v7, but what I can tell is that features are not being added and certain bugs are not fixed that many people have asked for - for years! My point is that there is a huge list on youtrack that developers can dive into to improve Rhino and make users happy. No need to look for new functionality. Rhino’s foundation needs work, not the cladding.
This was something I hoped for in V6. Possible to have it in V7?
Philip
I totally agree with you and if you ask the guys behind tech@mcneel.com they will confirm that I am one of the most frequent bug reporters.
There is nothing wrong with demanding change, I only asked for mor appropriate and mature choice of words.
Gustavo is family…families argue sometimes even though the love is real…
The only wish of yours I’d consider worthwhile. So please pull your head and consider that you are only one of many Rhino users. Your opinion isn’t the only one.
@Ncik
How about this one? It’s not worthwhile in your opinion?
That it works better then Rhino 6. Rhino 5 as far as I’m concerned worked really well. Large models were kind of fussy but as far as I can tell every thing related to blocks worked right. In version 6 anything related to blocks sucked. Especially when opening a large model created in Rhino 5. I’ll give Rhino 6 credit for improving Rhino render and better video graphics but utility is awful. I’d also like a BOM feature
The business I work for has never used blocks in rhino and I see no need to with our current modelling processes. So I have no vested interested in seeing block management being improved.
I was pointing out to @osuire that his opinion was not the only one, which he seems to lack an understanding of, and gets cranky when others disagree. If anyone can successfully lobby for “proper block management” to be addressed, whatever that is (again, I wouldn’t know what the problems may be), then go for it. It just seems weird to me to get cranky, insulting and bullying when others disagree.
I know that, sir.
I don’t have the statistics about block usage to be honnest, but , after 25 years of drafting, modeling designing various things (cell phone towers, train catenaries, architecture drawing, industrial design, tensile structures, wood structures, steel structures, heck, even kite buggies…) I have always used blocks.
Not that I love them particularly, but they are the only way I know of managing multiplicity.
The concept of nested blocks allows on top of that to manage complexity and combinations, similarly to the like of SolidWorks with the “parts” and “assemblies” concept.
For proof of this, the export to STEP of a Rhino file with well structured blocks makes for a perfect import in SolidWorks (and the like).
Rhino has immense superiority over most other CADs in it’s versatility, robustness, ease of programming, but failed to raise their product to the functional level considered standard by the industry :
Interactive documentaion (2D/3D associativity) and block management (ease of editing, extracting BOMs,…)
So now, they find themselves in the situation where they try to be embeded in other software… like a virus…
Pathetic.
Indeed…
McNeel seems to be very excited about this, all I see is resources being pulled away from improving Rhino where it is really needed.
@Ncik how do you handle repeating items (as in parts / assemblies) in Rhino if I may ask without blocks?
Interesting observation. It must be making sense for RMA from the business standpoint and I am sure there is a strategy behind this, but I have to agree that observing the development in many new areas like Rhino Inside while some basic stuff in core Rhino has not been fixed or implemented for years has been a bit disappointing to watch. Hope it will all come together as we need both new ideas implemented and old keep being fixed and improved.
I think you fellows are missing the point. I think McNeel is doing an excellent job of mimicking the most salient feature of all the other software providers in the CAD space:
religiously avoiding giving their users the complete set of well developed tools that will allow them to do their jobs quickly, easily and creatively. They measure their success at this by maintaining a long list of user requests which they gleefully never address.
I’ll offer a little defense here on the “spending resources on peripheral feature X instead of core” thing – developers are not interchangeable, and you can’t just decide one day to hire three more Jeffs or Steves or Dales, or whoever else you would need, because this is really niche stuff. On our team, each of us would be completely useless in trying to fill the roles of the others.
In other words, developing on rhino.inside or whatever else does not necessarily take away from development on core things, except as far as paying salary to the person who does it, and paying salaries is not likely a limiting factor here. On the contrary, unless the feature is not making a return, it is contributing to the the health of the company, and its ability to hire more core people when the opportunity arises.
Where there’s a will, there’s a way:
Hi Jeremy,
Nice to hear you.
One day, after much pestering and ironizing and ulcer digging, I at last got one of my Block wishes granted.
That was to have the block manager’s block list sorted. Hear me ? Sorted ! As in “not in a completelely random order” sorted kind of sorted.
Man, that was a big day for me, because I could use my knowledge of the alphabet and of counting numbers on my fingers to find where a block name was, instead of reviewing all 5498 of them one by one.
Then, I got ambitious : I thought “if they can pull this off, maybe they can do the same in the Block Edit dialog”. That was over ten years ago…
Here’s what a nested block description looks like today :
Where’s the genius dev who sorted the block manager ? Did he die and take his secret to the grave ?
Seriously now, this is just total neglect, there’s really no good excuse for it.
Rhino has the potential to shame many CAD tools out there, and I never considered it as some kind of “accessory”, like McNeel seems to be targetting.
This makes me both sad and mad, and explains why I can get a bit acrimonious sometimes.