I have finished my first pass of optimizations to the 3d viewer, and they are ready for review. Updated everything to the latest THREE.JS version, and resolved all the deprecation warnings. I have removed the FPS dropdown, animation delay is now determined dynamically by the actual FPS the system is capable of. There are options now to enable/disable both AA and the shadow. The shadow is now built using THREE.JS shadow material/layer, instead of a custom shader, so it should work on all platforms that THREE.JS is supported. There is also an option to disable smooth animation, which basically puts in a 2 second delay between animation calls.
This is my first pass of optimizations, my next pass is going to be a little more destructive in terms of existing flows. I want to remove all knowledge of prior gcode jobs from this widget, and rely on the gcode widget to call in with the gcode that is loaded. I will also look at passing gcode as a pre-parsed array, rather than a large string that we regex each time, this should speed up larger jobs.
I think there is a lot of potential in abstracting the gcode parsing and making Chilipeppr into a full gcode editor. I saw some old Python command line tools that will do transforms like scaling and skewing but nothing like what Chilipeppr could be if the gcode parsing and editing tools were surfaced for users. It’s already a great way to learn gcode just loading files and looking at them but I would love to see a parse tree rather than the long string of repetitions.
BTW, one thing I miss is the color change of paths that are cut like in Mach3. It really helps to visualize how the cut will work in the simulation and during the cut how far along you are.
Thanks for the hard work. I could not do what I am doing without TinyG and Chilipeppr.
This looks amazing and you did a massive amount of work to get all those changes in there so a huge high five to you. The shadow is really great to have back as it helped to visually see what your Z position was.
Getting to the latest Three.js is huge, but I do think to get this into the full workspace we need to upgrade about 6 other widgets that also reference Three.js including Auto-Level, Eagle BRD, Font2Gcode, SVG, Touch Plate, Super Touch Plate, etc. Have you tried to bring the 3D viewer into a full test workspace?
Since you are working on the 3D viewer, there is a minor issue that you might be able to fix, curves (G02/G03) are rendered with fixed number of line segments, I think it’s better if we make number of segments dynamic with fixed length, so curves will always look smooth regardless their length, here is a screen shot and the gcode I used to create this curve:
@jlauer Ok, I just cloned the tinyg workspace to test, and its broken due to legacy threejs code in other places… I guess Ill spend the weekend tracking down the components and spending the time to fix them.
I just updated the widget with the css changes for my raspberry pi optimized workspace, and switched that to using this widget. You can play with it here: http://chilipeppr.com/dchote
Ok, just used your new 3D viewer and man that is nice. I couldn’t believe I was getting 120fps. It feels smooth as butter. I tried anti-aliasing and at least on my Surfacebook Nvidia GPU I can’t seem to find a difference, but I’m sure on slower machines that will really help. Overall it does seem the other widgets work like Touch Plate so maybe getting the other widgets to catch up on the 3D version won’t be so bad.
@Daniel_Chote what do you think if we push these changes to production soon? I will say I’m nervous about it from one aspect. When a full job is running and things are getting high on the CPU usage, if the 3D viewer sucks down all the resources you lose the websocket. That’s why I implemented the lesser frame rates because I found that the requestAnimationFrame would give me too many callbacks even though it’s supposed to yield automatically. So, I do think we may need something where you let every 2nd callback, or every 3rd callback, etc get dropped. Not really sure though. This probably is only known via testing.
@jlauer let’s hold off until I finish up with the current refactor. And I agree, I would def like to stress test on the pi a little more to try and encounter those websocket drops and tweak appropriately.
