← All posts

Product update4 min read

Joining two scans that don't share an origin

Two rooms scanned separately have two unrelated origins. Recent builds combine them by their overlapping shape, and hand the choice over when the geometry is ambiguous.

Two maps, two origins

ICIDO saves each scanned place as its own map. Each place keeps its own ARWorldMap and its own coordinate frame, and an AR session relocalizes against exactly one map at a time. The origin of that frame is wherever the session happened to start.

Scan a kitchen one day and the hallway outside it the next, and you have two maps of one building with nothing in common. Both are metric. Both are gravity-aligned with the +Y axis up, so they agree about which way is down — a top-down view of either is just a matter of dropping the Y axis. What neither map knows is where the other one begins, or which way it is facing.

That gap is a real limitation, not a detail. Because each place is its own frame, a single route cannot span two places. One way to attack the problem is to stop having two places.

Overlap is the only clue

On 15 July a commit landed titled "Combine two already-scanned places by their overlapping shape" (ed5fbd6). The requirement is in the title: the two maps have to overlap. Some of the same physical surface — a stretch of wall, a section of floor — must appear in both, because that shared geometry is the only evidence available for how the two frames relate.

Aligning two sets of measured points by repeatedly pairing nearby features and solving for the transform that best brings them together is a standard registration technique. The current implementation uses point-to-line ICP (d6774dd).

Two harder questions sit in front of that. Which rotation do you even start from, and how do you know the answer you got is the right one? Registration was rebuilt on 21 July with contradiction-aware scoring and a global rotation search (f3c790e) — global meaning it searches the full range of orientations rather than refining a single initial guess. A related fix removed nondeterministic orientation ranking (add5079), so the same two maps stop producing different answers on different runs.

When the geometry cannot decide

Sometimes the shape genuinely does not settle it. More than one orientation fits the overlap about equally well, and no amount of scoring can pick between them, because the information is not there.

The handling of that case changed twice in a week, and the sequence is worth reading in order:

  • Ambiguous orientations were rejected outright (a9ef1fd).
  • Then they were offered with a warning instead of being suppressed (be6dcc5).
  • Then the choice was handed to the person holding the phone: pick the join orientation when the geometry can't (7fdcb29).

The same instinct shows up in the surrounding commits. The app asks before building a combined preview on a geometry match (107b808), gates the automatic offer on absolute overlap, and treats a declined offer as a cooldown rather than re-asking (e6d9cbd). A map is not something to rewrite on a guess.

After the save, not during the scan

There is an older path for growing a map — Update Map — and it carries a hard constraint from ARKit: a session can only relocalize into a map it was started with. So that path has to be decided before scanning begins.

Combining by geometry escapes that. Overlap is detected by registering geometry, never by pausing the scan (ae5ae58), which means it does not need the live session at all. The offer accordingly moved to after Save, where both maps are complete (08280e5). By 22 July, combine is always offered after a save and the old merge setting is gone (d6774dd).

Keeping the seam honest

Even a good alignment is not exact. A small residual remains, and if that residual is read as a mismatch, the region both maps captured gets stored twice — one wall becoming two, slightly offset. An 18 July commit tolerates the alignment residual so overlap is not doubled (7a5a78a).

The same care applies wherever ICIDO folds new geometry into a place it already has. In the documented update flow, old triangles inside the new scan's bounds are replaced by the new geometry while areas the new scan never visited are kept, and floor area is recomputed from the result. The top-down map is then rasterised into a grid fixed at 12 cm cells for saved maps, which is what turns noisy triangles into a floor plan solid enough to route across.

Still on the device

None of this reaches a server. ICIDO makes no network connections and has no accounts, no sign-in and no analytics. Scanned maps, tagged spots and settings are stored locally on the iPhone. Combining two places is two local files being read on the phone that holds them.

Where this is

The work described here is in TestFlight builds. ICIDO is coming to the App Store, and scanning requires the LiDAR sensor — iPhone 12 Pro and later Pro models.

Related reading