LineGlyphRepresentation to connect widget handles

[PaulHax]

Not sure we want to burden the repo with this niche, possibly duplicate code, but tossing this out there.

Context

I wanted to click on a segment of the PolyLineWidget and insert a handle in the middle of the line.
https://discourse.vtk.org/t/picking-tube-between-points-of-polylinewidget/12154

Results

Ran with @finetjul suggestion to use a Glyph mapper with cylanders to connect the points of a line. Can get the index of the cylander from WidgetManager
const insertHandleIndex = widgetManager.getSelections()[0].getProperties().compositeID + 1;

Using in VolView
Kitware/VolView#396

Changes

Adds a WidgetRepresentation based on PolyLineRepresentation. Adds example.

• Documentation and TypeScript definitions were updated to match those changes

PR and Code Checklist

• semantic-release commit messages
• Run npm run reformat to have correctly formatted code

Testing

• This change adds or fixes unit tests
• Tested environment:
  • vtk.js:
  • OS:
  • Browser:

[finetjul]

why not derive from vtkGlyphRepresentation ?

I'm not sure about the SegmentedLineRepresentation. How about LineGlyphRepresentation ?

[PaulHax]

LineGlyphRepresentation makes sense.

I did not see how GlyphRepresentation's polydata from state mixins code helped. I would have needed to override them all and repeat the points iteration in each. https://github.com/Kitware/vtk-js/pull/2899/files#diff-a7d2b7d96e3c0ce1c14f718829973230f2e3ee06fd6542c28dc6bc39d684475eR115-R139

Did I miss some nice feature GlyphRepresntation would have helped with?

[finetjul]

You indeed would have had to overwrite scale3 and direction. I think the origin could have stayed as is. The origin of the cylinder glyph would have had to be at the start of the segment instead of its middle.
The overrides could then have been passed as initialValues of the vtkGlyphRepresentation.extend() constructor. Of course you would have had also to override hasMixin() to force it to return true even if the states do not hold them.

I do not think it's a problem to repeat the point iteration in each mixin function, it does not change the order of magnitude. Each mixin are small enough to be readable.

I've been thinking that it would be nice if your polyline had "joints" between each segment. This could be done by adding spheres (of diameter the same as the line thickness) at each point handle. You would need however 2 glyphmappers though.

[PaulHax]

Ah, setting the center on the cylander glyph means we don't have to compute the center of the segments. Good tip.

If there was a 1 to 1 state mixin to PolyData array relationship, GlyphRepresentation seems helpful. In this case, OriginMixin makes 3 arrays, (position, orientation, scale.)

Regarding joints, should we keep this simple and ask the using Widgets to use vtkSphereHandleRepresentation for them? That is the original goal for this, to have pickable segments between handles.

[finetjul]

If there was a 1 to 1 state mixin to PolyData array relationship, GlyphRepresentation seems helpful. In this case, OriginMixin makes 3 arrays, (position, orientation, scale.)

Where did you see that OriginMixin makes 3 arrays ?

Regarding joints, should we keep this simple and ask the using Widgets to use vtkSphereHandleRepresentation for them? That is the original goal for this, to have pickable segments between handles.

Good idea, can you update your example to demonstrate that, that will make the screenshot more appealing.

[PaulHax]

Incopreated finetjul's GlyphRepresentation rewrite from here
3a9c044

Added sphere joints to the example.

[finetjul]

LGTM