Hi, I have an idea for a new plugin..
Octoprint shows a list of uploaded files by filename. What I would really like is that you can see what the file looks like when printed. An image of the 3D print.
Technically this could be done because the g-code preview on http://gcode.ws/ does a nice 3D look of g-code files.
Maybe I will develop it myself, first I have to learn some more Python 
Not a bad idea. Would complement my stl viewer plugin, which does that for stl files that have been uploaded to your octoprint.
Yeah, maybe my idea is only useful for users that upload gocde files, like me. If you are working with STL files you probably won't need it.
@M4rc3lv, Did you manage to get anywhere with this? It would be nice to see the progress of the print as a picture rather than a percentage.
Honestly, I'm thinking that the way to go here is to work this on the Cura side. One of their big printers now has an output file format which includes a thumbnail image of the mesh file. So when you upload that (assuming that you had a plugin which can unpack that) it's now trivial to display the preview.
Well, I want to be able to see it on my mobile or any other platform, perhaps even on the display of the machine. So there is basically no value in seeing a 3d version of the print when you can just look at the actual print that on the bed.
As long as the preview file gets stored somewhere in OctoPrint where it can be served up via the web interface, the web interface should be able to display it for workstations, smartphones and local TFT displays, for example.
In other words:
Going with Cura previews introduces a lot of dependency on the user to (a) be using Cura, (b) have the preview enabled and sent, etc etc.
gcode.ws does offer 3D views - would it not be simpler to just add that feature in, since gcode.ws is already installed and the gcode is already loaded into it?
Already installed where? I don't see it in the OctoPrint code. It's somebody's website on the Internet, to be honest. I really don't see an API to allow this to be scripted. In the old days we used to call the framing of another website's content in your own web page a "Fred Flintstone TV". If I did want to create an FFT previewer I think I'd go with the github version instead since it would likely be more scriptable.
Below is the github repo for the gcode viewer used by OctoPrint, of course not sure which version, etc.
You can see it in the OctoPrint repo here.
... and this is the same as seen in gcode.ws. Gotcha. 
From what I can tell though, I'm not sure the renderer3d.js file is being included in the UI because the command GCODE.renderer3d is undefined in developer console.
Looks like this has been on the feature request list for quite some time. Would take someone's time to make the necessary changes, test extensively, and submit a pull request since @foosel doesn't seem too interested in incorporating the feature.
Why don't you create an OpenCollective page for this project, set some minimum goal like $500 and see if anyone will fund the work? To me, this sounds like another can-o-worms plugin like OctoLapse that will work great on your own slicer and then suck the life out of you for supporting everybody else's.
But you're right, it would be hella-awesome if somebody wrote it.
This would be awesome for my next project. Rendering from the gcode itself would be so cool. Bonus points if this could be a pypy module!
So I played around with it a bit, and it would take some work to get this fully functional for sure, but it does look possible. The issue seems to be mouse control for moving around the model, but it's probably because the view model is doing something special for mouse movement, etc.
Like I said, make an OpenCollective page for your projects and I'll throw you some money.
I'm not sure I like the 3d view. It's good to get a rough idea of the model, but I wish it actually would go along with the z height slider the way the 2d model shows layers. Similar to how you can do in Slic3r preview tab, or pronterface where it allows you to traverse the layers. Unfortunately, it doesn't seem like gcode.ws doesn't have that capability.
That's a bummer. I did 3D graphics in a big way back in the days of Pascal programming and I'd say that the gcode.ws rendering seems to want some hidden line (segment) removal for it to be more accurate.
