I’ve been trying to come up with a way to handle storing and version controlling my 3D models (both from thingiverse, and models I create myself), however i ran into quite a few deadends when looking for software built for this purpose (PLM/PDM), so I’ve figured it would easiest to build a folder structure with some metadata alongside it to go on top of GIT, and allow GIT to deal with version control. While STL files are text, a majority of my models are in proprietary binary formats, but GIT can still at least store the files and provide a history. I figure the repository would have 3 primary folders, parts, products, 3rd party (more or less unstructured). Each part/product would also have an export folder which will store a copy of STLs, and metadata to go with for a specific published version of a model (might be duplicate data, maybe use some type of tag in GIT to represent each officially published version).
- Parts: not very useful as a single component, but used to create products, or as spare components to some item
- Products: a grouping of parts to encompass a single object, or a single piece that makes up the object (think one piece phone stand, vs a multi-piece assembly). While these may seem separate in their usage, they will be the final product of whatever is created.
- 3rd party: these may or may not follow the data policies, things like the ultimaker 2 models/plans and the backblaze storage pod models which are neat to have, but we won’t be applying our policies to those large assemblies. These can also include the innumerable thingiverse models we all acquire, eventually the goal will be to incorporate all thingiverse metadata into the dataset as well to provide details locally for all models herin.
- Exports: Each part or product can have versioned exports as well, these will be one specific version of the STL, assembly, and tags, allowing a product to reference the version of the export until both are updated to support newer versions or varients.
I have an example structure below.
PDM_Manager
|--Scripts
|--Management Script
Modeling
|
|--Products
| |--Assembly 1
| | |--3D models
| | |--Assembly.md
| | |--Meta.txt
| | |--Exports
| | |--V1
| | |--V2
| |--Assembly 2
| |--OnePieceProduct
|
|--Parts
| |--Component 1
| | |--Model
| | |--ReadMe.md
| | |--Meta.txt
| | |--Exports
| | | |--V1
| | | |--V2
|
|--3rd Party
| |--Large project download
| |--Large project download
Meta.txt
When a model is pulled to be modified for another purpose, the child model path will be added to the children tag. When the child model is created, the parent tag for that model will be updated.
TAGS: 3d print, laser cut, wood, plastic, peg board, wall hanging, storage RELATED: repo/relative/path/to/folder1, repo/relative/path/to/folder2 PARENT: repo/relative/path/to/original/model ASSEMBLES: path/to/part/1/Export/v1, path/to/part/2/Export/v2 CHILDREN: repo/relative/path/to/models/based/on/this, repo/path/to/another
Assembly.md
- more or less freeform markdown for instructions on printing, laser cutting, assembly, anything else that might be needed
- Maybe more files should be put together for information on the parts, but i think having one will cover it for now
The Management Script
Wrapper script around git commands and ensuring data is structured in a specific way, figure this will make it easier to handle the data.
- init: initialize a new modeling repo
- remix: create a child model of the input model
- tag: add, remove, update tags on a model
- create: creates a new model
- assemble: links a product to other parts
- get-thing: quickly grab thingiverse models and metadata (mostly convinience for myself.)
- publish version: some way to create a version directory, add in the associated metadata and md files, and any stl files for that version
I’m hoping this will cover my use case, though i’m worried it’ll make it harder to find my projects vs downloads from thingiverse/internet that don’t have source models to work from. I’ve also considered using the 3rd party folder for all those external downloads (maybe finding a better name for it). The meta.txt file i include with each part will also hopefully be good at providing searchable details to hopefully make finding specific models easier.