In the blend file are two cubes, sorry I numbered them right to left. Both cubes have modifiers, the left cube.002 is modified by boolean difference with object Hole.inside.2nd and the Right cube.001 is modified by boolean difference with object Hole.inside.1st.

The modifier of the Right cube does not work, it creates an intersection, when difference is selected, and even that is not working as an intersection.

The modifier of the Left cube works properly.

The intent is to make a hole through the cube.

The cylinder on the left is a mesh cylinder, with the same number of vertices as the one on the right. The right cylinder was made by hand my remeshing a cylinder of another object, not in picture. The original object only had a hole, So, to make it the same size, I just used the existing vertices of the original hole to make a circle (same size, same vertices), duplicated it, and loop extended both circles to create a cylinder, which I would use after the main body remesh to make the hole. I wanted to make sure I made the same size hole, and using 'C' I easily selected the verts and connected edges using extrude, and auto merge on the verts.

I presumed, when done, that there would be no difference between this cylinder, and a mesh cylinder I made and defined dimensions. This was not the case. For some unknown reason, blender does not treat the two identical manifolds the same. I've tried turning it inside out, in case somehow the manifold was inverted, that didn't work. Since the two end loops of the cylinder are copies, I presume any orientation existing would be the same for both, and then using loop bridge, would also be same. I've tried to make sure by doing both flip direction, and recalculate on the cylinder before trying to modify the cube with this object. I later made this .blend test file. The cubes are copies of each other, and the difference is in how the cylinders were created.

If a difference exists between the two cylinders, there shouldn't be since blender work flow should by understanding be able to boolean difference these two simple shapes regardless of their how they were created as long as manifold, unless there is an unknown parameter on the one over the other.

I figured that this may crop up quite a bit, as I have experienced problems, and have heard others with similar problems with the boolean operator not working properly with many manifold shapes that just did not work and no one knows why. I hope this creates a two similar situations for which the analyze what is going wrong may be simple, and possibly have a simple fix to allow the modifier to work on more manifold shapes once this is resolved.

This may not be something blender does or not; if it does, a global fix may be needed or at least a repair routine built.

This comment may also be rambling theoretical talk, which could be ignored.

I don't know if blender retains the order in which verts and edges are made. I'm trying to think as a programmer here. In a closed loop, the order in which the verts or edges are created doesn't matter as far as looks go; but, order could create problems if one is making selections based on order; during a retopo it's easy to mess this up, and all edges may not point in the same direction, if there is such a parameter. Technically I think it would be fairly easy, if one knew the parameters to fix this issue. Finding all lines and ordering their placement could be more problematic however, but not impossible. This may not be an issue; however, some modifiers may require knowing order or expect a certain order to enable the modification.

If there was order, then a routine which renumbered the order of connecting edges could be useful especially when it came to simplifying meshes. This would be similar to adding an extra dimension, and ordered pairs might be possible to decrease subdivisions of connected edges if the vertices do not modify the existing topology too much, which could be defined as a percentage or fixed number value difference between original location, and the new location as determined by the midpoint of the new edge, missing the vert, then it may be able to be removed, but we'd have to watch the order and number of subdivisions removed to ensure we didn't get accumulating errors. The simple shape to consider would be a cube with a lot of subdivisions, where it's obvious that only four verts are needed to define the shape, yet if it was subdivided, all inner verts could be removed with no problem, and by ordered pairs this could be determined, as well defined start and end points exist, and all points in between wouldn't modify the topology. Intuitively this is true; however mathematically for such a simple shape, this could be determined and all unnecessary verts removed to simplify topology. More complex shapes and topologies could be cumbersome, at the same time, the ordered pairs would not manifest as having any relationship with one another unless simple curves were introduced into the analysis. This would probably be too complicated as it would be introducing a more than simple vectors, and points could have an orientation, which may prove to be a simple solution. All vertices would have both a global and a local axis. By such parameters, all extrusions would have vertices with this local orientation. This would also allow for n-space creations n-gons in n-space.

As an aside, I feel intuitively this is a natural order of things, as all objects of 1 dimension are oriented in n-space in n-directions. I only bring this up because I am a string theorist. The files and processing time, may require this to wait; but, numbering verts along a line would be a start. This is partly included by their existing location on the x,y & z axes, we just need more dimensions. Think of numbering verts as including time. All verts in the same time frame (vector distance from origin, center axis being the geometric center of that segment) and forming a closed loop are superfluous if not a beginning or end point, and mid point between two verts connected to that vert by an edge do not deviate by a determined amount, then the topology doesn't change... much. In a circle or curve, this would not be true, in a curve, sometimes it would be true if curvature was small. The question would be what are the start and end points of a circle or n-gon with a roughly circular shape? Surely if the wrong verts are selected as start and end points, we won't get the faces we want, perhaps that's why we get those lines when making holes. And why we can't bridge circles to the outer edges of a box to easily make the faces around a hole... automatically. Boolean, when it works, does a great job.

I think that this is a real issue. I've only been using blender for a couple of weeks. Three days on boolean operators that don't work. I looked at closing manifolds, reversing normals / making normals uniform. I aksi tried small translates to see if this would help (sometimes it did, but not in the attached case).

I have an example here: http://www.pasteall.org/blend/36704

Try to do Modifier: Boolean-> Difference modifier using:

• Parent Object: Cube. Target object: Tred Result.
• Parent Object: C_Inner. Target object: Tred Result.

I included Tred_Source_Before_Mod - which is the (pre-modifier) object which generated Tred_Result

Thank you.

Bastien Montagne sent me an email saying:
Your second cylinder has its normals inside (inverted), which obviously affects boolean ops (to fix it, just select bad cylinder, switch to Edit mode, select all, hit ctrl-N, and you are done).

In reply...
I could swear I have done this several times and it didn't work. But, it did work. So, I feel like an idiot. So, I've repeated this several times. It was simple, I didn't even have to remove the modifier. I did what I thought I had done before. Load file. Select Right cylinder. Switch to EDIT mode. Select All. Under Shading/UVs select Flip Direction. Unselect All. Exit Edit mode. Select Cube. Done... Apply and Viola a hole, right where I wanted it.

I'm clueless, and I wish there was a way to know; but, no. Unlike face color changes, I saw none when I flipped direction in either way. It's nice to know there's such a simple answer. I guess the bug is that there is no easy way to "Always" tell which direction the normal is facing. Whether this is because of the way Blender lights the faces of the cylinder, or something else like I have the wrong color scheme and this is not obvious, I was unable to tell the difference between flipped normals, and normal normals.

Much thanks again for all the help; I once again apologize for making a bug report where none existed, I carry this shame heavily on my shoulders.

PS. Please close out my shame or remove this report, which would hide my shame. On the other hand, I can see this is a problem for others too. I will check the file mentioned by the other message, and check that also.

@Chip Cooper (Cyberchip) please avoid walls of text in reports, we have to handle tens of those every single day… Yes, modeling implies taking care of things like face winding (order in which vertices are defined/selected to make a face), which in turns controls that face's normal, which can affect quite a bit of things (you know, shading, tools, etc.). Nothing new here.

@Ben Hizak (BHiz) please make new report - and attach here the files (mere drag and drop works fine), pasteall.org is highly volatile storage).

Bastien, the file was also attached in the report already using the system's method. Thank you for your help. Face winding seems obvious, and I had considered it; however it was not intuitive the way the faces were, unlike flat surfaces where I can see face color easily, I have had no problem making sure the faces are normal. However, for some reason, whether it's my color theme, I can see them on flat surfaces but not on cylinder walls.

I try extensively to ensure I try all my resources before thinking there is a bug. As a developer, I understand the burden this places on your workload. The problem even as I mentioned in the report that I had considered inverted normals (6th paragraph), and tried to flip them; but, as there was no way to tell. I tried flipping them once, and trying the boolean, and then flipping them again in case I messed up, and doing that did not resolve my problem. Why it worked this time, I know not. I do not like to make frivolous reports as much as you hate getting them. As far as walls, if it were a genuine bug, all what I had tried would be relevant, and how many times do I try something, like flipping normals before I decide that's not the problem. Apparently at least one time to few, because clearly I made an error. What more can I add. Once again, thank you for your help; my very sincere apologies for being wrong. I have been programing for 30+ years, and I don't often make these types of mistakes, you can trust, I will be more diligent in the future, as this has proven that it's possible to mess up, even trying to ensure one doesn't.

However, I still contend, that whether it's my theme, or something about Blender, I cannot tell which face is normal on curved surfaces. You can believe I will be researching to discover how to change those colors so this will *NEVER* happen again.

I have confirmed, at a certain distance the face color change is not obvious; and, I have found no way to change the non-normal face color. Even selecting a single face doesn't help at a distance. Now I know "why" I couldn't see it; I would love to have the ability to change the non-normal face color to one that is less similar to normal face colors. Perhaps my 60 years of age is catching up with me; or perhaps the edges are too close without zooming in to see the color change, more steps, ... fine, I'll work around it.

@Bastien Montagne (mont29)
Thank you very much for your time.
I added the file here. I don't understand what you mean by new report. Should I open a new ticket?
Much appreciated,
Ben

@Chip Cooper (Cyberchip) yes please, open a new ticket, one issue per report. ;)

Yes Ben, and oops, my bad, I didn't notice he was sending to you. He's saying yours would be a new report.... or ticket.

Ben, are you trying to make threads, like on a bolt? If so, have you tried the Bolt Addon in blender. It has all kinds of settings for pitch count, length, angles etc. And if you do, and have a problem with it, you would have to contact the add-on developer that made it.

@Chip Cooper (Cyberchip) . That's fantastic I'll make sure to look at it (spent 3 days on the bolt now...)

@Ben Hizak (BHiz) Just thought I'd let you know that this forum is for bugs only; it's not a general questions type forum. For that you want either Blender Artists or Blender Stack Exchange. We try to keep these guys freed up to work on things that need fixed. You'll find both forums very helpful. I believe I'm Cyberchip or Cyberchipz on both of those, so look me up. I've mostly posted on Stack Exchange. And if you do post, use Thread instead of Tred... I was a little confused by that. On that Bolt addon, you'll find more settings than you want. I used to calibrate standard threads and I saw a lot of things we didn't even look at on that add on. Remember, after you create your bolt, you can always use it to make your screw hole, not too tight though. ;-)

@Chip Cooper (Cyberchip)
Your comments are truly appreciated.
Please note that I did not post a question, but rather a bug (including an example, that I had boiled down to the essentials).
I do appreciate the developer's time, not least by keeping my posts short.
I read stackexchange quite heavily over the last few days.

@Chip Cooper (Cyberchip)
Following your advice, I posted on StackExchange. Here's the post. Any help would be appreciated.
I want to make sure that it is a bug before I open a ticket: http://blender.stackexchange.com/questions/32932/blender-boolean-operators-problem