Geometric Primitives & Intersection Tests
Geometry & Trigonometry
Chapter 9 · Geometric Primitives & Intersection Tests
Chapter 4 introduced the cross-product's sign as a "which side" test. Chapter 8 built a consistent coordinate pipeline every object shares. This chapter assembles the actual toolkit that answers "do these two things touch?" — the real question behind collision detection, mouse-picking, and ray tracing.
Line-Line Intersection
For two lines through (P1,P2) and (P3,P4), the standard formula finds the intersection directly, with the denominator itself signaling the degenerate case:
(0,0)-(4,4) and (0,4)-(4,0) — an X shape — intersect at exactly (2, 2), the visually obvious crossing point. Lines through (0,0)-(4,4) and (1,0)-(5,4) — two parallel diagonals — give a denominator of exactly 0, correctly signaling "no intersection" rather than a division error, since parallel lines never cross.
Ray-Sphere Intersection: A Real Application of Numerical Methods & Floating-Point Computation's Own Quadratic Formula
Substituting a ray's parametric equation O+tD into a sphere's equation |P−C|²=r² produces a genuine quadratic in t: at²+bt+c=0, where a=D·D, b=2D·(O−C), and c=(O−C)·(O−C)−r². This is exactly the quadratic formula Numerical Methods & Floating-Point Computation Chapter 4 already verified can be numerically dangerous — and ray-sphere intersection is one of the most common places that danger shows up in real code.
O=(50000,0,0), direction D=(−1,0,0), sphere centered at C=(0,0,0) with squared radius r²=2,499,999,999 (radius ≈49999.99999) — a physically ordinary setup: a ray starting far from a large sphere, aimed at it. The resulting quadratic coefficients come out to exactly a=1, b=−100000, c=1 — the identical coefficients Numerical Methods & Floating-Point Computation Chapter 4 already solved. The naive (−b±√disc)/2a formula's near intersection point has a relative error of ≈3.38×10⁻⁷; the stable ("Citardauq") reformulation gives ≈1.14×10⁻¹⁶ — the exact same nine-orders-of-magnitude improvement already verified there, now confirmed in a genuine geometric context rather than an abstract equation.
Ray-Plane Intersection
For a plane through point Q with normal N, and a ray O+tD: t = (Q−O)·N / (D·N). A zero (or near-zero) denominator means the ray is parallel to the plane.
D=(0,0,1), against the horizontal plane z=5 (Q=(0,0,5), N=(0,0,1)): t=5.0, hitting exactly (0,0,5). The same plane tested against a horizontal ray, D=(1,0,0): D·N=0 exactly, correctly signaling the ray runs parallel to the plane and never reaches it — the same denominator-as-degeneracy-signal pattern as the line-line case above.
Point-in-Polygon: Extending Chapter 4's Side Test to a Whole Shape
For a convex polygon, a point is inside if it's on the same side of every edge — exactly Chapter 4's cross-product sign test, applied once per edge and checked for consistency.
(0,0),(4,0),(4,4),(0,4): the point (2,2) gives all four cross-product signs positive (8,8,8,8) — clearly inside. The point (5,2) gives mixed signs (8,−4,8,20) — clearly outside. The point (4,2), sitting exactly on the right edge, gives one sign of exactly 0 and the rest positive — a genuine boundary case, classified as "inside" only because the test used ≥0 rather than strict >0.
0 once real floating-point coordinates are involved, making a small tolerance around the boundary — not strict >0/<0 — the more robust real-world choice.
Where This Connects
| This chapter's finding | What it draws on |
|---|---|
| Ray-sphere intersection reproducing Numerical Methods & Floating-Point Computation Chapter 4's exact numbers | A direct, concrete real-world application of a prerequisite course's own core finding, not just a passing mention |
| A zero denominator signaling "parallel," in both line-line and ray-plane tests | The same degeneracy-detection instinct from Numerical Methods & Floating-Point Computation's own conditioning material, applied geometrically |
| Point-in-polygon's boundary case needing an explicit tolerance decision | Directly echoes Chapter 1's own 0.1+0.2 exact-equality warning, now applied to a geometric test instead of arithmetic |
Hands-On Exercises
Using this chapter's own line-line formula, find the intersection point of the line through (1,1) and (5,5) with the line through (1,5) and (5,1).
Using this chapter's own verified ray-sphere finding, explain specifically why a ray tracer using the naive quadratic formula would tend to produce its worst visible errors on rays that hit a sphere at a shallow, grazing angle rather than a ray that hits the sphere dead-on through its center.
📄 View solutionUsing this chapter's own point-in-polygon boundary-case finding, explain why a UI system that checks whether a mouse click landed exactly on a button's edge using strict cross-product signs (rather than a small tolerance) could cause a real, observable bug for the user, and describe what that bug would look like.
📄 View solutionChapter 9 Quick Reference
- Line-line intersection: a determinant-style formula; a zero denominator means parallel lines — verified
(2,2)crossing point and a verified parallel case - Ray-sphere intersection: substituting the ray into the sphere equation gives a genuine quadratic — verified to reproduce Numerical Methods & Floating-Point Computation Chapter 4's exact numbers (
≈3.38×10⁻⁷naive vs.≈1.14×10⁻¹⁶stable) in a real geometric setup - Ray-plane intersection:
t=(Q−O)·N/(D·N); a zero denominator means the ray is parallel to the plane — verified with a real hit point and a verified parallel case - Point-in-polygon (convex): Chapter 4's cross-product side test, applied to every edge — verified inside/outside/boundary cases, with an honest note that boundary inclusion is a real design decision needing a tolerance, not strict equality
- Next chapter: Capstone — building a small 2D/3D geometry toolkit that exercises every chapter in this course together