The first model we had a problem with was a lovely Bilateral Pentagonal Icositetrahedron sent to us by Scott Sherman (loki3 on Shapeways), who we met at G4G11. The model is great and even the idea of this isohedron is amazing, but its vertices were "mothy" (thanks M. for that word) and the model fell apart at the corners while I was trying to remove the supports.
These print fine on Shapeways (they are available in loki3's store), but with MakerWare something was going wrong. My guess is that there are just too many triangles at the corners where spheres were added to round out the connections between cylinders; or perhaps the meshes of the sphere vertices just weren't playing well with the meshes of the cylinder edges. When you open the file in MeshLab you can see the suspicious-looking vertex meshes:
I don't know how to fix this problem in MeshLab, and wasn't getting anywhere with TopMod either, so it was time for a Hail Mary pass to Tinkercad. Since Tinkercad can get slow with meshes that have too many triangles, I did a couple rounds of Quadratic Edge Collapse Decimation (a great future band name; also see Day 134) to the model first to reduce the number of triangles, and then imported the resulting lower-poly model to Tinkercad. It turns out that Tinkercad seems to reinterpret whatever mesh you give it; my guess is that this is something to do with keeping complexity low so its servers don't get overloaded. Or maybe it is due to Tinkercad trying to make hollow or open models into solid, closed models. Or maybe it is something else entirely, but in any case, sometimes importing an STL file to Tinkercad works fine, and sometimes it causes a problem (for example, with Mathematica-exported knots like the one in Day 11), and every once in a while it fixes a problem. This time was one of those whiles; after going through Tinkercad and back out again, this is what the mesh looked like in MeshLab:
At first glance this does not seem to be an improvement of the mesh, but it turns out that this model prints just fine, with sturdy vertices (that's another great band name right there). Below is a picture of how it came out; compare this model with the Pentagonal Icositetrahedron we printed on Day 197. And stay tuned for tomorrow's guest post about this and other isohedra from Scott Sherman!
The second model we had a problem with today was a Great Rhombic Tricontahedron model from Chris Wallace (kitwallace on Thingiverse), generated from his incredible Polyhedra Index that can produce OpenSCAD code for generating every polyhedra that anyone has ever heard of, ever. This particular polyhedron is the basis for the Frabjous puzzle that we discussed on Day 252, and it is a strange, self-intersecting beast. Apparently this was reflected in its mesh as well, because I could not seem to get MakerWare to slice it in a sensible way; it was as if parts of the model that needed support were invisible to MakerWare, and support would not be built to them. In addition everything was taking forever because the inside of the model (which nobody would see after being printed) was very intricate. A couple of Quadratic Edge Decimations in MeshLab allowed me to import the STL into Tinkercad, which apparently simplified the model enough to print. Except for one problem, which you can see here:
Well, you would be able to see it if I could photograph the translucent filament better. What you're seeing is the bottom of the model, where five points meet the build plate. In each case at least one of the points dislodged itself from the raft before things could get properly connected up. The model was just too pointy; or perhaps alternately, not all five of the corners were equally flush with the build plate, and so one or more of them was actually printing a layer or two in the air. Either way, the problem could be fixed with another hack in Tinkercad. After exporting from MakerWare (to preserve the five-points-down orientation), and then importing into Tinkercad, we grouped a large cubical hole with the bottom of the model to cut off the tips of the five points at the base. With these flatter points the model was able to print successfully:
