Thanks Travis, for another viewpoint.
I do agree that it is essential that the end-caps are part of the library. Currently we provide the mid-sections as 3D components, probably because the first to be modelled had some repeating structure (ribbed hoses, treads). In these cases, the generation of a flexed version is not a pure extrusion action and some deformation (or overlap) of the repeating sections is needed.
For the smooth flexible parts (pneumatic tubes, flex tubes, flex cables, fibre-optic cables, electric cables, string?) the flexed version really is a 3D extrusion of a 2D object. If we provided that 2D object as an LDraw file it would avoid the need for a tool to infer that information from the end caps, or hard code it internally. In reality for circular parts that would just be a 4-4edge definition, but by making it part of the library it allows us to tweak the dimensions of the end-caps AND the extrudable section in synchrony, if we make a dimensional mistake or need greater precision in the future. The tool would only need to store (probably in a tool.ini file) the filenames of the end-caps and their matching 2D extrudable part, although I would also favour that being part of the LDraw deliverables (in the way that the minifig generator metadata in MLCad.ini probably should be).
Chains are a special case, and probably deserve a different solution because they are not really flexible but a combination of rigid parts following a path.
I do agree that it is essential that the end-caps are part of the library. Currently we provide the mid-sections as 3D components, probably because the first to be modelled had some repeating structure (ribbed hoses, treads). In these cases, the generation of a flexed version is not a pure extrusion action and some deformation (or overlap) of the repeating sections is needed.
For the smooth flexible parts (pneumatic tubes, flex tubes, flex cables, fibre-optic cables, electric cables, string?) the flexed version really is a 3D extrusion of a 2D object. If we provided that 2D object as an LDraw file it would avoid the need for a tool to infer that information from the end caps, or hard code it internally. In reality for circular parts that would just be a 4-4edge definition, but by making it part of the library it allows us to tweak the dimensions of the end-caps AND the extrudable section in synchrony, if we make a dimensional mistake or need greater precision in the future. The tool would only need to store (probably in a tool.ini file) the filenames of the end-caps and their matching 2D extrudable part, although I would also favour that being part of the LDraw deliverables (in the way that the minifig generator metadata in MLCad.ini probably should be).
Chains are a special case, and probably deserve a different solution because they are not really flexible but a combination of rigid parts following a path.
Chris (LDraw Parts Library Admin)