This project can be edited with only [OpenSCAD](https://www.openscad.org/downloads.html) and the source files in the `scad/*_v1`, `scad/*_v2` or `scad/*_v3` directories which make reference to files from `scad/libraries`.
With just OpenSCAD, you can use scripts such as `scad/50ft_v3/gnal_50ft.scad` and export the different modules in [OFF](https://en.wikipedia.org/wiki/OFF_(file_format)), [AMF](https://en.wikipedia.org/wiki/Additive_manufacturing_file_format), [3MF](https://en.wikipedia.org/wiki/3D_Manufacturing_Format), [DXF](https://en.wikipedia.org/wiki/AutoCAD_DXF) or SVG (drawing) format.
The CSG models can be [imported](https://wiki.freecadweb.org/OpenSCAD_CSG) into [FreeCAD](https://www.freecadweb.org/) and DXF models should be readable by AutoCAD and [QCAD](https://www.qcad.org/en/).
Running any of the build scripts scripts--`scripts/v1.sh`, `scripts/v2.sh` or `scripts/v3.sh`--will start an OpenSCAD build process of all components and will log stats about the resulting files and render times to `notes/v1.csv`, `notes/v2.csv` or `notes/v3.csv`.
It's best to run these scripts in the background on a powerful machine or better yet, not at all. See the `stl` folder for pre-compiled STL files for 3D printing or the [releases page](https://github.com/sixteenmillimeter/GNAL/releases) for .zip and .tar.gz archives of all versions.
In the process of building this first version several approaches were evaluated to generate the spiral shape.
The first is what's best described as a brute force approach laying out an excessive amount of rectangular facets and unioning them together in such a way that the result would be a single continuous spiral.
This took hours to days to render depending on the machine used.
Besides the exhausting render times this approach bugged me for one reason: all facets of the spiral were the same size, meaning that the small diameter inner parts of the spiral were packing in millions of unnecessary polygons to allow for the large diameter parts of the spiral to be smooth.
This didn't sit well with me.
How many CPU hours are being burned by adding detail to a place that doesn't matter?
Finally, an external library called [`path_extrude.scad`](https://github.com/gringer/bioinfscripts/blob/master/path_extrude.scad) by [@gringer](https://github.com/gringer) was brought in to handle the complicated spiral extrusion step.
A simple function that plots a spiral in Cartesian coordinates is used to draw the path and a 2D triangle is extruded along it by the library.
This allowed for the path to be drawn at a consistent "resolution" throughout the entire spiral, so the facets of the outermost and innermost parts were the same or extremely similar.
The experimentation in this version predate this particular git repo and so will not be found in the git history, but you can find the vestigial functions in the `spiral` directory used for benchmarking different approaches.
When printing a model with [FFF printing](https://en.wikipedia.org/wiki/Fused_filament_fabrication), any piece that overhangs empty space (usually) needs to be supported by a temporary removable structure beneath it otherwise you risk the piece drooping.
In the case of V1 model, the spiral was completely suspended by the spokes of the reel with large gaps of empty space.
This means there were 90 degree overhangs under the most critical part of this model; the grooves for holding the film in position.
Printing and removing support structures from beneath the fragile spiral made post-production dangerous for the piece and time consuming.
The solution to this was to extend the spiral to the bottom of the reel and remove triangular sections from them to allow for a lighter print and better chemistry movement.
Most printers should be able to print these structures without any support material or any resulting deformations in the model.
One other change in this version is that it reduces the spiral models to a single one to be duplicated, rather than two distinct top and a bottom pieces that differ in only minor ways.
This decision was motivated by an interest in making this design better (cheaper) for injection molding.
A secondary benefit of reducing the spiral to a single model was to immediately cut render times for the entire project nearly in half before any other optimizations were made.
The first meaningful code optimization toward this goal was provided by a helpful comment made on a long-forgotten design shared on a 3D printing forum.
> It may be more efficient to approximate the spiral as a series of arc segments, like this <[Github gist](https://gist.github.com/sixteenmillimeter/839c16d39d26d04154f52b3f3ee6ee78)>.
This reduced the several hours render time to 1-2 hours, which worked for this version. Ideally this will be improved further in future versions.
Beyond some explorations into OpenSCAD hacks (rendering each complete rotation of the spiral and stitching all resulting STLs) the next version will incorporate other languages and platforms to find the fastest render time for a GNAL spiral.
All previous approaches are being compiled into a suite of tests to benchmark render times.
The goals of V3 are to **greatly** optimize the spiral generation code for speed and to restore the feature of the V1 spiral which maintains a consistent size of individual facets throughout the spiral even as the diameter changes.
This will be considered a stable release candidate for publishing the project.
Since the benchmarking process ([see below](#benchmarks)) was developed between V2 and V3, render times are optimized in this iteration of the project.
The success of the [`spiral_3.scad`](../scad/spiral/spiral_3.scad) approach stood out from the rest as fastest, so it was reworked into what exists in V3.
The spiral itself is plotted in 2D with a relatively simple formula that is expressed in this OpenSCAD script through a number of in-line helper functions.
It draws the position of various points along the spiral path and then uses the `path_extrude.scad` library to extrude a shape along those coordinates.
This proves to be fast and efficient while not sacrificing any detail in the geometry.
Prior to release a serious flaw was found while printing the V3 design.
The attempt to remove the need for supports in V2, actually printing the spiral was creating curious side effects during fabrication.
Not having material in the voids below the spiral, it seems, allowed air to cool the part and would consistently cause prints to fail when it reached the actual spiral at the top of the reel.
Since this is the most important element of the reel, the triangles have been removed and the design is more similar to V1.
In a compromise to make the process of removing the support material less dangerous to the detail on the top, the spiral itself extends lower than V1 into the space between the spokes of the reel.
The spiral is also made thicker and is a multiple of my nozzle diameter (0.4mm).
This uses slightly more material but is less fragile than V1 and test prints proved that the supports were less difficult to remove than in the earliest model.
In the process of publishing this repository I started questioning claims I was making in this README.
Throughout the development of this processing reel I've been plagued by long render times.
As a sanity check, I went through my personal development history on this project and produced 6 distinct spiral generation scripts that I ran through a series of tests to benchmark the render performance, total volume generated and number of facets produced.
Render time was the primary metric that concerned me, but I considered the others important in comparing these different approaches.
As you can see, the different approaches lead to wildly different render times for the same test.
If you look at the complete results you will see many tests did not even finish due to exhausting memory on the machine or the process being killed by the cloud host (using too much CPU for too long, most likely).
In the case of `spiral_3.scad` and `spiral_7.scad` measuring "0" seconds, this just means that the process finished rendering in less than 1 second.
Render times have gone down dramatically between V1 and V2.
Times halved again between V2 and V3.
The volume has stayed consistent with major changes in geometry (between V1 and V2).
The file size of the V3 spiral has reduced to about 30% of the V1 and V2 spirals and the facet count remains roughly the same throughout (which was a surprise).
Faster render times mean more iteration and less time between tests.
The next part of the process to examine is slicing which has primarily been done with Cura, but other engines will be looked at for their speed, efficiency and print quality.
