Disregard my post about the corner of the little piece. This seems to be just a display angle visual thing and nothing wrong with the object.

It appears to be something with the surface normals of the larger object. They are inverted (hence the opposite interaction. MoI has a "flip" command, though if you seperate the surfaces, flip them, then Join them back again, the surface normals are reversed again. If you seperate the large object, flip the normals, then save it to a STEP file, then import the part and Join it together, it then Booleans properley and works as expected. This is why the mirror makes it work, because it is reversing the normals on the surfaces.

Perhaps something up in mirrored surfaces?

Was the original part a mirrored part Yennmonger?

Hi Burr,

> Disregard my post about the corner of the little piece. This seems
> to be just a display angle visual thing and nothing wrong with
> the object.

Yeah, that's just a part of the display mechanism - that's what you see when the "near clipping plane" is hitting the objects.

The way 3D graphics cards work, they basically require a boundary to be set for a clip plane on both the near and far distances as seen from the eyepoint, and in a perspective projection it loses z-buffer resolution if you set the near one to be just right at the eye point.

If you switch to a parallel projection rather than perspective then that won't happen anymore.


re: Inverted normals - yeah when you see a boolean difference performing as if it were a union, and you've got 2 solids that will probably mean that the surface normal orientation on one of them is incorrect. On a solid the geometry library will do some ray firing analysis to automatically determine which side the "outside" is supposed to be, but in some rare situations it could get confused or maybe something forgot to do the rayfiring step. If you run across it, you can solve it by using Edit > Separate followed by Edit > Join to rejoin the surfaces into a solid - that will also run the inside/outside calculator.

- Michael

Hi Yenmonger, are you set with a solution to this now?

I think that the problem here is that you've found a shape that confuses the automatic inside/outside detection mechanism.

I think it's probably trying to fire a ray though the narrow area near the end of the wedge type shape. Then it's probably getting points that are within tolerance of each other and that's causing difficulty in the analysis.

If you run into this behavior in the future, you can try running the opposite boolean command to see if that will work.


I'll keep this model and take a closer look in v3 to see if the automatic inside/outside detector can be tuned up, but it is a sensitive area used quite frequently so it's probably a bad idea to mess with it right at the end of v2.

- Michael

FYI when you look. When viewing the surface normals in my CAM package, the indicator usually appears at the surfaces "center" position. Though with the little angular surface at the top, it appears at it's lower edge. Seemed kindof odd???

Hi Burr, it looks like your CAM package is taking the center of the underlying surface as the spot for displaying the normal.

In MoI, select that face and do an Edit > Separate to break it off of the main object, and then use Edit > Show pts to turn on control points and you will see that underlying surface is a kind of slanted parallelogram, the visible part is half of the underlying surface and the centroid point of the underlying surface is in that spot that you indicate.

That surface probably started out as a longer piece and the current one you see is the result of some other trimming or booleans that cut it in half diagonally.

- Michael

Yes, Mr. Gibson, I'm good now. Thanks again.

The piece of this model started life as part of a VRML file. I used Rhino to convert it to a series of lines, then used Rhino's mesh to polysurface command, then saved that as a 3DM file and used MoI for cleanup and enhancements.

So, it was probably related to the Rhino polysurface command. Or was it polymesh? Can't remember.

Hi Yenmonger, yeah probably Rhino's MeshToNurb command created that triangle that is half of a parallelogram. But there is nothing wrong with that.

I'm going to see if I can narrow down where in the inside/outside detection mechanism that things are going wrong and send this to the company that makes the geometry library so that it might get improved for v3.

- Michael

Hi Yenmonger, just a note on this - I was able to track down the bug in the geometry library that was making the inside/outside detection mechanism get confused for this case and I think that the fix is simple enough that I will include it for the v2 final.

- Michael

Neat, thanks!