The present LDraw library is divided into primitives, subparts, and parts. Each part can be assigned to a category and have zero or more keywords to aid searching. However, there is not yet any coherent structure for organizing similar parts.
Patterned versions of parts are primarily identified by a part number extension, while distinct underside reinforcements may be indicated with a letter (a, b, c...), a different part number, or some other extension to the part number. How would a prospective digital builder known which version to use without getting lost in the jungle of similar parts?
I propose using an ontology where the different versions of a brick are organized in a hierarchical manner. It could for example be possible to define a 'generic' brick and all its known variants of underside reinforcements in a consistent manner. This ontology could then be used to filter the library to produce different official subsets of the library for different stakeholders.
Reusing dat files is an efficient way of constructing complex structures out of modular subunits while maintaining editability on all levels without redundancy. However, each additional subpart requires its own review and approval on the parts tracker before becoming eligible for inclusion into the library. The low number of part reviewers effectively limit the realistic number of subunits of a part, thus hindering adequate reuse of subunits in different bricks. Consequentially, subunits tend to be large and highly specialized, thus of little use in other parts. Additionally, I would prefer having access to box primitives where the origin is at the end of the box rather than the middle and understud primitives with the origin at the bottom end of the primitive rather than the top to simplify scaling and placement.
The above can be achieved in at least two approaches; 1. allowing subparts within a file and 2. by expanding the 'primitives' library with structures that are repeatedly constructed in part after part. Examples of the latter include boxjcyl, a halfway truncated stud8, and all-edge versions of some boxes.
Solution 1 would enable more consistent parts as modular intermediates can be constructed in a "for this part only" manner. Solution 2 would enable more broader reuse of modular subparts. Neither excluding the other.
I would also prefer more standardized naming of parts, consistent part orientation, regularized primitive sizes, and circular segments other than those starting from a 0 or 90 degree angle.
Patterned versions of parts are primarily identified by a part number extension, while distinct underside reinforcements may be indicated with a letter (a, b, c...), a different part number, or some other extension to the part number. How would a prospective digital builder known which version to use without getting lost in the jungle of similar parts?
I propose using an ontology where the different versions of a brick are organized in a hierarchical manner. It could for example be possible to define a 'generic' brick and all its known variants of underside reinforcements in a consistent manner. This ontology could then be used to filter the library to produce different official subsets of the library for different stakeholders.
Reusing dat files is an efficient way of constructing complex structures out of modular subunits while maintaining editability on all levels without redundancy. However, each additional subpart requires its own review and approval on the parts tracker before becoming eligible for inclusion into the library. The low number of part reviewers effectively limit the realistic number of subunits of a part, thus hindering adequate reuse of subunits in different bricks. Consequentially, subunits tend to be large and highly specialized, thus of little use in other parts. Additionally, I would prefer having access to box primitives where the origin is at the end of the box rather than the middle and understud primitives with the origin at the bottom end of the primitive rather than the top to simplify scaling and placement.
The above can be achieved in at least two approaches; 1. allowing subparts within a file and 2. by expanding the 'primitives' library with structures that are repeatedly constructed in part after part. Examples of the latter include boxjcyl, a halfway truncated stud8, and all-edge versions of some boxes.
Solution 1 would enable more consistent parts as modular intermediates can be constructed in a "for this part only" manner. Solution 2 would enable more broader reuse of modular subparts. Neither excluding the other.
I would also prefer more standardized naming of parts, consistent part orientation, regularized primitive sizes, and circular segments other than those starting from a 0 or 90 degree angle.
