Feature request: visualize extrusion

[3d-gussner]

Do you think it could be possible to visualize an extrusion? Here an idea with magnifying x10 Constant extruder move while hotend begins slow and get faster and slow again.

[vintagepc]

As in actually drawing the printed plastic? I've thought about it a bit and I don't see why it would not be possible. We know the required numerical values so it would likely not be too hard to draw something representing an actual object being formed.

[vintagepc]

(I'm currently finishing up the initial fancy graphics visualization, I may take a peek at getting something rudimentary in as a part of that.)

[3d-gussner]

Just run your fancy graphics and looks awesome ... (bit too much for me) but someone like content team would love that.

Like the details!!! Like that the fins of the hotend fan start to turn when temp is reached.

One minor issue with the Pinda the red light is on as long it doesn't trigger. Another issue i ran into Bed is gray while sheet is black.

Normal printer has bed black with Do not print and the markings while textured sheet is black with small note front right.

[vintagepc]

You'll like the --lite option instead of --fancy then, that only draws the minimal components of interest that actually change/move :smile:

[3d-gussner]

Also during 1st layer cal you can see the pinda triggering after 0-150/175ish ... wow

[vintagepc]

I fixed the PINDA and tweaked the bed textures :)

[vintagepc]

I bashed a tentative idea together just now. Crude, but it's a proof-of-concept:

[vintagepc]

Bit of a milestone today... it printed its first benchy! Sure, it's got some major stringing... :rofl:

[3d-gussner]

Wet filament I guess... That's why it is so stringy

[vintagepc]

Took me a while to figure out how to dry virtual filament, but I think I managed to get my GPU hot enough:

Now I just need to get some nicer filament colours. This stuff is disappointingly 2d even when extruded.

[vintagepc]

I pushed up my branch if anyone wants to have a play. It's still basic lines but at some point it would be nice to actually draw with some volume to them for better lighting (though because of the way extrusion works, I suspect it may have an appreciable triangle count for larger prints)

https://github.com/vintagepc/MK3SIM/tree/114-extrusion-visualization

[vintagepc]

Oh man... I'm having flashbacks to linear algebra class. Making progress on the lighting though. We just need to calculate the lighting normals for each vertex (GL can't handle figuring them out on its own because it's a line, not a plane).

Even the janky test I did doesn't look half bad though. The tricky bit is going to be finding the nearest point on the layer below it so that sloped surfaces look right. Currently I just assume everything is a vertical plane.

[vintagepc]

OK - I'm pretty happy with this in its current state. I think I'm going to merge it in and leave it for a future task to improve the shading and geometry; that last part is necessary to get good extrusion width visualization. I think I've done as much as I can do with basic lines without doing a bunch of complex math that gets invalidated when changing from lines to triangle mesh primitives.

To get to better extrusions it looks like it might make more sense to consider a geometry shader to turn the lines into "pipes" of the correct dimensions, rather than front-loading the computations and buffers in system memory. https://learnopengl.com/Advanced-OpenGL/Geometry-Shader

[vintagepc]

The other possibility is a vertex shader that computes normals on the fly. Specifically, the post here: https://community.khronos.org/t/illuminating-gl-lines/44999/4

t would be good idea to compute a view-dependent normal in the vertex shader on the fly. Instead of providing a normal to the vertexshader, provide it with the direction of the line or line segment (at the position of the vertex). Then, in the vertex shader compute a normal which points into the direction of the viewer but still remains to be orthogonal to the provided direction (compute V then orthogonalize it to D). This way you´re effectivly emulating a thin cylinder which should give good lighting.

[3d-gussner]

Just merged to the latest commit and have an issue I cannot say if that it was there before or not: why do i get [build] make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.

[main] Building folder: TEST_MK3SIM 
[build] Starting build
[proc] Executing command: /usr/bin/cmake --build /home/gussner/Data/Github/MK3SIM/TEST_MK3SIM/build --config Debug --target all -- -j 4
[build] [  5%] Built target tinyobjloader
[build] [  8%] Performing build step for 'simavr'
[build] make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
[build] LD obj-x86_64-linux-gnu/run_avr.elf
[build] [ 10%] No install step for 'simavr'
[build] [ 13%] Completed 'simavr'
[build] [ 27%] Built target simavr
[build] Scanning dependencies of target Einsy
[build] [ 29%] Building CXX object CMakeFiles/Einsy.dir/Einsy.cpp.o
[build] [ 32%] Linking CXX executable Einsy
[build] [100%] Built target Einsy
[build] Build finished with exit code 0

[vintagepc]

Nothing to worry about - just means that make step won't use multiple CPUs to speed up compiling I think it's a hiccup of the way we nest the simAVR build as part of the main build. Edit: To clarify - I think what may be happening is the parent CMAKE is already trying to do multithreaded build, which causes this when the subtask attempts to do a parallel build as a subtask of an already parallel task.

[3d-gussner]

Nozzle cam doesn't work for me or is it only with --lite version something? Would it be possible to get a "3d cube" like in fusion? As soon I try to rotate/pan the fancy model it is all over the place. Or a home key for get the fancy model in a default view.

[vintagepc]

hmm... I'll look into the nozzle cam not working, I thought I had it (did test it in lite mode) but it's possible I fudged something up because we don't load some of the assets in lite mode - that might throw off the coordinate calculations.

I filed #123 for the view control. As a temporary measure I've found that it helps to zoom back out before trying to adjust the view with pan/rotate. It's like it doesn't account for the zoom factor and reduce the amount it needs to move.

[3d-gussner]

It would be great if we could also simulate the extrusion width like gcode.ws or PrusaSlicer 2.3-devel does.

@DRracer quote: yes please do and make it work after 0.1mm segments - I'm sure we are causing the ghosting effect in the FW in the acceleration segments. Be sure to add a multiplier to visualize the thickness e.g. 10x thicker so that we can see on single lines if the FW is computing the acceleration and deceleration correctly

[3d-gussner]

Here a link https://github.com/hudbrog/gCodeViewer

[vintagepc]

Yes, that's the entire reason this issue is still open. I definitely want to do it and the time is probably soon now that most other major functional development has slowed.

It's not a straightforward openGL thing to draw a "pipe" to create a 3d line. I think the best option for doing this is a geometry shader of some kind to turn raw line segments into a 3D entity.

[DRracer]

@vintagepc as a first approach, even if you do it like PrusaSlicer - draw a 8-triangle piece of tube simulating the mass of filament being extracted - would greatly help. We do not need to render millions of triangles for debugging, we need just a few.

[vintagepc]

@DRracer I'll see what I can do.... :+1: :smile:

[vintagepc]

oof.. my head hurts from the geometry calculations for this. gcode.ws doesn't have a functional example, it only uses line widths. But linewidths>1 pixel are not guaranteed in openGL, and of course we want "virtual mm" not pixels. So I need to offset the line in the XY plane.

Seems trivial... but it's not.

I tried poking through the PS gcode but there's too much noise. Perhaps someone familiar with the code could point me to the functions of interest that turn gcode line segments into square tubes.

[vintagepc]

https://github.com/linas/glextrusion might be useful. See also comments on https://stackoverflow.com/questions/11193524/create-tube-along-polyline-path-in-opengl

https://github.com/MicBosi/VisualizationLibrary

[DRracer]

@vintagepc if I had to solve this problem, I'd take the line segment as a normal vector for planes at each of its ends. In these planes I'd compute the positions of 4 points which will serve as the box/cylinder's base/top. And then just render the 8 triangles inbetween... I know there will be cracks - i.e. the cylinders/boxes's points will not follow each other in case of turn segments etc. But for our purposes this is enough ... tbh may be even better than a smooth surface, because we would like to find the inconsistencies of extrusion if there are any.

[vintagepc]

Yes - though I'm trying to find a way to do a continuous tesselation rather than having to start/stop triangle strips for every extrusion. I'd actually gotten something working with an existing pipe extrusion sample, but it didn't handle the winding changes well; you'd get places where the default normal would flip to the other side of the polyline and the exrusion would go hourglass-shaped.

I have no idea as to the performance penalty, hopefully this implementation won't run like crap.

[vintagepc]

Making progress... Now I just need to sort out the width calculations based on E movements...

[vintagepc]

Starting to look pretty good!

Remaining TODOs:

• [ ] Known issue with corners and very short extrusions with high E impulses causing spikes.
• [x] Variable width co-linear extrusions are not shown; they're treated as a single extrusion. (just need to include E rate as part of the co-linearity calculation to detect an E volume change mid-line.
• [ ] No automatic Z height detection. TBD, will have to make a guess based on previous layer Z. Currently hard-coded at 0.2mm
• [ ] No idea how this will perform with large prints in terms of performance

[DRracer]

TODO issue #2 is the most important one - ideally chop the single extrusion segment into 0.1mm slices and visualize extrusion thickness in each piece separately. With enough scale (probably including some coloring) this will enable us to see, if the firmware stepping is correct. If yes, the vertical fine artefacts must be caused by the TMC and or HW.

If caused by TMC, we could simulate its behavior and tweak the timing in FW in such a way, that the print surface gets improved.

[vintagepc]

That's one way; I'd planned to just add the E distance as a second triangle area calculation to determine if the volume:distance was changing. I don't think it'd be too hard to try both to see which is better.

Re: VFAs, I assume you're referring to the salmon-skin texture we see on the MK3 and discussed in that 50-page megathread? From what I recall the origin was concluded to be non-uniformity of the motor's step cycle; I can personally confirm they do go away if you change the motor. (but of course that doesn't mean it might not be possible to configure the driver in a way to mitigate it with the stock motors).

I agree it would be interesting to see if the problem exists here (or, if not) whether we could simulate and reproduce it by introducing a cyclic non-uniformity in the simulated motor.

[DRracer]

@vintagepc EXACTLY ... if we even simulate a bad motor and see similar salmon-skin effect in the simulation, we can start preparing counter measures.

[vintagepc]

That would be icing on a cake indeed!

Somewhat related: Funnily enough I've started seeing one on the E-cycle again on my own printer; I suspect it's because the 3d-printed gear in my extruder is actually flexing and off-center.... One of these days I'll get around to reprinting it out of ABS or something less flexible...

[DRracer]

I'm really looking forward to this visualization, there have been so many theories around, but no-one (AFAIK) ever tried to verify, that the FW is sending the pulses correctly. If we can rule out FW, we may start tackling the TMC and the potentially bad motors. Moreover - with LA15, the acceleration artefacts are stronger - that must be visible as well.

[vintagepc]

Yes, it's easy to latch on to a plausible explanation with relatively minimal (but highly validated) supporting evidence. A prime example was the common adage that the MK3's Einsy was "overloaded" and could not handle higher X/Y stepping rates and result in lost steps. And we know how that turned out with https://github.com/prusa3d/Prusa-Firmware/pull/2792 completely invalidating that. (I'm rocking 0.9 degree steppers at the default 16 XY microsteps now)

[DRracer]

There is also a video showing a motor from MINI being driven by a Duet board - and while the motor is purring in the MINI, it is rotating absolutely smoothly with the Duet board ... we are doing something wrong and I'd love to find out what it is.

[vintagepc]

Fascinating!

I think we'll be able to make good use of @wavexx 's colour interpolation to colour by E-width...

[vintagepc]

well that was .... interesting. I think we may be hitting the discretization limit of the motion tracking though. And my framerate absolutely tanked after a single layer of a 25x25 square :rofl:

[DRracer]

@vintagepc great progress - make longer segments (or configurable length of individual segments). For this to work we don't need a 20cm high object, a single line with acceleration and deceleration would be enough - just make sure the extrusion per millimeter is exact. I see some repeating patterns even now, but that's probably too early to judge.

[vintagepc]

So after rewriting much of the print visualizer to work in absolute motor step units rather than floats, it turns out that pattern is not discretization of the positions/float error on my part. It's the actual stepper resolution we're seeing:

fERate:119.000000 dXY:3.000000 dE:357
fERate:178.500000 dXY:2.000000 dE:357
fERate:119.000000 dXY:3.000000 dE:357
fERate:178.500000 dXY:2.000000 dE:357

In other words, sometimes X gets in 3 steps, other times 2 for the same E volume.

Arbitrary musings on the subject:

That actually makes a lot of sense in the context of higher resolution steppers reducing VFAs (assuming this is the cause) since with a higher steps/mm you inherently get a better interleaving of operations.

The physics of the molten plastic helps smooth this out in reality, but if the pattern is regular enough or there are clumps of higher-volume steps then of course you're going to see it in the right lighting conditions.

In theory one could mitigate this more with advanced planning - you could vary the travel speed (within a small window so as not to invalidate LA and molten plastic physics) such that you get even interleaving of E steps to X/Y steps....

I'm cleaning up the code a bit and getting ready to push it up as a preview. High-res E mode is enabled with a new command line argument, --highres-extrusion. (Off by default, it just averages the entire E volume over the total length of the segment otherwise.)

It occurs to me that this sim can also potentially be useful for investigating if the same step handling is related to the infamous 602 "inconsistent extrusion".

Current TODOs:

• Z layer height detection for layer heights other than 0.2. I think this will be a wishlist item, MBL is going to mess with trying to get this straight from the Z value at which we're extruding and at this level we don't have access to the raw gcode to ID it from the settings.
• Colour-based width visualization.
• Fix positioning of the print in XY, it's off slightly.

[wavexx]

Yeah, these are implicit with bresenham. The "correctly sampled" axis is always the fastest moving during the current move.

You can simulate the effect of higher sampling rates using higher microstep counts now that they work correctly (essentially giving you the same effect as ADAPTIVE_STEP_SMOOTHING) which will reduce the difference between the effective and real pulse speed.

I didn't see the same effect you get though by actually going with a 0.9 stepper :(

[vintagepc]

I didn't see the same effect you get though by actually going with a 0.9 stepper :(

Interesting... what motors did you go with?

[wavexx]

On Sat, Sep 26 2020, vintagepc wrote:

I didn't see the same effect you get though by actually going with a 0.9 stepper :(

Interesting... what motors did you go with?

I still kept stock 1.8 everywhere for greater torque/speed. I was using a 0.9 (an LDO coolstep mounted on a BMG) on the extruder for a while, but I also reverted that a month ago to the stock BMG with a random 1.8 (so from 824 to 412 e-steps) to get greater acceleration when I noticed that retractions were a limiting factor. E-jerk is also something I need to retest, but I couldn't get beyond 3.5 with the old setup and that is also to consider as it's a big limit in speed when using LA.

I was never able so far to get my hands on a low-inductance motor like the fabled "Moons" or the newer LDO ones...

[leptun]

Why would you want a low inductance motor? Doesn’t it have lower torque (especially at speed)? I also noticed that lower inductance motors play better with the tmc2209 drivers compared to the stock prusa ones, but it’s still not great.

[wavexx]

The idea was really to get rid of the banding ignoring everything else. It's definitely not a choice I would do today ;)

[vintagepc]

Interesting. I've got my 0.9s on X/Y. Stock firmware, no changes to limits/speeds. I have mostly run in power mode but as of the "high speed deceleration fix" I've done a few prints in stealth mode and also no longer had the layer shifting I observed there before. But it's a small sample size so not conclusive.

[wavexx]

Now that we fixed the deceleration bug we can go pretty fast, but acceleration (torque) is everything to actually save some printing time. I'll plop this here:

https://www.thregr.org/~wavexx/tmp/VID_20200920_191805_r.mp4

[vintagepc]

those poor stepper drivers :rofl:

Colour-by-width is live!

[vintagepc]

I've pushed it all up to https://github.com/vintagepc/MK404/tree/114-Extrusion-visualization-take-2

I think the only thing still missing is the Z layer height detection.

[vintagepc]

Added - Extreme MBL is likely to mess with it but it appears to get a reasonable guess of the layer Z height based on the segment average Z.

Also set the minimum segment size to 0.4mm for non-highres mode.

I'd say have a play with it and let me know if it meets your needs. Line drawing is still the default, but the new features can be enabled with:

  --3d-extrusion
     Visualize with 3D extrusions (can be GPU intensive for large prints)

   --colour-extrusion
     Colours extrusion by width (for advanced step/extrusion debugging.

   --highres-extrusion
     Enables high accuracy extrusion simulation. Creates a LOT of triangles
     , do not use for large prints!