Do we need another LDraw building program?

[Ben Supnik]

Hi Mario,

Thanks for the detailed explanation. I've been researching connectivity for Bricksmith so I'm trying to understand what people are already doing and trying.

There are some parts where axlehole is "+" oriented and other where axlehole is "x" oriented, so we need to add "orientation" to the connection itself (to the axlehole and to the axle).

Right - I suppose that inherent in the connection type is the rule about alignment, e.g. which way the "+" sits in a default, untransformed connection.

To keep program and logic simple, I chose to place multiple connection type on the same coordinates. Using your example, the "open stud" has three connetion type, two coincident: a plain stud, a "clip" type for bar and a underside pin receiver (a "stud3.dat"), to allow connection of a brick 1x2 on a plate 1x2 with single stud open on top (jumper).

This is a really interesting approach to me, because it -greatly- simplifies the connection logic, in return for a moderate increase in the number of connections on a part. (With this system, the bar now has 3 connectors instead of 1, and the stud has two instead of 1.)

My original idea was many-to-many relationships, so a technic hole could match a pin or an axle or a friction pin. With your scheme, the technic hole now must be several types of connectors:
- Stud receiver
- Pin receiver
- Axle receiver
- Friction pin receiver (if friction isn't modeled)

The win here, I think, is that the _constraints_ of these different uses of the technic hole are different. So under your system:

- technic hole + axle = rotation + translation (2 DOF, defined by axis of axle)
- technic hole + pin = rotation (1 DOF, defined by axis of axle)
- technic hole + stud = locked (0 DOF, a rigid body)

My original design required knowing that various combinations of connectors had different constraints.

There is one 'annoyance', namely that -every- technic hole will then need a series of connectors. But I think the heavy use of primitives can take the sting out of this. A technic hole primitive could be marked with all needed connectors on the primitive level, or we could even develop new primitives, e.g. "connectors for standard technic hole" that puts down all technic hole connectors with a single sub-file.

I chose to lower amount of mathematics and logic for every connection, because number of connections in a simple model it easily grows over thousands. A plain 2x8 plate has 39 connections, a 4x8 plate has 85 connections and so on...

On the other hand, I think that define too many conneciton type can be confusing.

I've been assuming that the number of connectors is just going to get really really huge...put your model on a 48x48 base plate and you start with over 2000 connectors before you even add bricks. My airport model covers 171 baseplates, so even if a lot of them have studs missing for roads, there might be 40k studs without the bricks.

So programmers that want to handle large models are going to have to cope with huge numbers of connectors anyway, by careful caching and data structures that can be rapidly searched. In that context, more connectors (in a spatially localized way) is probably fine.

Similarly, the connection types could be potentially specified strictly as data from a smaller number of connection classes. E.g. a stud-antistud or friction pin + friction pin hole can all be of the category of 0-degree-of-freedom point connectors. We have 924 primitives (apparently based on a quick dir listing) in the library, so coping with a large, carefully managed data set is something the community is already doing.

cheers
Ben