MeshBoolean

Remarks

Doc 24's P6, and the phase it says to budget as though it were two. Every mesh boolean that produces holes produces them because a classification near zero answered wrongly and the two sides of a cut stopped agreeing about which side they were on. That is not a tolerance to tune; it is a question with an exact answer, and Orient3D gives it.

⚠ A plane is three points, and they are the ones that defined it. Doc 24 asks for planes rather than points, and this is the shape that takes: a face's supporting plane is recorded as three corners of the original operand and never recomputed, so classifying any original vertex against any original plane is one exact predicate over inputs that were never arithmetic. A normal and an offset derived in floating point would be a fourth number that disagrees with the three it came from, which is precisely the disagreement that opens a crack between a wall and the floor it is coplanar with.

⚠ A vertex made by a split remembers the plane it was made on, and that is what keeps the cut closed. Its position is arithmetic and so is inexact; its membership is not. Asked which side of that plane it is on, it answers "on it" from the record rather than from a subtraction — for ever, through every later split — so the two faces either side of a cut can never be told apart by it. A point on a segment also lies on every plane both its endpoints lie on, so membership propagates through a split rather than being rediscovered.

⚠ What that does not buy: a split vertex against a plane it was not made on. Three planes meeting at a point is a position computed in floating point, and its side of a fourth plane is a floating-point question — the fully plane-based answer is a four-plane determinant, which is a predicate this engine does not have. What is exact is every original vertex against every original plane, and every derived vertex against the planes it was derived on, which between them are the cases a block-out is made of: coplanar walls, shared edges, identical operands, and an operand sitting exactly on another's face.

A BSP over the faces, which is the algorithm rather than the interesting part. Each solid is built into a tree of its own planes, each is clipped against the other's, and what survives is combined per the operation. It is Naylor–Amanatides–Thibault, and it is what csg.js, Quake's tooling and RealtimeCSG all are; the difference between one that works and one that does not is entirely in the classification above.

Fields and properties (1)

• public const int CapGroup

  The face group a plane cut's cap goes in.

Methods (3)

• public static EditMesh? Apply(EditMesh left, EditMesh right, BooleanOperation operation, Matrix4x4? transform = null)

  Combines two solids.

• public static EditMesh? PlaneCut(EditMesh mesh, Plane plane, bool keepFront = false, bool cap = true)

  Cuts a solid with a plane and keeps one side of it, or both.

• public static EditMesh? Trim(EditMesh mesh, EditMesh cutter, Matrix4x4? transform = null)

  Cuts a solid by another one's surface and keeps the part outside it.

Used by (5)

• BspNodeVixen.Geometry
• MeshBooleanPropertyTestsVixen.Geometry.Tests
• MeshBooleanTestsVixen.Geometry.Tests
• BlockoutBooleanVixen.Editor.Blockout
• SceneCsgVixen.Editor.SceneView