Do we need another LDraw building program?

[Mario Pascucci]

Hi Ben.

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)

Actually, I use an hybrid method:
- a Technic pinhole has two connection point (one per side) of type "PEGHOLE". This connector is directly coupled with a connector type "PIN" (there is a function called "opposite()" that gives the coupled connection type), but in program logic it accepts "STUD" and "AXLE" type connection if no direct coupling is available.
- Other connection with special handling are: AXLE (can connect with AXLEHOLE and PEGHOLE); STUD (can connect to R_STUD, a tube, or PEGHOLE); BAR (can connect with CLIP or AXLEHOLE). Of course, vice-versa is provided: PEGHOLE in STUD, AXLEHOLE in BAR and PEGHOLE in AXLE.

The win here, I think, is that the _constraints_ of these different uses of the technic hole are different.

In my analysis, DOF descends from family of connection: Vector, Rail or Point.
- Vector: 1 DOF, rotation on vector axis (stud can be connected to a pinhole in any angle around pinhole axis).
- Rail: 2 DOF, rotation on rail axis, translating along rail.
- Point: 2 (3?) DOF, rotating around x,y,z axis
Pinhole is type Rail for axle coupling and type Vector for pin and stud coupling.

Constraints rules are partially leaved to the user: not having collision volumes it is really hard to detect wrong connections.
I think LDD uses more and more sophisticated model. But I must take account of Java speed limits, and accept less complex models and methods.

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.

In this phase I focused on create and test a logic that "works". No optimization is done for connection search, except store connections by type, so if you have a CLIP you have only to search on BAR type array.
I'm thinking on two optimization: spatial sorting (connection point ordered by X, Y and Z) and remove used (coupled) connection, but no code yet.
Some connection is lot more used than other:
- stud and stud receiver in bricks, plates and baseplate
- pinhole, axleholes, axle and pins in Technic models
so can be useful to heavily optimize only some connection types.

Anyway, if you want to take a look to source:
- in file "ConnectionType.java" in package it.romabrick.ldrawlib there is connection type listing
- in file "ConnectionPoint.java" in package it.romabrick.ldrawlib there is connection autodetecting from primitives
- in file "ConnectionHandler.java" in package it.romabrick.ldraw3d there is connection search and coupling logic

In few days I think I can release new version and the (really ugly but "it works™") connection editor.
At present I have
- 290 part connections files (not autodetected parts)
- 155 parts correctly autodetected (checked)



Ciao!
Mario