I’m really trying not doing any mesh/subD modeling in Rhino because it’s just too frustrating for me, as I’ve mentioned several times in the past, but sometimes when we are referencing Nurbs models, or I need to rebuild/remodel in Nurbs I need to do some very basic things here with meshes, and more often than not I just get stuck. I have no expectations of modeling a product here efficiently, but at least it would be nice to be able to do some minor edits to imported mesh models.
Here’s an example. I need to split this closed retopo mesh (imported from Blender) along this close edge loop. I select my edge loop and now what? how do I split this open?
As you can see above ExtractMeshFaces does nothing at all. Same for _Cut _Delete _Explode _DeleteFaces… nothing really works here. This selected loop will not split, not even going away as a deletion. I also marquee selected the top half of the model to delete all those faces (hoping to delete each half in duplicate meshes): nothing happens after I hit delete (other than the not-responding blue ring cursor chocking Rhino for a while).
Please tell me that there’s an obvious command that I’m just forgetting about because I cannot believe I can’t do this simple operation.
UPDATE: I converted the mesh to SubD (_ToSubD) and now I’m able to extract the polygon loop and re-join it to one half. I’m also able to delete faces. That’s at the cost of losing all my saved selections of that mesh.
BTW, not only I lose saved selections when I convert _ToSubD, even worse problems with the saved selection workflow:
If I duplicate a mesh with a bunch of saved selections, the duplicate has none!
the named Selections windows lists all the named selections of other geometry that’s not even visible in my viewport (layers are off) so here I have a mesh duplicate, that I might think has saved named selections because I see them in this window, but in fact it has none. This makes no sense.
Also, I tried to ExtractControlPolygon to the new SubDs and in those new meshes (the control polygons) I can in fact delete faces, even though I was not able to delete faces in my original mesh. I’d love to know why this is happening. Is there any information in my imported fbx mesh that is tripping up Rhino?
@ryan.odom, the problem with mesh split is that the tool builds its own meshes based on intersections. That’s an extremely dangerous proposition in the mesh intersection solver of Rhino, as you can see. We have a perfectly clean model, we just want to organize it by splitting our nicely modeled edges, nothing else.
I guess is time to shake my head, close Rhino and start the weekend. Thanks for listening.
I have also had issues with saved selections, so I gave up on it. However, I did notice it happens more when I was inside of a block and then created my saved selections. They just disappear when I exit the block…
Why not make a mesh plane at your loop and mesh split with it? Am I missing something?
It’s not all planar so in this case that won’t work. Also I do not what to use any tools that can possibly edit my topology adding new faces/edges/verts, IMO that’s a horrible practice, and I want to be able to always model cleanly. Rhino needs to be able to give us that.
OK w/o the file I cannot tell, but why not ribbon both side of your loop and then convert to mesh and use that to meshsplit? Actulally, I think I understand what you want now. Not sure if it’s clean enough for you, but maybe I would ribbon the outside and patch the inside, join and convert to mesh, then meshboolean split. On second thought, it might be better to just use the patch and extend the surface ever so slightly to get your cut
Splitting open a clean, beautiful model should add zero new faces, and your poly flow needs to be intact so you can rejoin later, UV unwrap well, expand selections, shell, chamfer, etc.
Like everything else, it takes years to understand a good workflow in poly modeling, and about a decade to master it, if you care about it. Non-destructive tools are the foundation of clean, interoperable and responsive modeling workflows. Rhino needs to do the basics of that well, before anything else IMO.
Interesting, yea that’s way out of the workflow I work in, I only deal with mesh when I absolutely have to. And normally just to 3d print that someone will clean up and it never needs to be high res or clean or anything crazy - luckily, otherwise I’d be #$#%. But now I’m curious, how would you know that new geometry was added? If it’s cutting exactly at the loop?
Hi Gustavo, I’m willing to take some of your frustration about this, and also some of the blame Please bear with me for a moment. So, _SplitMeshWithCurve is the command that should work here. Most of the other commands that you mention, except selection and extraction, should not work by design.
You see, _MeshSplit, as you noted here:
allows to pick curves.
With MeshSplit, if a curve is selected as splitter, the curve is extruded in the direction of the current CPlane and used for splitting. If the curve is actually mostly already on the mesh, this usually just creates a set of overlapping faces that cannot be used for splitting. This is what you see with the MeshBox above. This behavior has always been like this. If the curve is entirely on the mesh, we probably should switch to using _SplitMeshWithCurve under the hood. And mostly, _SplitMeshWithCurve should work.
I didn’t get to rewrite _SplitMeshWithCurve, yet. It’s on my todo list, as well. For the time being, I’d like to have a look at the model. I’ll ask @pascal to show me a copy.
Thanks,
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates giulio@mcneel.com
Hi Giulio, thanks for your feedback. I think of would be great to fine tune SplitMeshWithCurve, but I’m hoping this will not be a replacement of a much more needed tool in poly/mesh/SubD modeling: split selected edges. If I select a full close loop the ‘split selected edges’ should split the mesh in two separate meshes (like the example posted here), no need, in fact no desire, to select any external input like a curve. If I only select a single edge, or a handful but not enough to be a close loop, it should ‘open up those edges by duplicating its vertices and then allow me to move one of them to create a local opening, typical workflow to make local vents or details.
Hi Pascal, thanks for checking on that. I would have never thought that a mesh check issue would prevent Rhino tools from working, and in fact wouldn’t even tell me anything about it. I’m familiar enough with mesh tools to know that it was not normal that delete faces or extract faces we’re doing nothing, and I’m stubborn enough to come here to ask for help. I’m afraid most new users could think that in Rhino you can’t simply just extract, or delete, a mesh face. This needs to be handled much better IMO.
Also what on earth is a degenerate Ngon anyway? And why having one (or several) in a mesh would prevent Rhino to run a command in a selection that has none of that? Also if I have a ‘degenerate ngon’ shouldn’t I be able to select that face and delete it and then add a new ngon? I think it’s worthwhile to pause on some advanced features and paying a lot closer attention at handling well the most basic stuff in mesh modeling, like these situations. This is the kind of stuff that makes Rhino untrusted and IMO even unusable for this kind of work.
Agreed. Actually, that tool needs a rewrite. You are not the first to ask.
I’ve started the tracking of this wish now at RH-69337.
Yes. I absolutely agree that all our more error-prone commands should analyze meshes before running the algorithm, and at the very least warn to the user if there are problems. In fact, _MeshSplit automatically does some healing of meshes that it will work on, and if the healing would be too complex at that spot (requiring picking, etc), it mentions it on the command line.
Hi Giulio, I think it’s really important to be mindful of preserving any and all mesh information when doing any repairs of rebuilds. For example: I might bring a mesh to Rhino that has:
UV unwrap information, sometimes multiple UV channels with different unwrap levels. This UV work takes a lot of skill and hours of world and I would not want a Rhino command destroying all this work. In my experience this happens constantly, but it’s been a while since I stop even trying because of this reason.
Vertex normals. Also super important for rendering, and Rhino is very lazy about respecting them on imports/exports and other commands. It’s more common than not that in a new Rhino build, this is broken for some kind of mesh file type export.
Vertex colors, leas frequently used, but also worth being respectful of them when they are present.
Smoothing groups. Meshes that have these are super risky to bring to Rhino.
Named Selections. Hi hear are only inside Rhino, but also take a lot of work to create, they should always be maintained. Like the earlier example I mention where a simple duplication ignores them.
In summary: you guys need to play well in a professional pipeline.
Hey @gustojunk — ah sorry my responses probably did not help with what you are doing-- I was particularly interested in the question because I recently had a super messy mesh from a client – a nightmare trying to get the mesh to split — but mostly because it was just all sorts of meshes thrown together to make an object- nothing was closed, overlaping - crazy times etc. Working with meshes has become of more interest to me because of my advancements in subd modeling. It’s not that I don’t understand your question, I was just trying to understand a little more about your technical needs and how you came to your conclusions on “clean” geometry etc. But anyway, I really appreciate this question and I am excited for rhino to split along a closed loop… at some point right — it is kinda insane but the mesh platform in rhino has come a long way IMO
Please bear with me for a moment. So,