[Plugin Idea] 3D visualisation of print preview

Well, sure. Webgl should be able to tackle it... if only it has the mesh file rather than the gcode file.

  1. Use the github 3D rendering technology by somehow getting it the mesh file, outsourcing the work to them in the cloud in realtime
  2. Similarly, use wikifactory's 3D rendering technology in realtime
  3. Use webgl to render the mesh file on the browser in realtime
  4. Use the (Cura) slicer to include a nice preview image, uploading this to the .octoprint/uploads area before the print has even started

Personally, I've just not seen many good-looking results from attempting to render a 3D graphic from the gcode tool paths.

1 Like

there were few decent STL preview libraries for javascript that were doing pretty good job, dunno if they are still around or not.. anyhow previewing mesh is not a big deal, visualizing g-code on the other hand is a big deal and good visualizers are rare.. as I mention one that I really like I'll up a preview image :smiley: so what I find a "good looking result of a rendered gcode toolpath" :smiley: (both files were sliced by S3D)


The approach that I'm taking now with the project I'm on is to use Cura to slice for an Ultimaker S5 printer. This produces a .ufp file which unzips to reveal a good-looking preview. (I don't have an Ultimaker S5, for what it's worth.)

You don't have to slice for an UM S5 to save an .ufp file; File -> Export after slicing should give you the option to save as Ultimaker Format Package with any printer.

Brilliant. Now all I need is a Cura plugin that will—with an added button—just do that to a temp folder locally, upload that to a folder on the Pi, rename/uncompress that and then drop/rename the preview file into another folder.

Is there a template-y Cura plugin tutorial somewhere? I guess I should just go to school on your own connection plugin.

1 Like

This is going rather off-topic, but wouldn't it make a lot more sense to write an OctoPrint plugin that accepts and unzips .ufp files? If you do, I'll make sure they are supported in the OctoPrint Connection plugin.

2 Likes

For the average-use case, yes (that would be great). For this particular project I can't have the user trying to initiate a print job via Cura since they haven't yet prep'd the printer (laser sintering).

That sounds like an interesting project. I don't personally use Cura but could probably throw something together for that. Now I need to download Cura I guess. What version should I use to create a ufp file?

Any version starting from Cura 3.3 can create .ufp files, but I would just go with the current version (4.2.1).

1 Like

did you stop development of your 3D preview plugin ?

It would be good if you can implement a 3D print preview like simplify 3D

Pretty much. I don't have the time to get into the complexity of webgl. That plugin was basically just enabling the parts that were left out from the original gcode.ws library used for the gcode viewer tab to enable the 3d view.

1 Like

So I've been able to put together a rudimentary plugin that is able to extract the thumbnail and gcode file from a ufp, just have to figure out if there is a way to override the filename in the preprocessor hook or if I'll have to change it over to using the StorageInterface to add the gcode file. As it stands now, the file keeps the original ufp filename but is able to be loaded and theoretically printed from the filelist. It's just not getting analyzed and therefore the additional information expansion arrow doesn't enable. That's where I wanted to put the thumbnail preview as a test. I guess I could add a button that opens a new window with the thumbnail instead.

1 Like

Can I have a look at what you have now, so I can start supporting it from the Cura OctoPrint Connection plugin?

1 Like

Just pushed an update to the plugin that hacked the filename issue, and queues the file for analysis. Adds a button to the file list items that opens a modal thumbnail viewer of the uploaded png file as part of the ufp package.

image

2 Likes

Wow. I think I would have tried a different route but it looks like you've gotten some traction on that. Guess I'll have to take a look at what you've done. :sunglasses:

What would you have done differently? Always looking to improve my thought logic/ programming work flows.

I'm guessing that you've faked out OctoPrint to allow it to receive UFP files... then uncompressed the package and it looks like you're keeping the original file. (I haven't dived into your code yet.)

I think I would have done something to bring the file over (but not into the ~/.octoprint/uploads folder itself. I'd have then grabbed the gcode out of there, renamed/moved it to the watch folder and then to have renamed/moved the samename.png into maybe ~/.octoprint/uploads/.preview perhaps. I'd have then deleted the UFP file completely when this process is complete.

I would call mine an "over the transom" approach whereas yours uses the more directed path.

You are correct in your assumptions, I'm using all built in mixin implementation and octoprint hook methods. This allows octoprint to support the file upload of ufp files, then uses the preprocessor hook to save the uploaded file to the plugin's data folder and extracts the preview image into the plugin's data folder as well as the gcode file renaming it to match the original ufp filename. The preprocessor hook then just returns a handle on the gcode file, which then continues the standard octoprint process for saving to the uploaded location. This was all well and good, but maintained the original ufp file name and therefore the gcode analysis wasn't running on it. You could have still printed it, but in order to get analysis I used the on FileAdded event to rename the file to gcode extension. I guess I could have just extracted the gcode file directly to the watched folder like you mentioned, but the preprocessor hook throws upload errors if you don't return a file wrapper object at all and then you'd be stuck with a ufp file in your file list. The plugin could easily be modified to remove the ufp file during the preprocessor routine, and I'll probably incorporate that as I'm currently deleting all those files on gcode removal.

I suppose that's why I was thinking that I needed to get past the ~/.octoprint/uploads folder directly because I didn't want it trying to analyze that file directly and I wasn't actually interested in the file itself, just its contents.

See what you can do with it and I'll give it a spin next week, I guess.