Set extrusionColor for different extrusion types (wall/infill/etc)

[remcoder]

Slicers produce different 'types' of extrusion, or rather, these are generated by different subprocesses of the slicing process.

For instance, perimeters are generated first after which the infill is generated. It is possibly to have the slicer output metadata (formatted as GCODE comments) to mark the different types of extrusion.

This enhancement discusses the options for rendering the different types with different colors.

As a strawman consider the following pseudo-code:

const colorInfo = [{
      'blockStart': ';TYPE:WALL-OUTER',
      'blockEnd': \;TYPE:*+\,
      'color': 'blue'
  }];

const preview = GCodePreview.init({
      canvas: document.querySelector('canvas'),
      extrusionColor: colorInfo
  });
  

note that coloring by linenumber is a different issue (#120 )

[sophiedeziel]

Could colorInfo also be an array for different types?

[remcoder]

But it is ;-)

[remcoder]

I think this is outdated now that we already have multi-color previews for gcodes with tool switching. I see color coding as a single dimension axis so I propose to introduce mode switching to change from multi-tool to line type visualization.

Api approach 1: separate mode param

One approach could be just to add a specific mode param which causes the extrusionColor param to be interpreted differently. For example:

For visualizing multi-color / multi-material:

mode: 'multiTool', // default, so optional
extrusionColor: ['red', 'green', 'blue'] // color T0 as red, T1 as green , T2 as blue

And for visualizing lines types:

mode: 'lineType',
extrusionColor: {
 'perimeter': 'red',
 'infill': 'green',
 'overhang': 'blue' 
}

This is slightly awkward because the type of the extrusionColor param changes depending on the value for the mode param. Although possible, it will lead to awkward code here and there.

[remcoder]

Api Approach 2

We might want to avoid having one param determine how another param is interpreted by extending the extrusionColor value to more descriptive object. This leads to:

2a

extrusionColor: {
  mode: 'multiTool',
  colors: {
   t0: 'red',
   t1: 'green',
   t3: 'blue' 
}

extrusionColor: {
  mode: 'lineType',
  colors: {
   perimeter: 'red',
   infill: 'green',
   overhang: 'blue' 
}

or

2b

extrusionColor: new MultiToolPalette ({
 t0: 'red',
 t1: 'green',
 t3: 'blue' 
})

extrusionColor: new LineTypePalette ({
 perimeter: 'red',
 infill: 'green',
 overhang: 'blue' 
})

The underlying code will use instanceof to determine the instance type and therefore which mode is activated.

The latter has less strings and should be little less error-prone in a non-ts conext