If the only new feature here is to make compatible meshes out of non-joined objects, well that’s hardly solving the main issue with the Rhino mesher which is that it makes absolutely horrendous meshes.
The whole “meshing based on the underlying Nurbs U and V” only makes sense to lazy programmers because it is easy.
Meshing should not care the least about U and V directions, but only about topology and curvature.
The best meshing tool I found within the Rhino ecosystem is “Meshmachine” from Daniel Piker (Kangaroo).
It will form-find the mesh instead of just blindly following U and V coordinates, thus creating beautiful pseudo-equilateral meshes of similar edge lengths.
Why don’t you guys implement this instead of trying to revive cold corpses ?
Same goes for “Make 2D” : why do you keep trying to make this silly concept work when we need real-time 2D-3D interactivity which has been available in almost all other CAD software for over 15 years ?
Yes, I also think that the concept of make2d is outdated. Having a live link between 3d and 2d is a must nowadays. I hope this will be one of the key improvement for V7. This is a feature that everybody would take benefit from.
Instead of looking for bold new ways, McNeel keeps on patching lousy old stuff.
I don’t know what is the exact role of Daniel Piker in respect to McNeel, but they sure could use more of his work in the area of meshing, or 2D constraints :
That’s an understatement re meshing! Amazing stuff possible with Grasshopper in Rhino. (The good news) And if all one needs is the default internal mesh, however it has been manipulated, it’s all good.
However, the breakdown occurs when one needs to massage said mesh into a sub-d, or nurbs, for further downstream non-mesh application. Typically a total fail in Rhino.
One typically needs to get the nascent mesh out of Rhino, and into something more modern and more mesh capable.
Me thinks this gets some serious love for v7, otherwise, the stated sub-d push is likely bonked. It is going to need to be linked with Grasshopper output, etc.
Well you can waffle around all you want.
This “new” mesher is still based on the U and V parameterization of Nurbs which systematically produces ugly meshes.
This has been criticized over and over and over ad nauseam.
MOI’s meshing, although using the same Nurbs based paradigm , manages to produce much better results ; why can’t you guys at least reach that level ?
Why do you stay mute about Daniel Piker’s approach which gives awesome results ?
At least, tell me that you can’t implement it because this or that !
To me, Rhino only stays relevant thanks to Grasshopper ; and I think Bob knows this because the GH integration into Rhino (which is a non-event by the way) is the first item in the list of “New” features.
Most of the other features are just plain lies, like the simprovements on booleans.
“Make 2D” is presented like something everyone loves, but that is clearly pure bullshit ; just read the comments.
The “real time rendering” is just another gimmick (and it is still extremely buggy) ; there is a plethora of more potent and almost free alternatives, and don’t get me started on the total waste of time that was the whole Brazil story.
The only real improvement is the display speed, but man ! Was that overdue !!!
Sorry for all the negativity, but I am so deeply disappointed to see my beloved Rhino sink into obsolescence.
I can’t help but think that the management leans on old familiar ways and only lets innovation in when it is overwhelmed by it.
To change the angle of this subject slightly - while I don’t have a problem that there is attention being paid to improving the mesher - seems like some people need this (not me) especially for export to other programs - but what I don’t see or hear about is any attention being paid to Rhino’s mesh INTERSECTOR. That is the cause of 80% of the woes we have with manipulating mesh objects in Rhino - splits, trims, Boolean operations - and needs help far more desperately than the existing mesh-creation algorithms IMO…
I have been struggling with splitting large meshes with curves recently and found it of no use at all.
Sent it to Max, it had failed too, but at least did something (ugly though).
I hope it will change.
In case it’s not clear to the McNeel developers, let me further explain what @arail posted, and why it matters, so much.
If you double-click one any single edge highlighted in green on the mesh of the left, you will select the entire unequivocal edge loop, which is also coincident with the topology detail you modeled. You can then make transforms, duplicate(slide) that loop, make chamfers, rounds, etc.
If you double-click one any single edge highlighted in red on the mesh of the right, you will either get a random guess at a loop selection, a partial loop or not selection expansion at all.
For work on further modeling, mesh selection, UV unwrapping and alignment and any other interactive mesh workflow the mesh on the left is extremely useful. The mesh in the right is pretty much useless.
For context before anyone might take my objective feedback as disrespectful, I’ll attach here the definition of useless:
PS: we still rely on MOI and we rather see this resolve inside Rhino, we deal with a lot of very heavy, detailed, and complex geometry. And MOI does not handle complex files well at all. Sometimes it just says: out of memory or something like that. Rhino on the other hand, is awesome for this. It can handle pretty much anything we throw at it. So let’s do come up with some kickass meshing with it too!
