This will be about working with mesh geometry in Rhino. More of ‘why’ with a little bit of ‘what’. For a while I have been posting some very specific out-of-context requests and ideas with some attention and implementation here and there, but I think it is worth explaining ‘why’ to hopefully get some more attention and long-term action plan in place.
Until version 5, Rhino has been specifically called “NURBS modeling for Windows” and only in V5 that has been changed to “modeling tools for designers”. Small thing, but I find this of big significance as it clearly shows some shift in thinking about the software, its use and development direction. Rhino has gone way beyond NURBS and while still the core of modeling in it, it should be recognized that it become a ‘design tool’ with a hybrid modeling being very common use of it.
Rhino 5 brought a lot of improvements and made working with mesh models a bit easier, 64-bit version helped dealing with large mesh objects and processing them in many different ways; ReduceMesh is a true gem of a tool and great to see it got even more improved for V6. Also finally in V6 we can see OSnaps working not only with mesh vertices but also face edges. These are all great things and going into right direction for the hybrid modeling workflow.
I don’t expect or want Rhino to become mesh modeler. I think hardly anyone would use mesh modeling to build things from scratch in Rhino. But speaking from architectural conceptual and detailed modeling standpoint here, it is a routine these days that all the project work done in Rhino is becoming a hybrid modeling (by hybrid I mean mixed mesh and NURBS models). So we need even more efficient tools to deal with this new reality. Long gone are the times when all of the modeling would be done from scratch in Rhino and the entire model and context would consist of nice surface/polysurface models. Instead, the most common scenarios are working with models which were pieced together from several different sources and teams - surrounding context buildings model, site and topography model, finally the main project building model - some or all of these elements come from other software (SketchUp, Revit being the most common ones) and are plugged in as mesh geometry. Very often the main project model is also a mesh model and Rhino is being used to either clean it up, add details or even rebuild from scratch into clean, more detailed and more editable geometry where the original mesh model is just a reference. Often Rhino is used to model the more organic parts of the building that are difficult to do in other software, but these parts have to interact with the simpler, mesh-modeled part of the project.
There is also another aspect of using meshes in Rhino - it has been discussed many times but joined mesh models perform way faster than nurbs models - it would be almost impossible to work on a highrise building model with 3d mullions as polysurfaces or even blocks for each single window, while all these mullions joined into single mesh don’t slow down the display even a bit. So having these meshes in working models is not uncommon either, and we need to be able to interact with them and make as much use of them as possible,
I hope the above illustrates the need for increasing mesh models integration in Rhino. Below are some suggestions - either new ones or gathered from my old scattered-around posts.
Allow Mesh edges as input for Rhino commands that take curves or NURBS edges as input (like Loft, Extrude, PlanarSrf etc. - virtually all commands that make sense to have it implemented). It is a lot more work now having to use DuplicateEdge every single time I need mesh edge as reference curve.
Mesh Trim, Split and Booleans to be more reliable and have the bug of disappearing disjointed meshes fixed
Have OrientOnMesh command and don’t limit it to just one input mesh as base geometry
Osnaps of OnMesh and PersistentOnMesh to be added to the Ctrl-mouseover Osnap toolbar also allow more than 1 mesh as the base object
Add _TesselateMesh command (to subdivide mesh faces n-times) for creating more dense meshes
Better OffsetMesh. Right now, even though we use it very often the results for mesh volume models are usually pretty bad. I realize currently the offset is just taking each vertex and moving it along its normal by the offset value, but I hardly find it useful for anything. How about making this tool working for real ? I guess it is harder to make it with Solids, and you did it nicely with OffsetSurface. offset_mesh_problems.3dm (466.6 KB)
InsetMeshPart command. This is quite common mesh modeling function and would love to finally have it inside Rhino too. See the image below for explanation of what it does and how it could work. Please note, the inset faces should stay selected for best workflow:
Hi Jarek,
Awesome post I wish it would get some attention.
I agree with your requests and these are things that should at least make it into V6 in my mind.
I don’t see these in the V6 osnap menu? I would like to see these added if that’s what you are asking? I asked for a osnap on mesh that is different from vertice snap long time ago.
However I do think Rhino should be a mesh modeler too, it has to be to conquer all modeling possibilities.
And for me I really feel Voxel modeling is the future if we could combine Voxels with Rhino the possibilities for perfect quad export and high dynamic modeling will be achieved along with the best of organic and mechanical modeling that 3d modelers really need. This would really set McNeel apart but it has to be done right. I know there is one company now who is doing voxel modeling in Rhino but it was too heavy handed in the past, 3dcoat and zbrush are doing it right and you can even build complex objects and scenes without heavy hardware. I would love to see more of this kind of modeling in Rhino the reason is I want to stay in Rhino for my organics but I can’t for the most part.
Your suggestions are a definite step in the right direction wish McNeel would comment.
RM
Thanks, I think there is better chance if other users would add their input in regards to meshes, too.
Obviously there is much more to be wished for but I thought these are the easiest/most straight-forward to implement building upon what’s in Rhino already. The mesh modeling will become even more relevant once SubD gets more advanced and exposed to more users. @Holo started some of his own mesh tools to support SubD cages creation which I feel like should be a next step to have natively implemented in Rhino.
As for #4 - that is actually about adding the OnMesh and PersistenOnMesh to the Osnap toolbar - options that show up when you have CTRL pressed once mouse-overing the toolbar. Right now, not sure why, they are only accessible from the pulldown menu and command line. Should be easy fix and add to the consistency.
But - which is huge IMHO - the Osnaps in V6 work with mesh edges now : ) You can get near, mid, perp… I think recently it has been by default disabled (which I disagree with) but try _SnapToMeshes to enable it.
See more here: http://discourse.mcneel.com/t/need-to-not-snap-to-meshes/28916/14
Hi Pascal, thanks!
I’d say my #1 is #1 on my list (I know it’s decent amount of work to enable many commands, and was wondering if from your end there any cons to having it in Rhino…)
thanks, and yes - either picking an existing line or polyline or drawing temporary in-command-only line between face edges. No need for curvy lines as these should be handled by general SplitMeshWithCurve and work on entire mesh object/many faces.
Here is a file with a ‘typical’ case, just a boxy slab with some openings, that I imagine may be an easier target for this and would be very helpful to be able to get rid of the holes just by single click.
There is also another more complicated shape that I just made up and most likely more difficult to handle.
Hi Jarek - ok - thanks - I still think this might be hard, but I’ll check with a developer to see if there is some way to even identify holes, given say an edge as input - say by tracing connected un-welded edges or something.
Wanted to add one more item to the list: 10) improve projecting curves to mesh(es). Currently very often the result is worthless. See attached file as a small example. Yes, I can MeshToNURB and get OK result, but this is a small part of larger file, in which case that workaround is not perfect. Also, shouldn’t it be more easy to calculate projecting to mesh than nurbs anyway?
PS. Don’t know why I can’t edit the original post - is it time-based and the post is too old? Wanted to update the list and check “done” for the few items that are implemented…
Thanks Pascal. Sometimes it works OK, but many times I see this kind or projection output. Can’t pinpoint why the problem happens with certain objects/files.
Hi Jarek - it turns out that the command meshes an extrusion of the curves and intersects that with the target mesh - the problem appears to be that it sometimes uses mesh parameters that generate a very junky mesh - the developer is looking into why that happens - it is supposed to use the current render mesh settings.
Interesting… so whether it meshes correctly or not, the result of projecting curves on mesh would always be a Polyline?
( so if we MeshToNURBS, the result may still retain smooth curves on each mesh face… good to know ).
Anyway, hope the file helps to diagnose the issue!
