Ultimaker
Truncated octahedron infill
This is the backend code for 3D Honeycomb / Truncated Octahedron infill, as seen in Slic3r (but not [yet] PrusaSlicer). The infill pattern only bridges once per "module", at the smallest bridge point on the square horizontal faces (with a bridge span of approximately [line_distance / 2]). This produces a strong infill pattern which should work at very low infill percentages.
Note that this is only the backend code. It will need to be bolted onto the frontend interface. To make that easier, I've tried to make sure that the public function syntax is exactly the same as the Gyroid infill, so hopefully it should just be a matter of copying the Gyroid definitions, and replacing "Gyroid" with "Troct".
See the following image, taken from my fork of PrusaSlicer, demonstrating a 5% infill with no walls, where I've changed the colour at each direction change. I've been having trouble testing this code (see below); this image is based onthe PrusaSlicer equivalent of the code in this branch:
In other words, this code, in its current form, probably won't work. I'm hoping that someone with Cura building capabilities can test it, or help me build a working test setup on my Debian system.
I have also attempted to tweak the density calculation to make it more accurate. Assuming I've got the right density calculation (i.e. [infill_line_width / line_distance]), it should have a similar accuracy to the gyroid and rectilinear infills.
Note: this is essentially the same change I've opened a pull request for in PrusaSlicer. There are some additional minor bug fixes due to pattern start/end points, but probably more introduced bugs due to the porting process.
p.s. I'm having a really hard time getting the Lulzbot Cura GUI to compile on my computer, and the test scripts for CuraEngine aren't working for me. Here's an example that I tried to run, and its output:
grinja@hera:~/install/CuraEngine$ ./build/CuraEngine slice -v -s machine_extruder_count="1" -j ../Cura/resources/definitions/fdmextruder.def.json -j ../Cura/resources/extruders/prusa_i3_mk3_extruder_0.def.json -j ../Cura/resources/definitions/prusa_i3_mk3.def.json -o "output/test.gcode" -l "/model_1.stl"
Cura_SteamEngine version master
Copyright (C) 2020 Ultimaker
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
[ERROR] Couldn't find definition file with ID: fdmextruder
[ERROR] Inherited JSON file "fdmextruder" not found.
[ERROR] Failed to load JSON file: ../Cura/resources/extruders/prusa_i3_mk3_extruder_0.def.json
I don't need a GUI; I just need some way to test out this pattern and produce GCode.
Hi @gringr
- Lulzbot is a fork, not the main repo. Will probably also be really out of date. (The Ultimaker one is the main one.)
- That said, getting Cura set up is no easy task... However if it's only development for the engine, you could also just take an existing version of Cura and replace the CuraEngine executable with a compatible one you compiled. You will need to add the setting, but you could either pretend yours' is Gyroid, or edit the json files in the Cura install.
Besides all that, I do have a question: What would the great advantage of this be? You say:
The infill pattern only bridges once per "module"
... but Gyroid (and most of the 3D infills) already don't bridge a lot.
As a direct comparison with gyroid, the patterns are similar, and the mass of the extruder will be moved to similar places (i.e. they're probably fairly similar in speed). Here are the differences I can think of at the top of my head:
- fewer direction changes: smaller GCode, more consistent patterning, no turning in mid-air
- more rigid structure (i.e. 45° angles)
- points of direction change are precisely the points where a bit of delay will increase the strength of the structure (i.e. delays, if they happen, aren't wasted)
- Can be used at lower density (e.g. 5%)
- Constant / predictable layer transition angles [similar to other 3D infills]
Compared to other 3D infills, it shares with gyroid the quality of having no planar lines. This means that the infill has a bit more "give" before breaking, and makes the structure less likely to explosively fracture. In other words, bits of the infill breaking are less likely to cause other bits of the infill to break.
While we're not completely convinced by the presumed advantages you list (more rigid and printable at lower density are doubtful for instance), the actual big sticking point is that this isn't fully integrated (not just with the front-end, also with the engine parts that handle infill) or tested in any way at all (either just the unit-tests we've made for infill or printed in real life).
To put it bluntly: Basically it just compiles, and that's it. We're not going to put in the extra work ourselves (given all other tickets/issues/etc. that require attention).
In other words: We can help you by answering questions and pointing you to documentation, but unless this becomes a complete package that we can just (code) review, test and merge (if all is well), we're not likely to pick this up.
