Any plans or interest to do real 3D Printing support in LW4/ future software? You know, the full experience with STL import, plate layout, slicing, rendering the gCode, and sending the job, all with a 3D viewer. What +Peter van der Walt and @Sebastien_Mischler and I started work on last year.
I one gazillion times support this motion.
Hohoho, It’s ambitious, but feasible… with time 
Would it work with a standard RAMPS 1.4 board? If yes, then great. If not, then I think adoption would be muted, to say the least.
Why not embed octoprint?
Well, I just wanted Repetier Host type functionality that played nice with Smoothie - so let’s stick the plating and slicing into the browser using ThreeJS as a viewer. Right now there’s extra clicking involved to make my gCode file there, save to local disk, and then either open with pronterface to send it if I’m tethered on a laptop or upload to octoprint. I know I can use the slic3r UI and have it go directly to an octoprint instance… but meh. I like Repetier Host’s interface.
Re slicing, yes I was very excited about kiri:moto at the time. That said. That said. If it’s an install we can package slic3r (binaries should be available for all OS) and invoke it. If it’s a website, well, I’m not gonna talk about cloud slicing unless we can actually do it.
+Peter van der Walt yeah, I am familiar with Octoprint’s arch, I did the initial Octoprint slice -> curaengine & helped with the first Smoothie web panel (1st KS days).
TBH Octoprint has an abstraction around the printers to handle the different kinds of messaging / connections etc. That might be worthy of pulling out and having it be the adapter other people can plug different wrappers around. So you can drive your UI/Connection over something simpler vs managing your own serial/integration library.
I’m spitballing here
So the JS backend just talks to another process, over localhost to get status, execute commands and send gcode to the printers/lasers etc. Then you can pipe in a slicer or other features however you wish.
FWIW I have yet to try LW4 out as I’m still in the process of finishing my latest CNC mill (No lasers in this house!) that is GRBL powered.
I have to finish my book before I do any more open source :D. Writing is hard! And I am not a JS fan/user at all 
sry. If I did anything for LaserWeb I would do it in Elm 
@Ross_Hendrickson Embedding octoprint is not needed. We already have a server that could be run on a Raspberry Pi.
It should be possible to integrate usb streaming to repetier or marlin for 3d printing a bit later.
I almost finished re-writing SLAcer.js in ES6, without any dependencies to TreeJS. The module will be available on NPM. I would not have time to add the fill functions for FDM printing. But I think it will be a good working basis for the main developers …
Good work!
I’ve always been a friend of small tools that you can combine to do something bigger (the Unix way). I have to transfer a file anyway - either the gcode or the stl. Focus on the core but offer nice interfaces for others to plug into first. You can always create something extra that uses this feature, but don’t create a “does everything integrated monster”.
+Peter van der Walt 3D printing slicers use a much more complicated approach than Fill Paths; they have to look at what happens in the layers below and above to decide where to bridge, where to add supports for bridging below, and other complications.
Daids work for Cura makes it almost trivial to plug into curaengine https://github.com/Ultimaker/CuraEngine
for slicing, you already have a server component so why not just slice on the machine versus trying to in the browser?