I found a thread from 2015 where connectivity was discussed. I also know that both stud.io and LDcad encode connectivity.
Would LDraw files benefit from having connectivity metadata?
There are a relatively small number of connection types. More than LDcad uses, but small enough to be enumerated.
Studs go into stud holders, antistuds go into antistud holders, clips (bar holders) can be radial or axial when attached to bars.
The majority of snapping connections can be described by a point and a direction vector, so effectively the same as a LDraw type 1 line. The type of connector can be in the subfile argument. If the connector types match and the directions vectors align, then the connection can snap into place, meaning that the points are made to overlap by adjusting one.
Sliding connectors (bars) need two points, which can be encoded as a point and a vector or similar to type 2 lines. Bar holders come in two flavors; those that attach radially (c-clips) and those that attach axially (o-clips and bar holes). The c-clips require another direction vector.
Hinge connectors also need a point and an axis of rotation, which can be encoded as a type 1 line. If an additional direction vector is available, then the hinge halves can be made to not overlap one another.
Ball connectors need a point and would benefit from knowing which way (direction) is definitively inappropriate (directional vectors must not overlap).
Many generic clipping connectors are adequately described by a single point.
Gears are a challenge, because there are two things to consider; the distance between rotational axes, and the toothing. Some gear pairs can connect slightly too close to each other and some gear pairs can connect very loosely without loosing function. So, snapping to a "perfect" distance is not an option. The software must calculate if any two gears interact or not.
As for the rotation, the minimum information is a point for the axis, an axial vector, and a reference point on the teethed perimeter.
Sometimes gears do not connect to other gears, but toothed shapes. The teethed path can be described by a set of line segments. The direction of the teeth can be described by a vector. The position of teeth relative to the line can be described by a reference point along that line.
The above is the information needed for each of the parts that interact. It is then up to the software to use that information to calculate the nature of the interaction.
Would LDraw files benefit from having connectivity metadata?
There are a relatively small number of connection types. More than LDcad uses, but small enough to be enumerated.
Studs go into stud holders, antistuds go into antistud holders, clips (bar holders) can be radial or axial when attached to bars.
The majority of snapping connections can be described by a point and a direction vector, so effectively the same as a LDraw type 1 line. The type of connector can be in the subfile argument. If the connector types match and the directions vectors align, then the connection can snap into place, meaning that the points are made to overlap by adjusting one.
Sliding connectors (bars) need two points, which can be encoded as a point and a vector or similar to type 2 lines. Bar holders come in two flavors; those that attach radially (c-clips) and those that attach axially (o-clips and bar holes). The c-clips require another direction vector.
Hinge connectors also need a point and an axis of rotation, which can be encoded as a type 1 line. If an additional direction vector is available, then the hinge halves can be made to not overlap one another.
Ball connectors need a point and would benefit from knowing which way (direction) is definitively inappropriate (directional vectors must not overlap).
Many generic clipping connectors are adequately described by a single point.
Gears are a challenge, because there are two things to consider; the distance between rotational axes, and the toothing. Some gear pairs can connect slightly too close to each other and some gear pairs can connect very loosely without loosing function. So, snapping to a "perfect" distance is not an option. The software must calculate if any two gears interact or not.
As for the rotation, the minimum information is a point for the axis, an axial vector, and a reference point on the teethed perimeter.
Sometimes gears do not connect to other gears, but toothed shapes. The teethed path can be described by a set of line segments. The direction of the teeth can be described by a vector. The position of teeth relative to the line can be described by a reference point along that line.
The above is the information needed for each of the parts that interact. It is then up to the software to use that information to calculate the nature of the interaction.
