Hi Roland,
Indeed, how the represent the parts needed to construct a 'composite part' is the subject of my question.
- Some part assemblies have dynamic content when modeled, like a complete PF motor with it's cable and electric connector. Nevertheless, for at least rendering instructions, a complete PF motor should be treated as a single part assembly - much like most static content parts in the library.
- LDCad's template framework allows static (motor body, electrical connector) and dynamic (electrical cable) components of a part (PF motor) to be defined as a single part assembly which is powerful for instruction generation, as processing functionality like part count and generating BOMs can be much more efficient and accurate.
- What I am asking is for the ability to 'create' composite part assemblies using a the template framework and have the content be generated with the same attributes and naming convention as a conventional [unofficial] part.
- The file extension being of no consequence to LDCad is a plus to enable this capability because, I imagine, one would simply present the user option of deciding if s/he wanted to save their template composite part as a model (ldr) or a part (dat).
- Of course, it is clear that the best indicator of a component's type is it's LDRAW_ORG attribute which is key to processing these items but as LDraw.org places a priority (and implemented standards) on maintaining a human-readable file format, I believe remaining consistent between .dat, .ldr, .mpd content is also worthwhile.
For me, a complete PF motor is a part that should be defined as all other parts in the library which is to say with the .dat extension. I don't speak about the shortcut representation which is useless in any real modeling exercise other than representing the part in the BOM/PLI.
Hopefully, this detailed expression helps to make a bit more clear the purpose and application of my question. But in fact, the point of my question is about enhancing interoperability and standardization between applications that respect the LDraw format.
Cheers,
Indeed, how the represent the parts needed to construct a 'composite part' is the subject of my question.
- Some part assemblies have dynamic content when modeled, like a complete PF motor with it's cable and electric connector. Nevertheless, for at least rendering instructions, a complete PF motor should be treated as a single part assembly - much like most static content parts in the library.
- LDCad's template framework allows static (motor body, electrical connector) and dynamic (electrical cable) components of a part (PF motor) to be defined as a single part assembly which is powerful for instruction generation, as processing functionality like part count and generating BOMs can be much more efficient and accurate.
- What I am asking is for the ability to 'create' composite part assemblies using a the template framework and have the content be generated with the same attributes and naming convention as a conventional [unofficial] part.
- The file extension being of no consequence to LDCad is a plus to enable this capability because, I imagine, one would simply present the user option of deciding if s/he wanted to save their template composite part as a model (ldr) or a part (dat).
- Of course, it is clear that the best indicator of a component's type is it's LDRAW_ORG attribute which is key to processing these items but as LDraw.org places a priority (and implemented standards) on maintaining a human-readable file format, I believe remaining consistent between .dat, .ldr, .mpd content is also worthwhile.
For me, a complete PF motor is a part that should be defined as all other parts in the library which is to say with the .dat extension. I don't speak about the shortcut representation which is useless in any real modeling exercise other than representing the part in the BOM/PLI.
Hopefully, this detailed expression helps to make a bit more clear the purpose and application of my question. But in fact, the point of my question is about enhancing interoperability and standardization between applications that respect the LDraw format.
Cheers,