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:
SplitMeshFace command. Same as SplitFace command, but working with meshes. Or just have SplitFace accept mesh face.
Hope the above makes sense and we will see continuing improvements in this area.
Thanks for listening !