This is my raspberry pi optimized workspace with the optimized 3D viewer all running

This is my raspberry pi optimized workspace with the optimized 3D viewer all running on a raspberry pi 3, with a dell 21.5" multitouch monitor connected. The gcode being rendered here would not work on the vanilla tinyg workspace at all, the pi would hang and chromium would error out. As you can see, with shadows disabled and AA turned off, chilipeppr runs fantastically on a sub $50 computer. It’s quite awesome to boot right to chilipeppr!

I am currently writing a blog post about my CNC build, but I may write a mini post about running the serial port server AND the front end via chromium on the rpi3.

Sweet, nice work. Yes please, blog about it all, we would be interested.

So killer

This is amazing that just the anti-aliasing became the most key item between it working on Raspi 3 and not working. Damn. Love these changes. Is it true as well that having the 3D viewer be full browser width/height under those other widgets also caused flickering?

@jlauer I think the flickering was when it ran out of gpu memory and started dropping mesh. Full screen does make it considerably slower on the pi however. I made some tweaks to the 3d viewer to make it work in whatever element you attach it to. I now just need to go and make sure that it still looks great when full window.

@jlauer what I may do is have the widget scan the dom for 3dviewer classes, and allow you to choose which element to render to. That way we can have it render to an area, or render full window as an option

I noticed when going into Jog mode the calculations are off since it uses the width/height of the browser to calculate the jog position. Maybe that calc should use the element width/height to solve that.

@jlauer good catch. I’ll add a ticket and follow up on that

Looks like Inspect mode is off too with same type of calculation. I use Inspect Mode a lot when trying to fix a messed up job.

I think @sszafran mentioned this too, but it would be cool if there was a pubsub exposed that let the Gcode widget send which line just got executed and the 3D viewer took it in and rendered all prior lines in a different color to indicate it was milled. I know it’s brutal when new features get suggested cuz they’re all a decent amount of work, so take the suggestion with a grain of salt. It’s just that you now have the most tribal knowledge of the 3D viewer probably even ahead of me now.

I dont think it would be too difficult, i just need to review how the gcode to line relationship stuff works in more depth.

@jlauer ill fix and push up later tonight after work. Easy problem

Each line of Gcode has a matching array item in the Three.js object for the 3D viewer. In the userData element of each Three.js item is a copy of the Gcode, which G command, feed rate, etc. So, you could just take the line number passed to you from pubsub and iterate through each Gcode item starting at 0 and change it’s color/opacity in a loop up to the number passed to you.

@jlauer Nice. In theory then, for our current tween, we could actually copy the entire line as a highlight, rather than the start to end point straight line that it is now… right?

@ameen.nihad ​ is the array that John mentions a potential answer to the polygon issue? Iterate through, extract the dupes and remove the offending lines from the gcode widget.

Ok @jlauer , I just pushed up my fixes and optimizations for inspect+jog, live at: . I hope you dont mind, but i removed the red line, since we highlight around the section anyway, it seemed kinda pointless to me