3D Printroom

A small distraction I thought up a few days ago involves how we organise our STL and gcode files.  The Windows and Linux file explorers are rather limited when dealing with exotic files (no previews, no metadata). Additionally, I don’t know how other people manage their files, but mine are scattered across my main PC, my laptop and a NAS, within arbitrarily named folders filled with overly long file names (in an attempt to capture some metadata). It certainly has it’s limitations!

file chaos

Chaos! Chaos I tell you!

This seems ripe for an application of some sort (ignoring the patently absurd, if rational, argument to simply impose a little order on things).

I have always enjoyed using Adobe Lightroom to organise and work on my photos – it has several features that could be very useful when dealing with 3D printer files:

  • Directory scanning & sync
  • Arbitrary collections and groups
  • Adding additional metadata, including comments and ratings
  • Previews of non-standard files (e.g. RAW)
Adobe Lightroom

Adobe Lightroom – something to aspire to.

I wish I could announce that I have completely written a “Lightroom for 3D Printers” but at this stage I have only created a skeleton app with limited functionality:

  • Drop a directory in the top left panel to load it.
  • The top file view filters only STL files.
  • When an STL is selected the related gcode files are displayed below. This assumes the files start with the same name, e.g. cube.stl -> cube.gcode.
  • Any metadata in the gcode file is displayed in a table view (Slic3r only).
  • Double clicking a STL file displays a preview (thanks to Tony Buser’s Thingiview).
  • Double clicking a gcode file displays a preview (thanks to Joe Walnes’ gcode-viewer).

3D Printroom (Alpha!)

… and that’s it … so far.

The reason I am posting about this already is to share the idea, gauge interest, and to make the source code available in case anyone wants to pick it up and hack with it.

I chose to develop it with node-webkit, which allows you to develop with HTML + JS + CSS but still release a native binary. (This is necessary in order to use node.js so the local filesystem can be accessed). I’ve added a few notes on the github project on how to hack with it.  Or there is a Windows binary available to play with: 3D-Printroom-distribution.zip.

I’d be interested to hear if anyone thinks such an app would be useful.




  • February 17, 2013 - 11:30 pm | Permalink

    This is definitely the sort of thing that anyone who has 3D printed for a while eventually needs… I keep my stuff sorted into a folder structure in Dropbox so that I always have access to everything.

    I use a 3D printing folder under my main Projects dir for my own creations and remixes, but for stuff I’ve just downloaded it goes into categories inside a separate 3D models folder (like next to Music and Photos).

    Categorizing stuff gets a bit weird. Some of the top-level categories in my model folder include: “Colbert”, “Facial hair”, “Household”, etc.

    I think that I’d also want to keep track of the original source URL for the object.

  • dzach
    February 20, 2013 - 1:52 pm | Permalink

    Bringing order to the chaos of ideas, designs and creations requires a lot of effort. Successful attempts, like Thingiverse, show that at the center of their success is a good visual of the object.

    Your own Development Tracker is a good example of an application that collects scattered information and metadata; I find it very useful. However it concentrates on textual descriptions and (mostly) lacks visuals.

    Sad as it can be for the Semantic Web, it looks like Google’s way, i.e. unstructured combinations of atomic meaning, such as it is carried by a picture, is better suited for the current technology, i.e. keyboard, mouse and screen, than is a well defined structure of metadata. What could possibly change it, is another kind of interface which would make it easier for humans to communicate with the machines. Seeing is easy (thus visuals) but reading (thus reasoning) requires effort.

    Voice might be the HM interface that could make a big difference. Doesn’t require visual attention, can work in parallel with other activities and it is structured itself. Because voiced nonsense is very annoying, one would expect that incoherent atomic meaning would be a failure for a voice HMI. In the case of a voice HMI, structured metadata would give the machine ways for reasoning and would provide humans with coherent answers.

    I follow your efforts to bring order to this chaos, and the same thing comes up over and over: the iconic world needs just icons. It’s the world of reasoning that needs structure. But reasoning is locked out by the current technologies we use, unless we are determined to make the effort. And make it continuously.

    • February 20, 2013 - 3:17 pm | Permalink

      You make good points. I would say though that voice as an interface mechanism brings a whole set of new challenges that would have to be dealt with before it brings real benefits. As is the case with video, there is little way to “skim” the content to evaluate whether it should be looked at in more detail, for example.

      I think some form of graphical visualisation may be the most promising route, but providing a coherent and useful visualisation is extremely challenging, as you mention.

      It’s certainly an interesting problem to attempt to solve!

  • jt
    April 23, 2013 - 3:41 pm | Permalink

    awesome idea.

  • June 6, 2013 - 12:28 am | Permalink

    This has one goal similar to githubiverse and thingscript; it tries to represent files.

    Personally have thought of trying to make thingscript make a server that functions a bit as a file browser, so you can browse projects you downloaded(/git cloned, gotten from a floppy whatever) offline. I suppose then being able to use it as a file-browser -in which it makes sense of files it knows- would make sense too.

    This looks similar to that. If the stars align maybe this or something like this can be developped, developping the representation for web serving at the same time as the application. What i see about node-webkit so far bodes well.

    Thingscript(well the default way of using it) aims at a gallery similar to thingiverse as the central thing. So it looks for thingscript/gallery_list for the list with an order of files to generate parts of the gallery from.(it also has thingscript/thumbnail, and defaults for stuff, in that case the first element of the gallery list)

    Not that the thingscript approach is completely right. For one i think filesystems arent aimed at many tiny files neither storage efficiency or more importantly, lookup speed. But it’d have to have some kinds of standards about where to put stuff.

    Additionally thingscript has customization is best done via some hierarchy(though now i realize it doesnt quite work the way it should), for instance if the project maker likes some awful pink scheme, maybe the user could override it. Similarly, the gallery is just the default.. But it is also kind of a convention, the project maker might not follow that convention, but the user doesnt want to bother with that silly guys whims, then whatever data around may still be usable to cook up a more conventional page.(for instance gallery_list could be automatically made, not as good as hand-crafted but whatever)

    That said maybe this post is quite a bit premature 🙂 maybe i should have looked at 3d printroom a lot more before typing 🙂

  • Comments are closed.