I have the tinyg workspace working with my optimized 3d viewer.

I have the tinyg workspace working with my optimized 3d viewer. Autolevel and Cayenn plugins break things, so they are disabled in my tinyg workspace until I can spend some time updating them.

For full window 3d viewer, some workspace CSS additions are required, they can be found here: https://github.com/dchote/workspace-tinyg/commit/7a7eb373ee4a67c037c5f63de98d53967f5c5825#diff-4a8f76b271b700662f7abc9b54264286R204

My tinyg workspace can be found here: https://github.com/dchote/workspace-tinyg

Some performance notes, I have a new 13" macbook pro, 3.3ghz 16GB of ram, but it only has an Intel Iris 550, driving an LG 27" 5k display. Full window view for the 3d viewer is not fast at my resolution with AA and Shadows on, it seems totally fine with both disabled. Running in my Raspberry Pi workspace with AA disabled, shadows work just fine. There is definitely a big performance hit by adding in all those extra hidden pixels behind the other widgets.

Can you give some context on how autolevel breaks things? I’ve spent quite a bit of time in that widget over the last week and can look for fixes.

@Justin_Adie the threejs code in both of those widgets need to be updated to match my 3d viewer.

I see. So more a compatibility issue than a bug.

@Justin_Adie yeah. It shouldn’t be too hard to fix, I’ll fork those widgets and make the appropriate changes. I’d like to focus on the last few 3d viewer features first. My next goal is making the tool-path operation tween match the line in gcode, right now it’s just a straight point to point, I may look at just adding a clean way to change he state of a line, and instead of adding a new line for the current operation, just change the color of the line. Once we have that working, I can then change the color of the completed lines.

@jlauer I have done a very deep dive on the 3D viewer today, and I think I have a game plan that I want to throw at you for a 30,000ft sanity check.

Right now we actually store 3, maybe 4 copies of the gcode data, translated, within the widget, we have 3 copies within the object.userData property (lines, extraObjects, threeObjs).

I started down the path of attaching a renderObject to the line object in the lines array, but then I realized that thats not the one being rendered, the bufferGeometry ones are.

So, what Im thinking I need to do is move the bufferGeometry stuff up the stack, remove the 2nd set of loops to re-build the bufferGeometry lines all together.

Im thinking that object.userData.lines should become more of a top level property, and each line (as reflected by actual line of gcode path) should have a reference to the line object (bufferGeometry), that we can then use to tween against, and potentially change the color of (i need to research this more).

Does that make sense? Or do you remember some design issue that you ran in to when doing the bufferGeometry conversion?

I think that makes sense. The bufferGeometry was done about 9 months later because it was brand new to Three.js. So I just left the original stuff and added on the bufferGeometry. It could be worth rebuilding it. You could also try to not store the Gcode line since it’s redundant and I don’t think it’s really used again other than in inspect mode. You could just know what the Gcode line is and ask the Gcode widget via pubsub to give you the line if you need it. That could reduce RAM usage. The thing is, though, on a 10MB Gcode file, that’s not very much RAM to use 20MB if you have double storage. The larger problem with RAM just seems to be Three.js overall.

@jlauer cool. I observed something interesting with threejs. I attached the userdata property of the non-buffer line to the buffer line object, doing that had a 5-15fps impact on overall fps.

Meaning it made it worse or better?

Made it worse. Seems like attaching too much to threejs objects is detrimental

I’ve made huge progress in refactoring the gcode object creation stuff, but now im stuck having to completely refactor createGlow. Not a huge deal, but converting bufferGeometry back to geometry actually poops on straight lines with an error inside the threejs code itself. Its a known issue, without any resolution in the pipeline. I think the easiest thing will be for me to refactor this the right way, but its just going to take time :slight_smile: https://github.com/dchote/widget-3dviewer/commit/0e5dc84ecad81b5a8cbccd622ad61af7a655baee

Wow, so you’re saying the newest version of Three.js has a bug in drawing lines? Or just the way I/we were drawing lines in the 3D viewer? What’s interesting is I always thought it was odd you couldn’t draw thicker lines in Three.js. Did they maybe finally fix that?

@jlauer it draws lines fine, the issue is converting buffergeometry back to geometry using their official helper method, raises an array error due to a straight line not having faces.

What if you just cheat and store start/end xyz positions in userData? Also, I was never all that happy with my cylinder rendering code to generate a “glow” because it was generally too small or too big. I never really thought of a better way to hilite, but maybe there are some better helpers in the newer Three.js. Is there actually a glow texture that could get added? Or a line thickness finally exists? Drawing a cylinder is kinda heavy cuz it’s a ton of triangles, but it was an easy helper function to use.

@jlauer good points. I am already planning on changing the line highlight logic to use a copy of the entire geometry for both tweening and inspect, maybe a slightly different highlight approach would be better.

I may take a look at how this looks when dropped in place https://github.com/spite/THREE.MeshLine/blob/master/README.md

Whoah. That’s a sexy looking line. Good find. That example of the head they rendered is gorgeous. If we could get Gcode to look like that, that’s almost game changer looking. I always wonder why Fusion 360 looks so nice and it’s as if they make lines using a similar technique to that Three.MeshLine.

Hmm. It does look like that Three.MeshLine uses triangles to render the lines, so that would be really heavy for the main Gcode rendering. It could, however, work great for highlighting lines. There’s also the notion of after the 3D viewer is at rest for a second or two it does a 2nd rendering of the sexy lines, but when animating it does the basic lines. Fusion 360 does that when you’re panning/rotating and then the nicer rendering jumps in a bit later.

@Daniel_Chote there is a bug in the parsing code, also in the original, whereby if

  1. an M command is on a line by itself and
  2. subsequent coordinates are not supplied with a command

the M command gets accepted as lastargs and the associated cmd property gets prepended to all subsequent coordinates until the next proper command is received.

the parsing code is overriden in grbl but after some bug-chasing the following check fixes it (in parseLine)

// don’t save if saw a comment
if (!args.isComment && args.cmd && args.cmd.substring(0, 1).toLowerCase() != “m”) { this.lastArgs = args; }