[GH-ISSUE #209] [Feature]: Support other file formats besides 3MF

BreizhHardware commented

2026-05-06 12:26:08 +02:00

Owner

Originally created by @jhf2442 on GitHub (Jan 31, 2026).
Original GitHub issue: https://github.com/maziggy/bambuddy/issues/209

Problem or Use Case

I can only upload 3MF files - even when putting the file dialog to "all files"

Proposed Solution

Support STL, GCODE, openscad, freecad ... files

Use case is not to print them directly but rather to have a centralized place where to put all files. Currently using nextcloud which is only a file manager, no tagging, no addtl 3D printing-related options like bambuddy is offering.

Alternatives Considered

No response

Feature Category

Print Archiving

Priority

Nice to have

Mockups or Examples

No response

Contribution

I would be willing to help implement this feature

Checklist

I have searched existing issues to ensure this feature hasn't already been requested

Originally created by @jhf2442 on GitHub (Jan 31, 2026). Original GitHub issue: https://github.com/maziggy/bambuddy/issues/209 ### Problem or Use Case I can only upload 3MF files - even when putting the file dialog to "all files" ### Proposed Solution Support STL, GCODE, openscad, freecad ... files Use case is not to print them directly but rather to have a centralized place where to put all files. Currently using nextcloud which is only a file manager, no tagging, no addtl 3D printing-related options like bambuddy is offering. ### Alternatives Considered _No response_ ### Feature Category Print Archiving ### Priority Nice to have ### Mockups or Examples _No response_ ### Contribution - [ ] I would be willing to help implement this feature ### Checklist - [x] I have searched existing issues to ensure this feature hasn't already been requested

BreizhHardware

2026-05-06 12:26:08 +02:00

closed this issue
added the
wontfix
label

BreizhHardware commented

2026-05-06 12:26:08 +02:00

Author

Owner

@maziggy commented on GitHub (Jan 31, 2026):

This is why we added the file manager!?

@maziggy commented on GitHub (Jan 31, 2026): This is why we added the file manager!?

BreizhHardware commented

2026-05-06 12:26:08 +02:00

Author

Owner

@jhf2442 commented on GitHub (Feb 1, 2026):

not really

What I'd like to have is that I can put into e.g.$bambuddy_data/archive/unassigned/20260128_232819_AMDI as well the 3MF as the STL as the freecad file, maybe a PDF etc - all files related to a single model stored at same location. BTW: when will it become "assigned" ? (assiging to a printer and to a project didn't move the file elsewhere)

This is a feature that e.g. manyfold has - but I'm not using this software for several other reasons

I can use the file manager to upload files (even create folders to arganize them), but they end up being stored as $bambuddy_data/archive/library/files/868277a4ac174ae2a0f8556da7ad111d.stl - independently of folder, original file name and there's no way to associate them to a 3MF, a project nor tag them. Further playing around I found the option to lik a folder to a project or an archive - seems a complicated way to achieve what I want to do -> what's the use case you designed this for ?

Also: Why rename the files to UUIDs when the 3MF files keep their original names ? and why have the folders virtual only ?

@jhf2442 commented on GitHub (Feb 1, 2026): not really What I'd like to have is that I can put into e.g.$bambuddy_data/archive/unassigned/20260128_232819_AMDI as well the 3MF as the STL as the freecad file, maybe a PDF etc - all files related to a single model stored at same location. BTW: when will it become "assigned" ? (assiging to a printer and to a project didn't move the file elsewhere) This is a feature that e.g. manyfold has - but I'm not using this software for several other reasons I can use the file manager to upload files (even create folders to arganize them), but they end up being stored as $bambuddy_data/archive/library/files/868277a4ac174ae2a0f8556da7ad111d.stl - independently of folder, original file name and there's no way to associate them to a 3MF, a project nor tag them. Further playing around I found the option to lik a folder to a project or an archive - seems a complicated way to achieve what I want to do -> what's the use case you designed this for ? Also: Why rename the files to UUIDs when the 3MF files keep their original names ? and why have the folders virtual only ?

BreizhHardware commented

2026-05-06 12:26:08 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 1, 2026):

Please first check out the existing features and read the docs on Wiki!

For example:

"Further playing around I found the option to link a folder to a project "

That is alaready there!

@maziggy commented on GitHub (Feb 1, 2026): Please first check out the existing features and read the docs on Wiki! For example: "Further playing around I found the option to link a folder to a project " That is alaready there!

BreizhHardware commented

2026-05-06 12:26:09 +02:00

Author

Owner

@jhf2442 commented on GitHub (Feb 8, 2026):

Sorry, was on a business trip, could post earlier.

As stated, you seem to focus on the manufacturing part of the flow. Meaning: storing 3MF/G-code and pushing to the printers. 3MF originating from e.g. Makerworld. When making modifications to the 3MF in the slicer, I don't see a path back into bambuddy, besides storing the file locally, and uploading it again. Name "archive" says it all - it's not a working space. Comparison would be e.g. plesk for managing collections of videos: focus is on having an overview of the collection, finding and viewing the video files. No video editing or the like

I'm looking for a toolsuite that's more holistic, covering custom designed parts as well as downloaded items. So far I've been using nextcloud to store all files (3MF, STL, freecad...), and a markdown file per folder to associate them with the originating URL, a screenshot etc. Quite cumbersome, but at least I can share my files online, while working on my models -> online access through a web interface while keeping the possibility to acces them through filesystem to easily edit them. Comparison with videos: having in plesk option to add my own videos, that I can still cut and rework out of the same source.

Benefit I see with your solution is the tagging (sorting into folders has come to it's limits, sorting into subfolders and finding the files 6 months later doesn't work), the automated extraction of information (e.g. URL of makerworld), preview etc.

As you indicated, I could add e.g. my freecad files using the file manager, creating a new folder per model, and linking the folder to the final 3MF. Tested, works basically.

Problems I see with the current implementation:

files are stored in separate locations - 3MF in archive/unassigned and other files in archive/library/files -> the distinct location only makes sense when a folder is not linked to a model, else the files could as well be stored together with the model (in a subdirectory if you really want to have some kind of separation)
uploaded files are stored using a UUID as their filename, without folder information - mapping to "real" filename is done througth DB. Means it's impossible to find the files directly through file system in an easy way. What is the benefit of hashing the filenames and storing them flat? In comparison to the archive structure where the filenames are preserved and 3MF/thumbnails stored in directories.
what is the point of having to explicitly link a folder with additional files to an archive, when files could simply be added to the archive's directory ? I'm aware that manipulating files directly in the filesystem may interfere with the state stored in the DB - Nextcloud solves this through a rescan feature that can be triggered. Opencloud skips usage of DB.

My solution ("attached files") proposal would be:

ability to store additional files directly in the archive's directory (or subdirectory if you prefer)
keep original file names, not UUID, to enable interaction through filesystem
additional icon (e.g. red folder icon) on each archive card to open a file manager showing these files

file manager code is not 100% suited as it uses the DB to do filename mapping etc, so has to be rewritten/duplicated. Yet, most of the functionality would be reusable (e.g. thumbnail / preview generation for STL)
maintenance mode to re-sync filesystem state and DB, updating thumbnails etc

Had a look at the code, I think it can be extended using some minor frontend modifications and api calls, and a new backend handler for attached files. I'm not a web developper (my experience with the frameworks you use is very limited), so I won't be able to provide full PR by myself, but I may ask for some help in our local fablab. Overall question is if you'd be willing to acces such a massive change ? If not, would not make sense to spend the effort implementing.

Thanks for taking time to read this long post !

@jhf2442 commented on GitHub (Feb 8, 2026): Sorry, was on a business trip, could post earlier. As stated, you seem to focus on the manufacturing part of the flow. Meaning: storing 3MF/G-code and pushing to the printers. 3MF originating from e.g. Makerworld. When making modifications to the 3MF in the slicer, I don't see a path back into bambuddy, besides storing the file locally, and uploading it again. Name "archive" says it all - it's not a working space. Comparison would be e.g. plesk for managing collections of videos: focus is on having an overview of the collection, finding and viewing the video files. No video editing or the like I'm looking for a toolsuite that's more holistic, covering custom designed parts as well as downloaded items. So far I've been using nextcloud to store all files (3MF, STL, freecad...), and a markdown file per folder to associate them with the originating URL, a screenshot etc. Quite cumbersome, but at least I can share my files online, while working on my models -> online access through a web interface while keeping the possibility to acces them through filesystem to easily edit them. Comparison with videos: having in plesk option to add my own videos, that I can still cut and rework out of the same source. Benefit I see with your solution is the tagging (sorting into folders has come to it's limits, sorting into subfolders and finding the files 6 months later doesn't work), the automated extraction of information (e.g. URL of makerworld), preview etc. As you indicated, I could add e.g. my freecad files using the file manager, creating a new folder per model, and linking the folder to the final 3MF. Tested, works basically. Problems I see with the current implementation: * files are stored in separate locations - 3MF in archive/unassigned and other files in archive/library/files -> the distinct location only makes sense when a folder is *not* linked to a model, else the files could as well be stored together with the model (in a subdirectory if you really want to have some kind of separation) * uploaded files are stored using a UUID as their filename, without folder information - mapping to "real" filename is done througth DB. Means it's impossible to find the files directly through file system in an easy way. What is the benefit of hashing the filenames and storing them flat? In comparison to the archive structure where the filenames are preserved and 3MF/thumbnails stored in directories. * what is the point of having to explicitly link a folder with additional files to an archive, when files could simply be added to the archive's directory ? I'm aware that manipulating files directly in the filesystem may interfere with the state stored in the DB - Nextcloud solves this through a rescan feature that can be triggered. Opencloud skips usage of DB. My solution ("attached files") proposal would be: * ability to store additional files directly in the archive's directory (or subdirectory if you prefer) * keep original file names, not UUID, to enable interaction through filesystem * additional icon (e.g. red folder icon) on each archive card to open a file manager showing these files <img width="477" height="302" alt="Image" src="https://github.com/user-attachments/assets/bd54114b-6651-49b5-a3a3-55b76ee773fc" /> * file manager code is not 100% suited as it uses the DB to do filename mapping etc, so has to be rewritten/duplicated. Yet, most of the functionality would be reusable (e.g. thumbnail / preview generation for STL) * maintenance mode to re-sync filesystem state and DB, updating thumbnails etc Had a look at the code, I think it can be extended using some minor frontend modifications and api calls, and a new backend handler for attached files. I'm not a web developper (my experience with the frameworks you use is very limited), so I won't be able to provide full PR by myself, but I may ask for some help in our local fablab. Overall question is if you'd be willing to acces such a massive change ? If not, would not make sense to spend the effort implementing. Thanks for taking time to read this long post !

BreizhHardware commented

2026-05-06 12:26:09 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 8, 2026):

To be honest: Bambuddy is already a full time job. I don't have the time for such extensions. Sorry.

@maziggy commented on GitHub (Feb 8, 2026): To be honest: Bambuddy is already a full time job. I don't have the time for such extensions. Sorry.

BreizhHardware commented

2026-05-06 12:26:09 +02:00

Author

Owner

@jhf2442 commented on GitHub (Feb 8, 2026):

Fair enough, but would you be willing to accept a PR if I provide it ?

@jhf2442 commented on GitHub (Feb 8, 2026): Fair enough, but would you be willing to accept a PR if I provide it ?

BreizhHardware commented

2026-05-06 12:26:09 +02:00

Author

Owner

@maziggy commented on GitHub (Feb 8, 2026):

Sure!

If you find Bambuddy useful, please consider giving it a ⭐ on GitHub — it helps others discover the project!

@maziggy commented on GitHub (Feb 8, 2026): Sure! ----- If you find Bambuddy useful, please consider giving it a ⭐ on [GitHub](https://github.com/bambuman/bambuddy) — it helps others discover the project!

BreizhHardware referenced this issue

2026-05-06 12:34:03 +02:00

[PR #128] [MERGED] Fixed re-auth setup and gitignore node modules #935