CageMaker PRCG: parametric rack cages you can print at home

What the project is

The project makes a rack-mount cage for small devices, in the sense of a printed enclosure with rack ears that slides into a standard rack and holds a device in front of it, together with the faceplate options that go with it: ventilation cutouts, mounting points for various connectors, and openings for cooling fans.

The description in the repository is broader than that, and the extra clauses are the interesting part: it can rack mount almost any small device into almost any rack, it can create custom faceplates with ventilation or mounting points for various connectors and cooling fans, and it can create custom rack mount enclosures for projects.

The way it does this is by being a parametric model. The subject is the scripting language for solid modelling, and the whole thing is one file of parameters and one directory of included geometry. Change a parameter and the model rebuilds. There is no drawing to measure, no file to import, and no possibility of the model and the specification disagreeing, because the specification is the model.

That is the right tool for this problem. A rack cage is a box with a set of holes in it, and the holes depend on the device being racked, the rack being targeted, the printer, and the panel sizes. A parameter for each of those is a small number of fields, and a parameter for each of those is exactly what a customiser panel gives you.

The licence is worth reading carefully, because it is unusual for a hardware design. The file is under a Creative Commons licence with attribution, non-commercial and share-alike terms, and the copyright is held by a company rather than an individual. For a physical design, that is a meaningful choice: the design is published for people to print for themselves and to share, and the share-alike clause keeps any derived design in the same terms, which is what stops somebody commercialising a derivative while the original stays free. The non-commercial clause is the one that would rule out selling printed cages made from this model.

And there is one more line in the readme that is unusual enough to quote, because it is a policy rather than a fact about the code. The project states that it is human-produced, that no artificial intelligence assistance or vibe coding was used in its development. For a project whose output is a design that people print, that is a claim about the provenance of the geometry, and it is a deliberate one.

The workflow, and the customiser panel

The usage instructions are six steps, and the first one is the download or the clone.

git clone https://github.com/WebMaka/CageMakerPRCG.git

Then you open the model file in the modelling application, and the readme predicts what you will see: an extreme close-up of a default rack cage design in the preview window. And then it tells you the shortcut to fix it, which is to zoom out to the show-all distance.

That prediction and that fix are good writing, and they are also a warning about the model. The default settings produce a design whose visible portion in the preview is a wall of surface, and the first thing a new user has to do is change the scale of the view. Which makes sense for a model whose default dimensions are the standard ones and whose camera is placed at a default distance rather than at a useful one.

The third step is the one that matters: use the customiser to configure the size of the object you want to rack mount, and optionally the other settings. The customiser is the panel of parameters that the modelling language generates from the model file, and the readme gives a tip that tells you the project knows it is not self-explanatory.

To make the massive number of options easier to understand, change the dropdown next to the reset button at the top of the customiser panel to show details or description only.

So the customiser has a display mode, and by default it does not show the explanations. Which is a design decision in the modelling tool rather than in this project, and the project's contribution is to notice that a hundred options in a flat list are unusable and to tell you which setting to change. The phrase massive number of options is doing real work: it tells you the scale of the configuration surface before you start, which is a kindness.

Then the render and the export. The sixth key calculates and renders the model as an object, the seventh saves it as a printable file, and then you slice it and print it.

And then the important warning, which is the one thing that will stop a first attempt working. If the application cannot find the include files, make sure there is an includes directory in the same directory as the model file, and that it contains files, and that the directory layout and the file locations in your copy are the same as in the repository.

That is the price of a single-file-plus-includes distribution: the user has to keep the two together. It is a small thing, and the readme states it as important, and the alternative would have been to inline everything into one file, which would have made the model unreadable.

The browser playground, and what a port gives you

The second half of the readme is about a browser, and the mechanism is more interesting than the feature.

The model is usable from any reasonably modern browser, thanks to a fork of the Java-based port of the modelling application. So the whole thing runs in a page, with no installation of the desktop application at all, and the readme says the full feature set is available, and that the playground can even export the finished printable files for slicing and printing.

That last claim is the one that matters. A browser port that can only show you a preview is a demonstration. A browser port that exports the finished geometry is a working tool, and the difference is enormous for the use case here, because the audience for this project is people who want to design a part and print it, and most of them do not have the desktop application installed.

The reason the port is a fork is worth noting. The upstream port of the modelling application to Java exists, and a fork of it exists because this project needed it to be a fork: the readme's framing is that the project is usable in a browser thanks to that fork, which implies the fork carries something specific. And the obvious thing it would carry is the model itself, with its parameters and its include directory, made available to the browser environment.

The readme points at two entry points for people who want to try it: a quick start guide, both as a page and as a file in the repository, and the playground itself, at the project's own site. And for anyone who is not sure what the options do, it points at the configuration options page in the wiki, which has a complete breakdown with screenshots of what each option does.

The screenshots detail is worth a sentence. An option that controls a ventilation pattern is much easier to understand as a picture than as a name, and a project with a hundred options cannot describe them all in prose. So the documentation has an image per option, which is a lot of images and a lot of work, and it is the reason the option list is usable at all.

The documentation, and what its structure reveals

The documentation is extensive, and the readme says so with the phrase that every single option has detailed coverage. What matters more is the shape of the list, because the list is a description of the model.

There is a home page, a quick start guide, a best practices page, a page on the maximum supported sizes, one on the supported modifications, and a frequently asked questions page.

Then there is the configuration options page and its many sub-pages, and the sub-page names are a complete inventory of what the model can be told to do. There is a page of target device presets, so you can pick a known device rather than entering its dimensions. There is a page on the target device's dimensions and geometry. There is one on the overall structure and geometry, which is the cage itself rather than the device. There is a page on rulers and guides, which are the markings on the faceplate that help somebody align a device. There is a page on support for the printing process, which is about orienting the model for a particular machine.

Then the rack settings, and the faceplate options and the faceplate ventilation options, and then the cage options and a page for each of the cage's faces in turn: the top and the bottom, the left and the right sides, and the back, each with its own geometry and ventilation options. There is a page on the rear support options, and one on additional faceplate modifications, and one on custom cutout options, which is where a user specifies a hole of their own.

And the last one in the list is a page on ignoring errors.

That last page is the one I would read first, because it tells you something about how the author thinks about the tool. A generator that takes a hundred parameters and produces a solid model will sometimes produce a model that does not validate, and there are two philosophies available. One is to refuse the parameters and make the user fix the combination. The other is to let the model through with a warning and offer a way to suppress the complaint.

The second is what a tool for hobby use needs, because the alternative is a user who cannot print the thing they designed because two dimensions disagreed by a fraction of a millimetre. Offering a documented override, with the geometry still visible in the preview, is a better trade than refusing.

The per-face breakdown is also a design statement about the model itself: the cage is not a monolith with a few options, it is a set of faces each of which can be configured independently, and the documentation mirrors the structure of the code. Which is what you want from a project whose subject is a box with holes in it.

The repository, and the version in the file name

The top level of the repository is small, and every entry is meaningful.

The model itself is a single file at the root, and its name carries the version: the file is named with the project name and the version number. So the version of the model is not in a manifest, it is in the file name, which is a convention that has a practical consequence: a user who downloads the file and drops it into a folder has the version without needing to look anywhere, and a user who has several copies in different folders can tell them apart.

The reference to a specific file name in the usage instructions is therefore precise in a way that would not be possible with a differently named file, and the important warning about the includes directory is consistent with it: the file and the directory have to travel together, and the file's name tells you which revision you have.

Next to it is the includes directory, which holds the geometry the main file pulls in. Splitting a model of this size into a main file and a library of parts is the only way it stays editable, and it is also why the download has to be a repository rather than a single file.

There is a documentation directory, which is the source of the published documentation site, since the pages the readme links to are served from a project pages site with a path that matches the repository's own directory. And there is a directory of sample printable files, which is a genuinely useful thing to ship: a set of finished designs that somebody can print without configuring anything, and which double as worked examples of what the model produces.

And there is the guide for the browser playground as a separate file in the repository root, alongside the readme, which is where a user will look for it after they have downloaded the project and before they have read the website.

The remaining entries are the ordinary ones: the licence file, the readme, and the directory for the project's own automation.

Taken together, the layout describes a project with three audiences and three ways in. The person who wants to print something today downloads a sample file. The person who wants to design their own downloads the model and opens the customiser. And the person who wants to try it without installing anything opens the browser. The repository supports all three, and the readme leads with the middle one because that is the one the project is really about.

Editorial conclusion

CageMaker fits a person with a small device and a rack, and with a printer, who would rather adjust a parameter than measure a drawing, and a maker who wants a browser playground to try the model before installing anything. It does not fit a commercial product run, because the licence requires non-commercial use and share alike. Verify first that the options you care about exist in the version you download, since the file carries its version in its name and the options are numerous enough to have changed, that the includes directory travels with the script, since the model will not render without it, and that the licence terms fit your use, because the non-commercial clause and the share-alike clause are both live.

Frequently asked questions

Official sources

1. Issues
2. README
3. WebMaka/CageMakerPRCG on GitHub