Initial experiment with #20

[philipbelesky]

This all seemed simple enough in terms of code implementation, although there is a slightly strange behavior where the setting seems to 'persist' in the output mesh. If the toggle is set before the definition is executed, the resulting mesh will either be colored or 'bare' as expected. However, changing the setting subsequently will not then change the result despite the fact the correct code path is being executed for the toggle. Is there some behavior, or interaction with the scheduler, which would explain why the output mesh 'remembers' its previous vertex colors? As far as I can tell, the lookup table definitely isn't being employed.

The change in behavior in Core.vs and the component file is pretty straightforward now given the only options are basically on/off. If additional color options are added it would probably benefit from a better abstraction to map between the set option and, the calculations needed to identify vertex colors.

Anyway, let me know if you think the context menu approach is useful, or if #20 should be abandoned in favour of dedicated components / a standard parameter / something else.

[mariuszhermansdorfer]

You need to clear the vertex color list when the boolean changes like this

As long as the number of faces in the mesh remains the same, I only replace individual vertices to keep things snappy. Resizing the mesh with one of the sliders fires up a new Mesh() call, clearing everything else in the process.

Also, the lookupTable, once computed, remains in memory. You could try resetting this one when changing the option in the right click menu.

[philipbelesky]

Have updated with the mesh clear function and tested with a live setup. I've held off on clearing the lookup table as I suspect the implementation of other color options, like #13, would affect this and so might be best tackled at the same time.