Hi all.
This post might look like one of my usual Trolling attempts, but it’s really my sincere feeling about the present state of Rhino.
I have seen absolutely nothing in the V6 WIP so far that truly adresses the issues that have plagued Rhino for so long.
Namely,
-Poor solid boolean and shelling
-Bad meshing due to simplistic “UV”-following algorithm
-Slow and glitchy “make 2D” and no feature for synchronized 3D and 2D drafting which has been mainstream for 15 years.
-Slow display of meshes ; no smart/adaptive display strategy was ever devised, unlike in most CAD
-Old fashioned interface
In short, Rhino is an obsolete modeling tool, but it is saved by it’s low cost, community of long time users, and I think most importantly, by Grasshopper and satellites.
The “Rhino news” says it loud and clear : all the new and exciting stuff is about Grasshopper and what is developped around it and designes with it; Rhino is just the tired donkey on which GH is riding.
I’ll really get interested in this WIP when GH2 is integrated and it’s interface paradigm “trickles down” and juvenates Rhino’s.
Just an example of how the GH world solved a long-time Rhino weak spot : the Meshmachine from Daniel Piker’s Kangaroo.
At last ! Meshing done right !
Now you can trigger the bazookas and flamethrowers, I’m ready.
I have a dream that Autodesk buys McNeel and thus adds serious algorithms and hopefully also follows Clayoo2 in adding brush tools to T-Splines.
MeshMachine is itself a bit buggy and tweaky so it often takes all day to get a result.
Marching cubes was also added as the recent Cocoon plug-in to afford meta line/surface/point modeling but its mesh refine component is also very buggy so I turn to similarly buggy MeshMachine again.
I spend most of my time creating tools in Grasshopper just to arrive at basic capability. That means I’m working day jobs instead of solving problems in my home business.
I’m also reliant on ZRemesher in ZBrush to do quad remeshing. Rhino has no such capability. It’s a historical fluke that they lucked out on having T-Splines, which vastly expanded their jewelry clients.
The main problem with both Rhino and Grasshopper is that the company is too mathematically pure in its outlook, so if something fails, well, it’s the fault of NURBS math right, not their fault for not caring to invest in serious robust algorithms that just work. Why isn’t McNeel adding a team of paid developers to help poor David Rutten make Grasshopper work better, for instance? It’s volunteer plug-in work that thus rarely gets debugged.
I can’t even load Numpy/Scipy from Rhino/Grasshopper IronPython 2.7 abandonware. That limits what I can promise to a given client. So someone kludged up the ability to load .NET libraries. Well I’m working hard enough to learn Python. I don’t even know what .NET libraries are nor how I might offer them to a client. This sort of confusion saps my enthusiasm. Do I have to learn to compile those or do they come as binaries? I have no idea since there’s no manual and so few books on Grasshopper and how it works. What is .NET anyway? How would I know as a designer lacking a computer science degree. My degree is in chemistry, actually. Python I can handle!
Geomagic Freeform has NURBS auto-surfacing of meshes but Rhino doesn’t?! Rhino only turns each face into a NURBS surface, blowing up memory. So I had to invest in it, and that’s $8500 that did not go to McNeel for their cheap plug-in to do that, which millions of people would happily buy.
Granted, much is patented and trade secret proprietary, but shouldn’t McNeel be the guys getting those patents and licensing them out?
I think it very valuable that Olivier takes the time to give this feedback.
Personally I agree with him on the matter of not being able to reliably work with meshes inside Rhino.
The lack of robust Make2D functionality is also a concern of myself, as it is a long standing issue that only now in V6 gets addressed and it seems the new functionality still lacks realtime updating and a speed comparable to other software.
It’s my understanding that much comes down to the limited resources McNeel has -compared to other companies-. For it’s price Rhino has a lot to offer that cannot be found elsewhere.
Like any developer, McNeel has to choose what to invest development time in and what not. It’s my experience that McNeel has always been very open in their reliance on user feedback to make these choices. McNeel is a company geared towards a satisfied end-user as an intrinsic goal in contrast to many other companies that primarily need to keep stakeholders satisfied, and user-satisfaction is merely an asset.
@bobmcneel please correct me if I’m misstating things I don’t want to come across as an ignorant fanboy.
All this being said, I think Olivier cares about this software and is sincere in his concerns, he takes the time to write these comments to help out, not to bash or troll. He dares to put it bluntly in order to get discussions going that are meaningful.
Thanks for taking the time to share what you think of the work we do and how you think it could be better. I’m also excited about the idea of Grasshopper integrating more deeply into Rhino. Wouldn’t it be cool if the act of modeling created a GH definition, and fiddling the definition updated the model? Woah, that sounds like a huge project. But cool to dream about none the less.
I am prone to sarcasm, and there are lots of ways I could be sarcastic in response to Olivier’s post… but in this instance I am being completely serious. Unfortunately, when I say it’s a huge project, I’m probably under estimating by a couple orders of magnitude.
@brian ^^^ That would be so cool - and my non-programming brain says it shouldn’t be too huge (the base commands are already in play). Having quasi-parametric fillets in V6 and the existing History commands makes it seem plausible.
Im very very very very excited to have that in Rhino.actually it is something very plausible to do. I will give some input about how that works in other software = (to get a glimpse at how it might work in rhino, and maybe we can use their tricks too)
actually that kind of workflow brian mentioned is exactly how AutoDesk Maya core software works, they automatically create “nodes” everytime we do something on the model.(“nodes” in maya is like components / params in GH) and we can fiddle with the said nodes to alter or modify its effect on the model without having to even bother creating the nodes from the first place.
this is what it looks like =
those connection are made automatically depending on how we apply “commands” to the geometry. even as simple as creating layer and adding geometry into that layer, the “NODE EDITOR” will do it.(they have layer nodes too)
they store all the info u need to manipulate data, not to mentioned, it is packed with physic simulation + render nodes that is proven well to achieve something you can see on movies.
Maya 2016 even have sculpting (ala Zbrush) node and the latest algorithm to easily manipulates massive point data.
NURBS nodes also present although it is rather “buggy” (rhino still wins hands down in this category)
Additional feature brought by disney XGEN (which I think is a bizzare workflow) is something a “parametric” modelling should look into.
so all of the things inside Maya is actually just a collection of nodes.
BUT, THERE IS A DOWNSIDE.
all the nodes displayed and created are not addressed in a “language” that is easy to understand. (someone who has ever touched Maya node editor would know) they expose too much details on each nodes to something only programmer would touch. it is a good thing for advanced users but nightmare for normal users. they have introduced a shortcut in each nodes that we can preview them in “simplify mode” or “advanced mode” but still, compared to GH, Maya node editor is like reading hieroglyphs under disco light…
the other downside is that by standard, maya node editor is very destructive, it cannot maintain its data flow when u change the input data. u still need to go back to the specific nodes and add some utility nodes to make it works like GH. (maybe because I am more comfortable working in GH)
so maybe we can learn from that. hopefully can be useful in GH + Rhino implementation.
