Intersect with meshes and general mesh rant

Rhino
,
1

I still don’t understand what’s so special about meshes that it requires its own intersect (and trim and split) tool(s).
I think it’s more a case of programmers making it easy on themselves.

Moreover, I think it really sucks that the concept of “IntersectTwoSets” isn’t available for meshes since intersecting a bunch of meshes is typically time consuming and produces LOTS of geometry.
Without the ability to choose what should intersect what, intersections with meshes are a real chore.

240424_IMG_Intersect Too Much
240424_IMG_Intersect Too Much1423×977 253 KB

And this is one of the many pain points still remaining with meshes in Rhino.
I could also cite :
-Extremely poor shelling (completely useless ; I need to use MeshMixer every time for this)
-Lame “ReduceMesh” dialog box where the preview is dumped and the computing has to run again if you hit “OK”
-Confusing “MeshRepair” dialog box
-Still a lot of work to make the Quad Remesh as good as what is found in Z-Brush or others
-Shrinkwrap produces meshes that are considered “Bad meshes” ; in particular, with self-intersections.
Isn’t the point of this new tool to make “good” meshes out of rubbish ?

1 Like
2

Hello - added

RH-81688 IntersectTwoMeshSets

thanks.

-Pascal

1 Like
3

_IntersectTwoSets: I didn’t add that command so I cannot assist you with the ideas driving it. However, there’s something deeper to think about if we consider this.

It’s not really difficult to add meshes-meshes sets for this command, but unfortunately there are caveats in other cases. Mostly, problems arise when you select mixed items like polysurfaces with meshes, or surfaces with meshes. What can be offered, in that case, is the intersection of the mesh representation of the surface with the mesh. This isn’t necessarily the same as the intersection of the surface with the mesh. Would that work as well?

If so, probably this can be added within a service release cycle. I haven’t heard other requests about _IntersectTwoSets recently.

Alternatively, _IntersectTwoMeshSets could be added as a standalone tool. Not sure if we really want to add that command, it feels a little lonely.

Giulio

–
For Robert McNeel & Associates
giulio@mcneel.com

4

What problems exactly ? We need to get to the bottom of this, because this whole duplication of intersectors is contrary to the general spirit of many Rhino tools like “Join” or “Explode” which can deal with mixed geometry types without any fuss.

Say you have 2 surfaces and a mesh, then the intersector could :
-Intersect the two surfaces like it does with the “Intersect” tool
-Intersect the mesh with the render meshes of the surfaces like it does with the “MeshIntersect” tool

Then the “IntersectTwoSets” would do it’s job in a similar fashion ; really, no rocket science here !

Please give me a clear example to justify this mesh apartheid thing that’s been going on.

5

We know each other since forever,… Please keep the conversation friendly, it will help to keep all of us healthy. :slight_smile:

As I mentioned before, the problem arises, as you now also noticed, with mixed types. _Join is actually a great example: it will just entirely ignore anything that happens among different types. This appears not to be what you expect, though.

It cannot really happen this way at once because we still have to select two sets, so I assume we select one surface first, then the mesh and the other surface. So, would this transformation with render meshes be a satisfactory outcome? So, as soon as one element is a mesh, everything gets transformed into a mesh? I’m asking because I’m not sure, and this is probably why the “ancestral developer” chose to implement this feature in this way. But we can only guess.

If we are consistent with how _Join behaves, as mentioned above, we would get the surface-surface couple, and for the mesh, we would get nothing done. But this will certainly create a lot of technical support so I don’t think this would be appreciated by the support team.

Another possibility is that the mesh is transformed into a NURBS with the _ToNURBS command and the result is computed between polysurfaces. This is the most “precise” geometric result, far different from the rendermesh approach (for a sphere and a mesh plane, you get a circle, not a polyline), but it also has a big disadvantage: it will only work for small meshes. For larger meshes, _ToNURBS will never end. This is because meshes have a much smaller memory footprint than the equivalent polysurface and support way more faces.

A final approach would probably be that an option is given, and _IntersectTwoSets asks how to deal with mixed types; options could be: Ignore, UseRenderMesh, and UseNURBS, each with their own advantages and disadvantages. Having such a fine-tuned command would probably be amazing: Again we can only guess the underlying thinking of the “ancestral developer”; but I think it could be something along these lines: so much work for maybe a little-used command, with so many other issues on the todo list.

Sometimes, we have to do with the resources that management gives us. So, what do you think we should do?

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

6

I didn’t mean to be un-friendly, but you know, like Elon Musk, I had a tough up-bringing in South Africa ; comparison stops there, though.

Sorry Guilio, but this is completely irrelevant.
I don’t expect Rhino to join surfaces and meshes, not more than curves and points.
Yet, intersecting a mesh with a surface internally converted to mesh makes sense and is practical, thus it should be made easy.

For starters, I have no idea how Rhino meshes (“internally” as it says in the invite) the surfaces so they can be intersected with actual meshes. This is probably something that should be clarified.
Secondly, this has nothing to do with “IntersectTwoSets”. You are mixing up everything to make it sound complicated, and even bringing MeshToNurbs in the picture, when it is really very simple !

The normal intersect tool tries to intersect all the selected elements with all the others, right ?
So there is a very simple logic to do this with a “hybrid” selection (meshes and surfaces) ; suppose we take each object one by one :
-If the current object is a mesh, and one of the other object is a surface, intersect it with the meshed version of the said surface, just like “MeshIntersect”)
-If the current object is a surface, and one of the other objects is a surface, intersect them just as “Intersect” does.

This is really basic, I don’t understand what’s all the fuss about.

Thank god, the “Section” tool works with both Surfaces and meshes.
Well hear this : it should be the same for intersect, Split and Trim !

1 Like
7

4 posts were split to a new topic: Shelling meshes wishes

8

I split the topic to keep things readable. I’m really trying to make this work.

I was thinking about this during the weekend. You certainly make many valid points.
I need to get some traction to get everyone onboard. My current hope would be to get to a more powerful Intersect command.

RH-81737

9

Actually, the idea is rather “Intersect Meshes, Surfaces and Curves”.
Given a set of meshes, curves and surfaces, the intersector would intersect :
-Curves with the surfaces, meshes and curves
-Surfaces with surfaces
-Meshes with the meshed version of surfaces

I didn’t write all combinations because for example Curve/Surface is identical to Surface/Curve.

10

Well thanks for this, but you could even split further because there’s :
-Shelling
-Re-meshing
-ShrinkWrap
-ReduceMesh

I could also add “Mesh Repair” which is just a mish-mash of various mesh editing/fixing tool in a confusing interface that doesn’t even bother to purge the selected mesh when it is closed.
I found myself multiple times fumbling with this interface to audit a mesh which wasn’t the one I thought !

1 Like
11

This one is unacceptable, I remember reducing some heavy meshes and feeling like my time was worth nothing. Probably it’s not as important as other of your points, but it shouldn’t be as difficult to improve either.

1 Like
12

Yup.
Crass negligence here.

13

Absolutely. It does pretty well with surfaces and curves. The main problem, as far as I understand, is that there’s nothing for mesh-curves pairs. That’s why I mentioned these types.

Yeah, I fully understand. I can only move posts to try to help other developers and get these important fixes and wishes you mentioned added. Maybe Shelling and ShrinkWrap can be grouped by similarity for what algorithms are concerned, however there’s a different workflow. The fix for ReduceMesh seems easy. I’ll try to bug the dev, but I know he’s swamped…

1 Like
14

Don’t forget SubD, which apparently also has a duplicate set of commands for common tasks. The whole thinking at McNeel ought to be “generalize, generalize, generalize” but it feels as if it’s more “compartmentalize, compartmentalize, compartmentalize”… I bet that’s easier day to day as a developer, but it becomes more difficult day to day as a user.

2 Likes
15

These choices are very old and probably dependent from what was available back then.
I’m trying very hard to make this part work well, and believe me, it’s taken a toll… not only on you as a user…

16

So, I just decided to go ahead and fix this.
RH-42740 and RH-62170 should be fixed in the next release of Rhino 8 SR7.

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

2 Likes
17

Thanks Giulio.

And here’s a little gift for the folk who made the ReduceMesh dialog.