How a ContentMatch relates its base and head members (issue
#1891, DiffOptions.matchUnpairedByContent):
renamed — the base and head members share a data hash AND a world
geometry hash: same content, same place, different key (re-GUID/rename).
Usually one entity per side; a group of N per side is reported as one
renamed match when both sides agree on both hashes N times over,
because every bijection between them is then indistinguishable.
moved — one base and one head entity share a data hash but not a
geometry hash, and their bounding boxes are the same size in every axis
while their centres are further apart than DiffOptions.moveTolerance.
Without an EntityFingerprint.aabb on both sides this is also what
a bare geometry-hash difference reports, since nothing can tell a move
from a reshape.
reshaped — one base and one head entity share a data hash but not a
geometry hash, and their bounding boxes differ in size beyond
DiffOptions.reshapeTolerance — or agree entirely, which is what a reshape
confined to the interior looks like. A pure re-triangulation of an
unchanged surface no longer lands here (the geometry hash is
retriangulation-invariant), but a re-tessellation that introduces new
vertices still does, and a bounding box genuinely cannot separate that from
an interior reshape. This kind does not pretend otherwise.
respecified — one base and one head entity share a world geometry hash
and a bounding box but NOT a data hash: same shape in the same place, new
key, changed data (issue #4955). The delete-and-redraw case when the
authoring tool auto-renamed the element. Always exactly one per side; an
N:N geometry bucket is reported as ambiguous instead, because members
that differ in data are not interchangeable. changedComponents says
which data slices moved.
duplicated — one base entity's content matches several head entities
(it looks like it was copied).
deduplicated — several base entities' content matches one head entity
(they look like they were merged into one).
ambiguous — several candidates remain on both sides with no
principled pairing: the engine could not tell duplication from
deduplication, or positions were symmetric enough that no base was any
head's unique nearest neighbour, or the only candidates were further apart
than DiffOptions.maxMoveDistance.
How a ContentMatch relates its
baseandheadmembers (issue #1891,DiffOptions.matchUnpairedByContent):renamed— the base and head members share a data hash AND a world geometry hash: same content, same place, different key (re-GUID/rename). Usually one entity per side; a group ofNper side is reported as onerenamedmatch when both sides agree on both hashesNtimes over, because every bijection between them is then indistinguishable.moved— one base and one head entity share a data hash but not a geometry hash, and their bounding boxes are the same size in every axis while their centres are further apart thanDiffOptions.moveTolerance. Without an EntityFingerprint.aabb on both sides this is also what a bare geometry-hash difference reports, since nothing can tell a move from a reshape.reshaped— one base and one head entity share a data hash but not a geometry hash, and their bounding boxes differ in size beyondDiffOptions.reshapeTolerance— or agree entirely, which is what a reshape confined to the interior looks like. A pure re-triangulation of an unchanged surface no longer lands here (the geometry hash is retriangulation-invariant), but a re-tessellation that introduces new vertices still does, and a bounding box genuinely cannot separate that from an interior reshape. This kind does not pretend otherwise.respecified— one base and one head entity share a world geometry hash and a bounding box but NOT a data hash: same shape in the same place, new key, changed data (issue #4955). The delete-and-redraw case when the authoring tool auto-renamed the element. Always exactly one per side; an N:N geometry bucket is reported asambiguousinstead, because members that differ in data are not interchangeable.changedComponentssays which data slices moved.duplicated— one base entity's content matches several head entities (it looks like it was copied).deduplicated— several base entities' content matches one head entity (they look like they were merged into one).ambiguous— several candidates remain on both sides with no principled pairing: the engine could not tell duplication from deduplication, or positions were symmetric enough that no base was any head's unique nearest neighbour, or the only candidates were further apart thanDiffOptions.maxMoveDistance.