Storage and Synchronization of Rigid Bodies and Constraints in a Mechanical Engine

Problem Description

Mechanical equipment is more complex than electrical equipment. In electricity, the engine only handles electrical data calculation and does not involve any changes to equipment attributes (including geometric and electrical attributes); saving and restoring does not need to consider engine impact. In mechanics, equipment geometric attributes are computed by the engine, relationships between equipment are maintained by constraints in the engine, and physical attributes may affect equipment state, requiring more considerations and making implementation more complex.

Problem Analysis

In mechanics, the objects we handle are rigid bodies and constraints; the display is just a skin that follows the rigid‑body motion, so we need to store the properties of rigid bodies (e.g., position, rotation) rather than equipment properties (the position of a rigid body and equipment may differ but are proportional).

In electrical equipment, connections between equipment are maintained by a “slot model”, while in mechanics they are maintained by constraints, so we also need to store constraints.

Rigid Body Storage and Restoration

For rigid bodies, we consider position, rotation angle, velocity (including linear and angular), and forces. Position and rotation must be stored; previously equipment also stored them, but values may differ. Velocity should also be stored. For forces, the main driving force does not need to be stored; the engine adds it during calculation, and constraint forces are also computed by the engine, so they are not stored. Therefore, for rigid bodies we need to store coordinates, rotation angle, linear velocity, and angular velocity.

For mechanical equipment, a piece may consist of a single rigid body or multiple rigid bodies combined. The connections between rigid bodies (which may belong to the same or different equipment) are maintained by constraints. We need to save the position and angle of all rigid bodies, even if they are fully constrained. Internal constraints of equipment do not need to be stored because they are fixed at creation and do not change; if they do change, they would need to be stored, but so far none have been encountered.

Constraint Storage and Restoration

We only consider constraints between equipment, not internal constraints. Mechanical constraints correspond to the electrical “slot model”.

There are many types of constraints in a mechanical engine, appearing complex, but they can be abstracted: all constraints limit the positional relationship of two rigid bodies (e.g., a pulley in Nape involves four bodies). Constraint c = f(p1, p2) = 0; the electrical slot model also limits two equipment positions (slot follows pin), constraint c = f(p1, p2) = p1 - p2 = 0. Thus we can unify them; regardless of implementation, we only need to know which entities are connected, not how the connection is realized.

Side note: during experiments, binding between rigid bodies (e.g., hook and latch) follows the same logic as the slot model: collision detection → determine if connection possible → if so, connect.

Synchronization

We use state synchronization to achieve teacher‑side and student‑side sync. Synchronization and save/restore use the same data; as long as we synchronize all rigid‑body and constraint states (in electricity we did not sync all states), the visual states on both sides are consistent. When both teacher and student engines are active (student engine off makes it a pure player), no inconsistency has been observed. Mechanical synchronization is not as difficult as imagined, data size is not large, though unexpected issues may arise, they are not unsolvable.

Additionally, in mechanics, dragging a rigid body may be implemented using a constraint; this interaction‑created constraint does not need to be saved for restore, but if omitted during synchronization, the rigid body may oscillate.