oh yes!!! and if you take into consideration that not everyone run this on rpi but also opi, different x86 boards etc etc...
now, tbh I'd rather just shoot the whole g-code into browser and let browser do the visualization .. webgl is powerful enough to handle that and I guess whatever user looks the octoprint web trough is more powerful than soc board octoprint is running on 
Well, sure. Webgl should be able to tackle it... if only it has the mesh file rather than the gcode file.
.octoprint/uploads area before the print has even startedPersonally, I've just not seen many good-looking results from attempting to render a 3D graphic from the gcode tool paths.
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 
so what I find a "good looking result of a rendered gcode toolpath" (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.
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.
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).
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.
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.
Can I have a look at what you have now, so I can start supporting it from the Cura OctoPrint Connection plugin?
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.
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. 
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.
