Hi Randy - so it looks like here Trim itself is actually ok and you're actually running into a bug in the display mesher that is making an incorrect display mesh for the trimmed result basically because of the very narrow clearance from the outer boundary to the inner hole.

If you do just a trim using your outer boundary of the file you posted, you can see that the result fragments look like this:



So note there that the bottom cut edge there has a slight amount of curvature to it, but it's not enough for the display mesher to add more points to it, so the display mesh uses a linearized boundary that's just a straight line there like so (the red line):



But that's a problem because you can see there that line is going to end up hitting the inner boundary and having outer and inner boundaries cross each other is bad and will mess up further steps in the display mesh generation. It won't be able to properly distinguish the outside and inside regions of the surface once those boundaries have crossed each other.

This is all happening in the creation of the display mesh and not in the actual real surface geometry operations that Trim had already calculated though.


If you try to repeat your trim with the attached file you should see that it does not do that anymore - the only difference in the attached file is that I added some points to the bottom curve so that it was made up of several spans instead of being just a single one-span bezier curve like it was before. That will then cause the display mesh to use several points along that bottom piece and then the linearized boundaries will not cross.

So anyway, it's a display mesher issue and not actually something going wrong with Trim - it's difficult to tell the difference though when this happens.

It's unfortunately pretty difficult for me to do much about it, because of the speed orientation of the display mesher. I could try to add code to the display mesher to analyze whether the outer and inner linearized boundaries were in a shallow area and needed more points to cross each other but that will be a fairly time intensive calculation to do and in 99.9999% of cases the end result of the calculation will be that it doesn't need to do any refinement. So it's kind of difficult to slow down mesh generation for all cases just to catch this particular kind of case...


But I do want to tune up the display mesher to try and make it add a couple more points in for things that are only shallowly curved but kind of stretch a fairly long ways across the particular shape - that would probably help with this situation.


Boolean merge happened to work in this case just because it ends up making a somewhat more complex edge curve for the bottom edge which has more spans in it, so it has more points in its initial linearized boundary for the display mesh generation.


Also one last note - on the original file that you posted, if you generate the messed up looking one but then go to actually do an export to a mesh format you should see that the export is not actually messed up itself, because there is an extra point added to the middle of the bottom edge in that case to slice the inner hole into 2 halves.


- Michael