Hi Ben.
This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.
- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.
I don't say that LDraw library is wrong, absolutely NO. But, until now, it was used as a geometric shape definition library, with defined primitives used as shape shortcut, sometime regardless the primitive meaning and defined purposes.
So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.
This is why I take so long to add new parts in connection library: I must check every single part connection in connection editor before add to list of "correctly autodetected" or add a ".cxml" file to library.
Mario
Ben Wrote:1. Annotation of existing primitives with connectivity, e.g. if you use stud.dat, you get a male stud connector 'for free'.
This is not always true, and I need a "visual check" for every part I add in connectivity library. At the moment, I found some parts designed using primitives as mere geometric shortcut, but ignoring the semantic meaning. Some examples:
- parts 59426.dat and 32209.dat (axle 5.5 with stop): parts are axles, but uses axlehol8.dat as primitive for axle. If you use "axlehol8.dat" (defined as "Axle hole perimeter") to detect a "female" connection for axle these two parts will becomes axle holes 5.5 unit long for connection logic.
- part 4727.dat uses a "peghole.dat" as a base. I don't know, but should be better use a stud4.dat, I think. If you use this part with autodetect, a "peghole" connection is placed in a totally wrong position
- part 3680.dat: an inverted peghole.dat to obtain central hub.
- 32556.dat: an inverted peghole.dat to obtain the flange.
just to say some.
I don't say that LDraw library is wrong, absolutely NO. But, until now, it was used as a geometric shape definition library, with defined primitives used as shape shortcut, sometime regardless the primitive meaning and defined purposes.
So, including connectivity to primitives is surely a good starting point, but at the present state of library it can lead to unwanted/weird connectivity issues: you need to delete some connections derived by primitives in final part. This is a major issue in autodetect strategy. In my connection library some parts are inserted only to avoid autodetection, that includes unwanted and wrong connection points.
This is why I take so long to add new parts in connection library: I must check every single part connection in connection editor before add to list of "correctly autodetected" or add a ".cxml" file to library.
Mario