John K. Jordan is an old friend and Master Max guy from way back. Some of you may recognize him from the reams of valuable posts on the Kinetix web board. An old master of 3DS Max Boolean Voodoo, John was good enough to let me post his outline for successful Booleans for the general good of the members of the San Diego User Group. So here it is, and I hope that this helps many of you in your modeling adventures in Max.

The Max boolean is indeed "flaky", but not by fault of itself! It just requires a few things to be right. The
STL-Check modifier can be used to verify that neither operand has the types of errors that cause 90% of
boolean failures.

I provide FA support on the Max forum and I've seen many, many people with boolean problems, even a few so
upset that they claim that every boolean they've ever tried fails. There is no reason for this! I've had several
people tell me recently that some of the techniques below have improved their boolean success
astronomically. (well, at least greatly :)

There are several things to watch out for, but the biggest is:

1) The topology of both operands MUST be in perfect condition: each operand needs to have a continuous,
closed surface. This generally means things like: no holes (open edges), self-intersecting surfaces, double
faces, internal faces, or unwelded vertices. There are other issues too, such as the need for consistent
normals and to avoid zillions of long skinny faces.

If an operand does not have a robust surface, the result can be anything from a boolean that fails immediately
to one that appears to have worked but has subtle mesh problems. The latter might appear to be OK and even
render correctly, but if used as an operand in a SECOND boolean, things fall apart rapidly.

The STL-Check routine was intended to check a model for consistency before sending it to a stereo
lithography machine. It turned out to be perfect for checking booleans! Except when an operand is a primitive, I
apply an STL-Check modifier to the operands and again to the result, click the Check checkbox, and look for
errors. Any errors must be fixed, especially if doing successive booleans, or disaster will soon follow!

(Actually, I cheat a bit - to save time, I often do the boolean first and STL-Check the result. If I see any errors, I
undo the boolean and go back and STL-Check the operands.)

If STL-Check reports ANY errors, the mesh must be fixed before continuing. The fix may be as simple as
applying a Cap Holes modifier, or may require welding open vertices, deleting rogue faces, turning edges, etc.

For successive booleans, I generally follow this procedure:

A - apply STL-Check
B - OK? then collapse, Boolean, goto A
C - Errors?, then fix, goto A

Since the CapHoles modifier fixes many surface problems and doesn't usually hurt anything if not needed,
step A might be modified to read:

A - apply CapHoles and STL-Check

(Note that it is often recommend to collapse each boolean - see below. This seems to help in many cases,
but is not always necessary - I've had more than 20 booleans on a stack without problems. However,
collapsing does speed things up considerably and will avoid some other potential instabilities.)

Besides a continuous, non-broken surface as mentioned above (#1), some other boolean "rules" are:

2) An operand must be non-intersecting. You can't, for example, apply a noise modifier with parameters so
severe that some of vertices are pushed through other faces. You can't reliably use an operand that been
constructed out of several meshes which have been attached with an overlap in the area of the boolean. If
necessary, the sub-meshes should be combined with a boolean union instead of a simple attach.

3) An operand must have uniform normals, i.e., all normals must point the same way, either in or out, relative
to the inside of the object. I think this is what makes self-intersecting meshes fail. Inconsistent normals can
cause some apparently strange results. For example, if all the normals are reversed, a subtraction will actually
be a union - imagine the problem if some faces are one way and some are the other! This problem commonly
comes up with models imported from CAD packages.

4) An operand should have a minimum of long, skinny, faces. Max2.5 Boolean2 is better about this than
previous versions, but still, operands with too many long, skinny, faces can cause small boolean glitches
which can explode into huge boolean problems with later booleans on the same object.

5) An operand should have a minimal (or collapsed) stack. Too many things on the stack MAY cause
problems. I saw one case where a seemingly innocent UVW modifier far down in the stack resulted in a
spectacular boolean failure. In addition, always collapse the result of a boolean, especially if you intend to do
another boolean on the same object. An exception to this is if you need to animate the operands.

6) Never, ever, hit the boolean button twice without doing a Pick operation. This will put two boolean create
operations on the stack, but one will have a blank operand-B. This can later come back to haunt you. (Note:
this may be part folklore, but I've seen too many problem boolean files that had this common "attribute", so I
make this a rule for myself)

---------------------------------
Some notes on creating or fixing operands, in no particular order:

- Avoid long, skinny faces if possible when lathing, lofting, or extruding objects that will later be part of a
boolean. For example, when extruding a spline, I turn on the edge display and look for long, skinny faces on a
capped surface. These can often be eliminated by dropping back to the spline in the stack and adding a few
well-placed vertices around the perimeter of the spline with refine, using "show end result" to check.
Sometimes simply changing the 1st vertex of a nested spline helps tremendously. For maximum control, I
also like to segment a spline by hand (making all segments linear) instead of relying on the evil boolean killer:
automatic curve segmentation!

- Add extra subdivision where necessary to minimize long, skinny faces, for example by adding height
segments to a cylinder.

- Plan each boolean operation of a series so each subtraction will cut through a minimum number of edges. A
common operation is to boolean a bunch of round holes from a broad, flat object. This gets quite nasty since
each successive boolean compounds the surface segmentation. Fortunately, there is an easy fix: subdivide
the surface first so each boolean is within it's own "space" to prevent a sea of faces radiating from the
boundaries. Successive booleans trying to cut through this sea will likely fail. For example, to boolean an
array of round holes in a flat plate, I use Slice, Cut, or other methods to subdivide the plate into rectangles so
each hole is confined within one rectangle. This method also works great when subtracting a bunch of window
and door holes from a wall.

- Each operand should consist of only one "element" in the area of the boolean, i.e., you should not attach two
meshes together and then try to subtract a third mesh that overlaps more than one element. If the object is a
mesh, use the Element selection tool under sub-obj/Face to see which parts of a mesh are a single element.
Detach and union overlapping elements together before applying a boolean through the overlap area.

- Use the CapHoles modifier or sub-obj Face/Create to fill holes. Use edge and face delete if STL-Check
reports any duplicates. Bobo's wrote a great script that can remove duplicate faces very difficult to remove any
other way.

- For persistent problems, "jog" or move one operand slightly with respect to the other. If this is not practical,
go into sub-obj mode and move some of the vertices a little. Problems seem to arise if two vertices are
extremely close to each other, if two faces are co-planer, or two edges co-linear.

- If given a file to work with that has a bad boolean, it can usually be salvaged by extracting both operands
(even through several levels), checking, fixing, and re-doing the boolean(s).

- Some people recommend increasing the face density on operands (by tessellating or other means) for a
problem boolean. I've found the opposite to be true - generally the simpler the operand the better.

- I've seen several cases where a rogue boolean was fixed by adding an Optimize modifier with a low (0.1) face
threshold.

---------------------------------
There are a few other things to consider, but I'm getting tired of typing! I wish the docs would provide some
additional boolean hints and perhaps even a tutorial on some of these points - that may help to change the
somewhat "flaky" reputation that 3DS and Max booleans have enjoyed for years.
JKJ

(PS: some of the opinions expressed above are based personal experience and are not necessarily those of
the management)