Mario Pascucci Wrote: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.
Right - this is a risk with "primitive"-based connectivity - when a primitive's semantic meaning is abused for its geometric shape, we introduce a connectivity problem.
I agree with Orion: in my opinion the best long term option for the library is:
- Primitives have "semantic" meaning. Use stud.dat when you mean a lego stud, not just when you have a cylinder.
- Parts that have wrong connectivity due to "abuse" of primitives should be fixed by changing which primitive is used.
This is a fundamental change to the library, so the community (or LSC or SteerCo or??) would have to agree to this change in library policy as part of an implementation plan. It's not a trivial change.
But my view is that in the long term it's better to fix "abused" primitives than to have to build all connectivity data separately and check it. The power of LDraw is in the leverage the primitive system gives us*; I think the alternative is a much slower, longer process for building connectivity meta-data.
cheers
Ben
* If we are not going to leverage having primitives, we might as well just create each part out of a triangle soup and model them in a 3-d modeler. :-): -)