summaryrefslogtreecommitdiffstats
path: root/_log/2d-geometry-kernel.md
blob: 385df18ab598dfcf80b54d5fbdfa35d2f66db16d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
---
title: Built a 2D geometry kernel
date: 2022-07-31
layout: post
---

Written in 2026, backdated to 2022.

Joined real estate firm mid-migration (C# to Java). Java version lacked a
geometry kernel; project stalled.

Geometries were small, mostly 2D—no frame budget or low-latency constraints.
Architects supplied test cases and tolerances; numerical parity with Rhino was
mandatory.

Implemented polygon clipping with Sutherland–Hodgman. No drama.

Fortune's algorithm for Voronoi diagrams was a missed opportunity. Implemented
the beach line with an array (O(N<sup>2</sup>)). Didn't pursue the balanced
binary tree (O(N log N))—ran out of time.

Polygon offsets had always been problematic. Two Z and H-shaped floor plans
produced self-intersections that tripped Rhino. Straight skeletons had too many
edge cases we didn't need—hard to get right under time pressure. Implemented a
custom solver that fixed invalid loops by backtracking.

Finding the largest inscribed rectangle was messy. No single algorithm covered
both convex and concave shapes. Found a paper on the convex case, but couldn't
translate the math to code. Fell back to a brute-force grid search: 12% gain,
but not the true optimum.

Rhino's BLAS-based linear algebra and Java's Binary Space Partitioning were
numerically incompatible. Replaced BSP trees with vector-based structures.
JBLAS reconciled most floating-point issues.

Migration resumed. No regressions in the building layouts.