Window/Crossing Selection

03/29/2026

• Two Drag Modes
• CAD tools traditionally distinguish two rectangle-drag selection modes: window selection picks only the geometry that is fully enclosed by the rectangle, while crossing selection picks anything the rectangle fully encloses or merely intersects. AutoCAD, Rhino, and most parametric modelers use the drag direction itself as the toggle: left-to-right means window, right-to-left means crossing.
• The mode is inferred from a single comparison between the pointer's down position and its current position:

  
      protected get isCrossingSelect(): boolean {
          if (!this.rect) return false;
          return this.rect.currentX < this.rect.clientX;
      }
  

  If the cursor's current x is to the left of where the drag started, the user is dragging right-to-left, so the mode is crossing.





• Drawing the Rubber-Band Rect
• The rectangle is a plain absolutely-positioned div appended to the main window on pointerdown and removed on pointerup. The visual style flips on every pointermove based on the drag direction — window mode draws a solid blue border with a translucent blue fill, while crossing mode switches to a dashed green border with a lighter fill, giving the user the same visual cue they would see in AutoCAD:

  
      protected updateRect(rect: SelectionRect, event: PointerEvent) {
          if (this.pointerEventMap.size !== 1) return;
          rect.currentX = event.clientX;
          rect.element.style.display = "block";
          const [x1, y1] = [Math.min(rect.clientX, event.clientX), Math.min(rect.clientY, event.clientY)];
          const [x2, y2] = [Math.max(rect.clientX, event.clientX), Math.max(rect.clientY, event.clientY)];
          const crossing = event.clientX < rect.clientX;
          Object.assign(rect.element.style, {
              left: `${x1}px`,
              top: `${y1}px`,
              width: `${x2 - x1}px`,
              height: `${y2 - y1}px`,
              borderStyle: crossing ? "dashed" : "solid",
              backgroundColor: crossing ? "rgba(74, 255, 158, 0.15)" : "rgba(74, 158, 255, 0.3)",
              borderColor: crossing ? "var(--success-color, #4ade80)" : "var(--primary-color)",
          });
      }
  

• The handler also requires a 3-pixel deadzone before treating the gesture as a rectangle drag. Below that threshold the pointer is still treated as a single click, so a sloppy mouse-down doesn't accidentally open a tiny selection box.


• Two Hit Tests, One Rectangle
• Once the user releases the mouse, each candidate object is projected onto screen space — every vertex of the geometry is run through worldToScreen, producing a 2D point cloud and an edge list. The mode then selects between two completely different tests.


• Window — every projected vertex must lie inside the rectangle:

  
      private allPointsInsideRect(pts, minX, minY, maxX, maxY): boolean {
          for (const p of pts) {
              if (p.x < minX || p.x > maxX || p.y < minY || p.y > maxY) return false;
          }
          return pts.length > 0;
      }
  

  A single vertex outside the box disqualifies the whole object. This is fast (early-exit on first miss) and matches the user's mental model: if any visible bit of the part pokes out of the rectangle, it isn't selected.


• Crossing — selected if any part of the geometry overlaps the rectangle. The check has two stages: first, any vertex inside the rectangle is an immediate hit; second, every geometry edge is tested against each of the four rectangle edges using a 2D segment-intersection routine:

  
      private anyCrossingHit(pts, edges, minX, minY, maxX, maxY): boolean {
          // 1) any vertex inside rect
          for (const p of pts) {
              if (p.x >= minX && p.x <= maxX && p.y >= minY && p.y <= maxY) return true;
          }
          // 2) any geometry edge crosses rect boundary
          const rectEdges = [
              [minX, minY, maxX, minY],
              [maxX, minY, maxX, maxY],
              [maxX, maxY, minX, maxY],
              [minX, maxY, minX, minY],
          ];
          for (const [ai, bi] of edges) {
              const pa = pts[ai], pb = pts[bi];
              for (const [ex1, ey1, ex2, ey2] of rectEdges) {
                  if (segmentsIntersect(pa.x, pa.y, pb.x, pb.y, ex1, ey1, ex2, ey2)) return true;
              }
          }
          return false;
      }
  



• The two stages cover the two ways an edge can intersect a rectangle: an endpoint inside (caught by stage 1) or an edge that passes through the rectangle without either endpoint being inside (caught by stage 2). Without stage 2, a long line crossing the box from edge to edge would be missed.





• 2D Segment Intersection
• The crossing test reduces to the standard parametric line-segment intersection. Given segments \(P_1P_2\) and \(P_3P_4\), express each as a parametric form and solve for the parameters \(t, u\):
  \[ t = \frac{(x_3 - x_1)(y_4 - y_3) - (y_3 - y_1)(x_4 - x_3)}{(x_2 - x_1)(y_4 - y_3) - (y_2 - y_1)(x_4 - x_3)} \]
  \[ u = \frac{(x_3 - x_1)(y_2 - y_1) - (y_3 - y_1)(x_2 - x_1)}{(x_2 - x_1)(y_4 - y_3) - (y_2 - y_1)(x_4 - x_3)} \]
  
  The segments intersect if and only if \(0 \le t \le 1\) and \(0 \le u \le 1\). The denominator is the 2D cross product of the two direction vectors — if it's near zero, the segments are parallel and skipped:

  
      function segmentsIntersect(x1, y1, x2, y2, x3, y3, x4, y4): boolean {
          const dx1 = x2 - x1, dy1 = y2 - y1;
          const dx2 = x4 - x3, dy2 = y4 - y3;
          const denom = dx1 * dy2 - dy1 * dx2;
          if (Math.abs(denom) < 1e-10) return false;
          const t = ((x3 - x1) * dy2 - (y3 - y1) * dx2) / denom;
          const u = ((x3 - x1) * dy1 - (y3 - y1) * dx1) / denom;
          return t >= 0 && t <= 1 && u >= 0 && u <= 1;
      }
  



• World-to-Screen Projection
• The hit test runs in pixel coordinates, so the real question is: given a 3D vertex on a CAD object, what 2D pixel does it land on? worldToScreen collapses the standard graphics pipeline — view transform, projection, perspective divide, viewport remap — into a single helper:

  
      worldToScreen(point: XYZ): XY {
          const cx = this.width / 2;
          const cy = this.height / 2;
          const vec = new Vector3(point.x, point.y, point.z).project(this.camera);
          return new XY({ x: Math.round(cx * vec.x + cx), y: Math.round(-cy * vec.y + cy) });
      }
  



• Three.js's Vector3.project(camera) applies the camera's view matrix \(M_{\text{view}}\) and projection matrix \(M_{\text{proj}}\), then performs the perspective divide. The result is in normalized device coordinates (NDC) — a unit cube where each axis lies in \([-1,\, 1]\):
  \[ \mathbf{p}_{\text{clip}} = M_{\text{proj}}\, M_{\text{view}}\, \mathbf{p}_{\text{world}}, \quad \mathbf{p}_{\text{NDC}} = \frac{\mathbf{p}_{\text{clip}}}{w_{\text{clip}}} \]
  
  Mapping NDC to pixels is a straight affine remap. Note the y-axis flip — NDC y points up, but screen y points down:
  \[ x_s = \tfrac{w}{2}\,(x_{\text{NDC}} + 1), \qquad y_s = \tfrac{h}{2}\,(1 - y_{\text{NDC}}) \]


• Vertices on a three.js Object3D start in local space — each object has its own coordinate frame. localToWorld applies the object's matrixWorld, bringing local vertices into the shared world frame that worldToScreen expects:

  
      private projectGeometry(obj: Object3D) {
          // ...
          const v = new Vector3();
          const pts: { x: number; y: number }[] = [];
          for (let i = 0; i < posAttr.count; i++) {
              v.fromBufferAttribute(posAttr, i);                // local-space vertex
              obj.localToWorld(v);                              // local → world
              pts.push(this.worldToScreen({ x: v.x, y: v.y, z: v.z }));
          }
          // ...
      }
  

  
  The full chain for a single vertex is therefore:
  \[ \mathbf{p}_{\text{local}} \;\xrightarrow{M_{\text{world}}}\; \mathbf{p}_{\text{world}} \;\xrightarrow{M_{\text{view}}}\; \mathbf{p}_{\text{view}} \;\xrightarrow{M_{\text{proj}}}\; \mathbf{p}_{\text{clip}} \;\xrightarrow{\div\, w}\; \mathbf{p}_{\text{NDC}} \;\xrightarrow{\text{viewport}}\; \mathbf{p}_{\text{screen}} \]


• One subtlety: this projection is a silhouette test, not a visibility test. A vertex behind another object still projects to wherever the camera would see it if nothing occluded it, so window / crossing selection picks parts by their on-screen outline — not by which pixels the user can actually see. That matches AutoCAD and Rhino: a part hidden behind a wall is still selectable as long as its outline lands inside the rectangle.


• For ordinary three.js meshes and lines the projection loops over the position buffer attribute, with the edge list reconstructed from the geometry type (LineSegments pairs vertices, Line chains them, Mesh uses the index buffer to build triangle edges).


• Fat lines (LineSegments2) are special-cased: their geometry doesn't store a position attribute at all. Instead each segment's start and end are stored separately in instanceStart and instanceEnd instanced attributes, so the projection has to read both attributes side-by-side and emit them as alternating points. Without this branch, fat-line edges silently never appear in any rectangle selection.



• Shape-Level vs Visual-Level
• The visual-level path above (detectVisualRect) is what runs for whole-object picks like "select these parts." For sub-shape picks — selecting individual edges or faces of a B-Rep — the code delegates to three.js's built-in SelectionBox, which performs a true 3D frustum test against the scene:

  
      detectShapesRect(shapeType, mx1, my1, mx2, my2, ...) {
          // Shape-level rect selection uses SelectionBox for both modes
          // (crossing/window distinction is handled at visual level)
          const selectionBox = this.initSelectionBox(mx1, my1, mx2, my2);
          const detecteds: VisualShapeData[] = [];
          for (const obj of selectionBox.select()) {
              this.addDetectedShape(detecteds, ..., shapeType, obj, ...);
          }
          return detecteds;
      }
  



• SelectionBox builds a frustum from the camera and the two NDC corners of the drag rectangle, then walks the scene graph and keeps any object whose bounding volume falls inside. It doesn't itself distinguish window from crossing — that distinction is handled one layer up, where the screen-space projection has finer control over each vertex.

---