Travel lines are clipped

[remcoder]

Often there are travel moves above the topmost extrusion layer. Due to the clipping planes, of which the max is initialized at the topmost extrusion layer, those travel lines are clipped.

      x--------x  Travel move (INVISIBLE due to clipping)
----------------  clipping plane
================  Layer n (topmost extrusion layer)
================  Layer n-1
================  Layer n-2

[sophiedeziel]

It's an interesting challenge to solve.

The clipping mask is needed to hide travel lines of layers above the upper limit, but we want lines that start on a visible layer to show in full.

A solution could be to detect such travel paths that should be visible and have some parts hidden and render them independently without the clipping mask. I don't remember if travel lines are rendered in batches like the extrusion paths. If that's the case, we'd have to exclude them from the batch.

I think fixing this would be most helpful when z-hop is enabled on the slicer. Travels would systematically be "lost" on the last layer.

Maybe clipping was a good idea for performance and ease of implementation, maybe we need to reconsider the approach?

I'm also thinking about an hybrid approach: clipping could be used for the first x frames that would offer a fast initial draw, followed by an actual render of the only subset of visible layers, without clipping. Some sort of delay would allow for changing the height and the result would remain smooth. We'd get the best of both worlds. Kind of when video games have a low-rez render first and we see accuracy and details on the next frames. Of course, on the first frames, this problem would still show. But that would only be for the first couple of frames and it would be then visible when the rendering strategy changes for the more accurate one.

[remcoder]

I hadn't even thought about z-hops. Good one.

Use cases

I suggest we first define the edge cases and what the user would like to see:

• If no min/max layers are set, then nothing should be clipped This is the only requirement I'm sure of ;-)

  • this is already interesting bc in the current implementation the min/max layers are always defined, defaulting to the top and bottom. Meaning that we never see those last travel moves above the print. I think it could be quite valuable to be able to see them!

• if a max layer is defined, do we then want to see z-hopping travel moves on the top layer? My gut feeling would say yes although a strict mathematical implementation of the max layer is not only defensible, from a purist stand-point it has it's own value.

• What about single-layer mode? In single layer mode it would be very unnatural to not see the travel moves from extrusion to extrusion.

• But this is a lib. So the consumer app needs to have control and we should stay away from being too smart. Although I do think we should be a little opinionated (in everything in this lib).

• And then there is non-planar mode... Although we could define that problem away by saying non-planar doesn't have layers so layer-based clipping is not really a thing then. Although in practise, I think there would still be layers, just not exactly.. planar.. :D

It's all about layers

So this whole thing again challenges our thinking about the most fundamental thing in 3d printing: layers! ;-) I we solve this well, we should have a very solid foundation! 🙌🏻

I'm thinking now that every extrusion and every travel move needs to have an associated layerIndex. The slicer actually injects layer change markers and I expect it will do that too for non-planar. (we need confirmation about this)

(The layer problem is actually not one that has a single solution that works for everyone. We might want to consider making this logic customizable. As in: we can have basically 2 algorithms available to define the layers one based on metadata and one based on the old logic. This will have a cost in terms of complexity tho)

Next steps

• I suggest that at least we extend the parser to read and store this info. Agree?
• And I also suggest to first fix the most basic version of the problem: initially no min/max should be set and we should see the whole thing, with travel lines way above the print. Right?

[sophiedeziel]

I suggest that at least we extend the parser to read and store this info. Agree?

Yes, 100%. We can start with a basic implementation first. We talked about this many times in the past, gcode metatada in the form of comments is a bit different from slicer to slicer and we could have dictionaries and stuff. We don't absolutely need all of this and to over-engineer it as long as we can iterate on it.

And I also suggest to first fix the most basic version of the problem: initially no min/max should be set and we should see the whole thing, with travel lines way above the print. Right?

Oh, I did not realize the clipping mask was there the whole time! Yes, 100%! This case is the most important and the easiest to fix.

[sophiedeziel]

And then there is non-planar mode... Although we could define that problem away by saying non-planar doesn't have layers so layer-based clipping is not really a thing then. Although in practise, I think there would still be layers, just not exactly.. planar.. :D

Agreed with that case. We can already detect that and we have a tolerance algorithm.

Section Analysis can be useful. It's clipping, but on the plane you want! Technically, our layers implementation is a section analysis on a plane parallel to the bed 🤷🏻 😆

Another tool could be to select a subset of gcode line numbers instead of layers.

[remcoder]

tl;dr on hold until #280 is implemented