Started work on slicing / host software for DLP printer. Writing it as a chrome app which allows it to access serial ports, and be aware of second monitors!
Initial plan for controlling printer is using a serial GPIO board to control the driver for the z stepper. If that doesn’t work out, will switch to arduino running some simple sketches. Will not be sending GCode as its pointless for something merely stepping up/down in the z axis.
The slicing/preview software is initially purely intended for DLP based printers. So image based only. There is no polygon generation step, just using custom shaders and opengl to slice the geometry.
In the sample pic, I manually set the slice z height to just ensure the simplest things were working. If I vary it,the shapes grow/shrink as expected. It even properly handles internal voids/hollows as long as your triangle orientation is proper, and your mesh is watertight.
I’m calling it “Microtome”, which is the device used to slice thin sections of samples for microscopy analysis.
Sounds interesting - couple of questions / thoughts - are you going to try and support tilt vat designs, and do you think you can maintain the exact timing required for the exposures?
Exposure timing is trivial. When running an actual print, I plan to use double buffering to swap between an all black screen during moves and the current slice during exposure.
Exposure times are on the order of seconds, which is ‘forever’ in computer terms. Being +/- a few ms shouldn’t impact it all.
As for tilt vats, eventual support should be possible, but for now I am just targeting flexible vat designs, which judging by the results on the buildYourOwnSLA forum can work very very well.
@Daniel_Joyce Can’t wait to give it a try. Creation Workshop seems to struggle to manage the 100-500ms exposure times I’m using with a modified pico, at the moment that’s probably an exception rather than a rule.
Which PICO did you modify? I am considering moding one with near-uv LEDs.
LC3000. I really want to try one of the Aaxa’s though.
The jr2 native is 640 x 480. Don’t use it. Aaxa pico is 940x540
Is there a reason you don’t want to just use existing slice-to-svg function?
Because GPU slicing is super fast? No need to rasterize polygons either. 
And no need for a thousand files.
