How incremental sync works
Every object carries a fingerprint computed from the geometry stored in the file — control points, knots, weights, topology counts — quantised to 1e-6 model units. Not from the tessellation.
Three consequences:
Reconnecting is cheap. On connect, the two sides compare fingerprints and transfer only what differs. Reconnecting to an untouched document transfers nothing.
Moving is cheap. Control points are recentred on their own bounding box before hashing, so a pure translation leaves the fingerprint unchanged and the object takes the transform-only path: a matrix goes over the wire, the mesh does not.
Windows and macOS agree. Because the fingerprint comes from stored values rather than computed tessellation, both platforms produce the same number for the same geometry. Syncing one .3dm alternately from a PC and a Mac stays incremental.
The fingerprint is salted with the mesh-detail setting, so changing Detail or toggling Clean quads correctly resends geometry that was tessellated at the old setting.
What travels:
Change in Rhino | Sent |
|---|---|
Move / rotate / scale | Transform matrix |
Geometry edit | That object's mesh |
Material change | Material definition |
Edit inside a block definition | That definition |
Named view or light change | Metadata, no geometry |
Nothing changed | Nothing |
Geometry travels as packed float32 and int32 buffers under zlib. Large documents arrive in chunks with a progress bar.
The client pings every 10 seconds on a priority channel that jumps ahead of queued bulk data, so a long sync cannot starve the heartbeat and cause a false disconnect. If the link drops, the client retries every 2 seconds.