search

Microtome / microtome

A browser based GPU accelerated 3D model slicer
Apache License 2.0
28 stars 5 forks source link

Support talking to printers via json serial server #8

Open DanielJoyce opened 8 years ago

WesGilster commented 8 years ago

Do you have a protocol planned for your json serial server? Just curious as I have a project that has a fully functional backend with quite a bit of print functionality. We could easy implement one of our PrintFileProcessors to to listen to your json and print accordingly.

https://github.com/area515/Creation-Workshop-Host

DanielJoyce commented 8 years ago

Ahh sorry I missed your comment. Was gonna use Serial Port Json Server to talk to some kind of existing board / firmware.

Is there and existing format that you support I can reuse? I could dump a set of images in a zip and some json information. I don't know what existing formats are available

The slicer is all camera tricks, fragment/vertex shaders, and image processing. I am in the initial stages of defining the new advanced slicer, which using these techniques, will support external supports, internal supports, shelling ( possible hollow shells with their own infill pattern ), rafts, etc.

Basically think of it as 'scanline/slice voxelization' where instead of building a octree slice by slice the output is a binary image immediately suitable for printing.

If your 3D card can load it, it can be printed.

DanielJoyce commented 8 years ago

I guess theoretically it should be relatively easy to port the slicer to Java 3D library of some sort.

jmkao commented 8 years ago

I think there are a few ways we could go, and we have the option to design our own interaction protocol.

CWH (soon to be renamed Photonic3D) has a fairly robust set of motion templates (GCode templates and exposure/lift calculators), as well as a physical resolution calibration tool that can determine the X/Y pixel dimensions & pixel density (pixels/mm) based on an interactive UI.

We also have support today for taking a zip of images and then printing it, which utilizes the motion templates but not the resolution calibration.

Off the top of my head there are a few options (which are not necessarily mutually exclusive, but might be ordered in some kind of evolutionary roadmap):

I think for graphics card (e.g. WebGL) based acceleration, the browser is a better place to do this than with Java3D. The libraries necessary to get Java3D working in a hardware accelerated fashion on the Raspberry Pi are not very mature (I think a compatible OpenGL implementation was only checked into Jessie in February, and contains some rendering bugs) and don't have the kind of developer manpower and user base that WebGL has.

DanielJoyce commented 8 years ago

So it seems offloading slicing to the managing computers browser might be a useful feature as well.

Well, could definitely add a "Hosted" mode which could pull printer information from CWH and use it for slicing, or simply reuse the components for your own hosted version with some new glue. In the near term I plan on working on the new slicer and then we can talk more. Do you have a REST api or websocket protocol for pulling printer information?

On Mon, Mar 28, 2016 at 10:25 AM James Kao notifications@github.com wrote:

I think there are a few ways we could go, and we have the option to design our own interaction protocol.

CWH (soon to be renamed Photonic3D) has a fairly robust set of motion templates (GCode templates and exposure/lift calculators), as well as a physical resolution calibration tool that can determine the X/Y pixel dimensions & pixel density (pixels/mm) based on an interactive UI.

We also have support today for taking a zip of images and then printing it, which utilizes the motion templates but not the resolution calibration.

Off the top of my head there are a few options (which are not necessarily mutually exclusive, but might be ordered in some kind of evolutionary roadmap):

  • Supply zip of PNGs and user has to ensure calibration parameters are the same
  • Supply zip of PNGs with a JSON file with user-supplied parameters that could be checked to see if calibration parameters are the same
  • Query for calibration parameters, then generate zip of PNGs and include the JSON file to check if the calibration parameters are the same
  • Supply SVG vector file based on physical dimensions that would be rendered to pixels by CWH, using its calibration parameters
  • Query for calibration parameters to build a more accurate build-plate previewer, then generate and supply SVG vector file

I think for graphics card (e.g. WebGL) based acceleration, the browser is a better place to do this than with Java3D. The libraries necessary to get Java3D working in a hardware accelerated fashion on the Raspberry Pi are not very mature (I think a compatible OpenGL implementation was only checked into Jessie in February, and contains some rendering bugs) and don't have the kind of developer manpower and user base that WebGL has.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/DanielJoyce/microtome/issues/8#issuecomment-202495596

Daniel Joyce

The meek shall inherit the Earth, for the brave will be among the stars.

WesGilster commented 8 years ago

We are in the middle of "swaggerizing" our restful API, and you can follow our progress on that issue(https://github.com/area515/Creation-Workshop-Host/issues/188) to find out when that will be ready. We currently use Websockets as an event notification system. Even our websocket API has a very restful style where it's designed to connect directly to specific printers and printjobs. Once that socket is connected, you get events for for the object you specified in the URL.

Here is a quick rundown:

  1. The restful API is broken up into 7 services Printables, Machine, Settings, Printers, PrintJobs, Media and Video based ProgressiveDownload.
  2. File uploads allow multipart/form-data or application/octet-stream (Rest based urls)
  3. Regular video supports any content type through progressive download (Rest based but a bit sloppy)
  4. Live video streaming are multipart/x-mixed-replace (Rest based urls)
  5. Image snapshots are image/jpg and some are png (Rest based urls)
  6. Optional SSL and Basic Authentication.

It's very simple to consume.

We are looking at integrating your slicer for two different functions:

  1. Showing the current slice as a model that is currently being printed.
  2. Slicing STL models for printing on the server.

As a part of the second function, I'd like to work out a vector based protocol(SVG?) so we don't have to ship these huge graphics back and forth to the server. I'd also like to work out a standard interface that we can both of us can agree on.

DanielJoyce commented 8 years ago

The whole point of the slicer is to avoid vector slicing. It's rendered entirely as a raster based image by the gpu and shaders. Its a brutally efficient collection of rendering 'hacks'.

SVG would slow it down because it requires actual geometry processing. And then you get into all sorts of additional nasty issues if you want to do shelling.

As for the images, they could be shipped as PNGs or gifs. They are black and white and would compress to almost nothing.

I made a 2048x2048 black image and drew a bunch of white shapes on it and saved it as a gif. It came out to 54kb. 100ish kb as a png. There may be better formats to use.

Its also perfectly possible to run the slicer 'headless' in the dom by rendering using a off-screen webgl context in a offscreen canvas element and both sending a copy of the image to save, and blitting the image to a visible canvas for the user to watch progress.

Tell you what, I'll open a new ticket for tracking this idea. I am a java dev normally, and have gradle experience as well. I can fork or create a new repo to build a component that does what you need.

DanielJoyce commented 8 years ago

see #11

DanielJoyce commented 8 years ago

I just want to say that when WebGL adds support for microtesselation, especially the kind directed by texture/vector maps, then its trivial to support it in the slicer. Users could then use a texture to modify a model, or tell the opengl context to 'smooth' it ( by dividing more via microtesselation ), and the slicer would basically support it automagically.

WesGilster commented 8 years ago

The raster/vector issue isn't a deal breaker. Just keep in mind, that for the CPU savings we gain in WebGL we loose some in IO transfers, zip compression and zip expansion. I'm still pretty sure there is plenty of performance gain from the client slicing.

You mentioned you were a Java coder, so you might be interested in taking a look at our parallel slicer for STL. It's fully functional and comes with a swing GUI to help debug slicing issues. The general benefit is that you don't have to perform a "preslice" phase and zip the contents before printing. Instead, the slice is performed in parallel to when your gcode commands and motors are printing the previous slice. The positive part to this approach is that the slicer really doesn't need to be that efficient because it just needs to be faster than the motors and exposure time of the previous slice. That's almost always attainable. The other benefit is that since we are in control of low level slicing, we are keeping track of non-manifold geometry and can report that information back to the rest client as errors.

The problem with this approach is that the slicer has to be perfect in order to trust it, and ours needs some work. The other problem with this approach is that you don't have all of the cool features that come with WebGL as you've mentioned.

Let me know if we can be of any help.