But what about the extra parts that come in the box but aren't part of the model?
Would the MPD not be an actual model of the set but just a collection of the correct type/color/count of the parts that come in the box, not organized into a proper model?
How do you want parts of the same type but different color represented?
Would
be what you're looking for?
For example, for this MPD:
Would you be looking for something like this?
Would you prefer the output in JSON because it could represent a hierarchy of the submodels within the parts as well?
If I remember correctly, LDView's code for generating the HTML parts list didn't rely too heavily on previous processing of the model, so I think most of the work is pretty much done already. (At least for CSV or any other flat format.)
Would the MPD not be an actual model of the set but just a collection of the correct type/color/count of the parts that come in the box, not organized into a proper model?
How do you want parts of the same type but different color represented?
Would
Code:
"part number", color_code, number_of_parts
"same part number", different_color_code, number_of_parts_of_the_other_color
"different part number", color_code, number_of_partsFor example, for this MPD:
Code:
0 FILE some-model
1 1 10 -32 10 1 0 0 0 1 0 -0 0 1 3024.dat
1 1 0 0 0 1 0 0 0 1 0 -0 0 1 some-submodel
0 NOFILE
0 FILE some-submodel
1 4 0 0 0 1 0 0 0 1 0 -0 0 1 3001.dat
1 2 -10 -24 0 1 0 0 0 1 0 -0 0 1 3002.dat
0 NOFILEWould you be looking for something like this?
Code:
"3001", 4, 5
"3001", 1, 2
"3024", 2, 1Would you prefer the output in JSON because it could represent a hierarchy of the submodels within the parts as well?
If I remember correctly, LDView's code for generating the HTML parts list didn't rely too heavily on previous processing of the model, so I think most of the work is pretty much done already. (At least for CSV or any other flat format.)