With some help from Mitch Bradley, I managed to get his Mach3 IJK Absolute gcode working in my fork of the 3d viewer!
My fork now renders all of my CNC job gcode perfectly!
Chilipeppr still has problems with my large jobs >2MB or so, but I think its going to require some serious work to fix that. As seen with this 3d widget rework, having to provide the same object structure for other plugins to interact with may cause more work than anyone’s willing to tackle all at once. There are a lot of small changes that can be done to shave a few ms off here and there, but the impact of those changes are not really known until its deployed to a full workspace, and all of the other plugins get tested against it.
Overall I am very happy with the state of chilipeppr for my use case, I have managed to get it very stable running entirely on a raspberry pi 3 (backend and frontend). Larger jobs like the one in first screenshot seem to pause randomly during the job, but if you just leave it, it will keep going until its completed. There must be some sort of heavy looping going on in the gcode widget on receiving completed lines back from the tinyG, it’ll occasionally throw a “page has stopped responding, do you wish to reload” error, but if you leave it, it will eventually continue. The 3d viewer now drops gotoXYZ events when it is struggling, this is wrapped in dynamic fps scaling logic that I added. If there is an animation currently in progress, the gotoXYZ method just returns before doing anything. This ensures that the 3d viewer doesnt become the total burden on the CPU if its bogged down.
I would love to merge these changes because you’ve done some beautiful work.
One thought is that with going to r86 of Three.js from the r76 version we were using, I believe that messed up other widgets that also use Three.js. That would mean all widgets need upgraded to release this. That’s some decent work.
One thing I’m noticing that’s odd is when I’m dragging my trackpad around your 3D viewer with button down to pan around, I get smooth motion around 24 fps. If I stop for a moment by releasing the trackpad button and then resume with button down again, I get like a 1 second delay before the viewer takes my moves again. Any ended move seems to have this delay except zooming. Zooming, though, seems to jump to 125 fps so it’s as if 4 or 5 overlapping animation loops get triggered.
The other thing I’m noticing is that in the simulator you don’t get smooth movement anymore between the start/end of the line. Instead you just get a full jump.
@jlauer if you could link me to all the other widget repositories and respective workspaces, I can attempt to fork and update them all.
As for the FPS thing. It’s likely that it hasn’t determined FPS cap, then it does. Moving will attempt to go as fast as possible.I can probably remove that override to let it be consistent. I added that for the pi, so that if FPS cap was really low, you would still get relatively smooth move actions.
If you could give me an example of the tweening weirdness I’ll attempt to debug and fix it.
For the widgets that use Three.js, here’s the list from looking at the widget pulldown menu: Auto-Level, Eagle BRD Import, Touch Plate, Super Touch Plate, SVG Import, and Font2Gcode. In Grbl workspace the Auto-Level is it’s own fork so that would be needed too.
On the 1 (roughly) second delay on movement, I wonder if that just happens on Windows which is where I’m testing.
Main things that have completely changed are fonts and bounding boxes… The thing that makes this really tricky is that if anything imports the old 3d viewer, it breaks everything… missing/deleted image from Google+
Ok @jlauer I have pushed up an updated tinyG workspace referencing all my widget forks.
A couple of things, everything has been updated to the latest threejs.
The svg to gcode widget is busted, had a slightly different use case for the bounding box helper, i couldnt get a quick fix in for it, and even with that disabled, it doesnt seem to render anything.
The eagle widget renders everything, but there seems to be an origin offset issue, when you play the animation, it is not in alignment with the board, hopefully this is something you know where to look for.
Everything else seems to work without errors logged (in terms of what I could test)
In Eagle widget it looks like mouseovers don’t hilite the signal path after a first couple moves. From looking at Javascript console the newer version of Three.js got rid of .applyProjection().
This is a lot of work, but I think it’s great you have a test workspace now. Your 3D viewer in the test workspace doesn’t have that 1 second delay I was experiencing yesterday, so it’s feeling nicer.
Well, I just loaded the sample Arduino Uno file in the file pulldown menu. Then watch Javascript console as you mouseover the signals. You get unending warnings. Maybe you just need to rename anywhere there is a .applyProjection() to be .applyMatrix4() since they deprecated it, but I don’t ever recall calling .applyProjection(). Rather I know I made heavy use of .intersectObjects() to determine what your mouse was over. So maybe it’s just a shift on how to use intersectObjects on the new Three.js version.
