Programmer's Notes

---

One big thing I notice is that the slicing itself is realtime even on my Pathological 800k triangle mesh, hereafter referred to as a Pathology Pumpkin. This means that the real slowdown is in file I/O, because that mesh takes a few minutes to slice for output to gcode. Great pains should be taken, therefore, to do everything in memory before writing out.

---

The Line2D class has been modded to include a feedrate and an extrusion speed. This way, pretty much all of the 2D things we do to the gcode can be done on a per-slice basis, in memory.

---

Operations that require multiple slices interacting… may be a problem. So far I’m not holding all slices in memory at once, so I don’t have a mechanism to hold all the slices together. I think perhaps we’re better off if we hold fast to one slice at a time but sometimes access the mesh for things other than intersections during a slice operation.

---

Having trouble drawing arrows. There’s got to be a way to do this without trigonometry…

---

One thing we hear a lot of and I mean a LOT of is settings simplification. And it’s entirely fair. There are as Revar pointed out maybe six variables at most that completely describe what settings you should have, and SkeinForge has easily over a hundred settings. It’s total pandemonium. As the number of settings to SuperSkein grows, there needs to be a sustained effort to pull new parameters under smaller umbrella variables…

---

Processing’s Keyboard handling sucks on toast as far as I can tell. Having a real laughable time setting up a text box for cryin’ out loud….