use dashed arrows for component vectors

[pixelzoom]

This was explored a bit in #84 (branch: dashedComponent), but there was no specific issue for this. According to @ariel-phet, this is a "must have".

[pixelzoom]

RootVectorNode(a class that is specific to vector-addition) is the base class for drawing a vector and its labels. Adding support for dashed component vectors involves adding an option like {string} arrowType: 'solid'|'dashed'. If we use common code, the arrowType values would correspond to ArrowNode (solid) and LineArrowNode (dashed).

I took a pass at this, and ran into many non-trivial problems:

• ArrowNode and LineNode have different APIs (different options, different methods), making it difficult to switch between arrowType.

• LineNode doesn't support zero-magnitude vectors, which are present through the sim. This support would need to be added, currently blocked by phetsims/scenery-phet#532.

• LineNode doesn't support a solid arrow head. Adding this support will be a nontrivial project. Here's what using LineNode currently looks like:

• When components fall on the axes, they look awful, and LineNode has no way to "fill in" the gaps in the dashed tail.

• Things get weird when components overlap. For example:

• The sim uses ArrowNode.shape to dilate touchArea. No such field exists for LineNode, and it cannot exist because LineNode can't be drawn using 1 Shape. In RootVectorNode, this would need to be short-circuited for component vectors, which is probably OK since they are not interactive:

      if ( rootVector.magnitude > 0  ) {
        // Make the arrow easier to grab
        this.arrowNode.mouseArea = this.arrowNode.shape.getOffsetShape( ARROW_MOUSEAREA_OFFSET );
      }

[pixelzoom]

@ariel-phet @arouinfar @kathy-phet Based on the experience in #177 (comment), we have 3 choices:

(1) Leave as is, with solid components.
(2) Modify LineArrowNode (and probably ArrowNode) to support this sim's needs.
(3) Create a new type of arrow to support this sim's needs.

@ariel-phet has previously indicated that (1) is not an option that he's willing to accept.

Options (2) and (3) are both a significant amount of work, and will certainly delay the start of Natural Selection. It's not clear what "this sim's needs" are, so the current suggestion of "do something and we'll tweak it" is not a path forward. If you'd like to pursue options (2) or (3), please provide mockups that show how you'd like component vectors to look for the "component style" options, and in situations where components do and do not overlap.

[pixelzoom]

Another option:

(4) Modify ArrowNode to support dashed tail, described as a single Shape, with continued support for all Path options (fill, stroke, etc.)

This is my current favorite option. Adding a solid head to LineArrowNode is contrary to the original purpose (and name) of that node, and I'd rather not deal with modifying it, and switching between ArrowNode and LineNode. How I approach this option depends on how you want to treat gaps in the dash when vectors overlap each other, or overlap the axes. So mockups are still needed.

[pixelzoom]

Discussed with @ariel-phet via Zoom. We're going to proceed with option (4), adding tailDash feature to ArrowNode. This will be generally useful in other future sims. Since @ariel-phet is confident that we won't need to be anything about filling spaces in the dash, I will proceed without mockups.

Notes:

• tailDash value will be similar to SCENERY/Line lineDash, e.g. tailDash: [ 3, 2 ]
• dash will be constructed from tail to tip, so that any partial dash (or space) is near the tip
• component vectors will be fully opaque, so I'll convert color palettes so that the hues look the same

Work on ArrowNode will be done in phetsims/scenery-phet#533.

[pixelzoom]

After hours of trying, adding a tailDash option to ArrowNode proved to be not feasible at this time, see phetsims/scenery-phet#533. So I implemented a sim-specific solution, that meets only the needs of this sim. See DashedArrowNode.

(EDIT: In phetsims/scenery-phet#533 (comment), @ariel-phet said: I actually think a sim specific implementation is totally appropriate currently. We can wait until some recalcitrant designer (ie me) demands dashed arrows in another sim before making a general solution. I think what you will have done in Vector Addition will be informative to that general solution when it becomes desired.)

The next step is to refined the tailDash pattern and colors for component vectors.

The tailDash is currently [ 6, 4 ] and lives in VectorAdditionConstants.

Colors are all opaque, and live in VectorAdditionColors -- look for "componentFill" and "sumComponentFill".

@ariel-phet @arouinfar please review in master and let me know what you'd like to change.

[pixelzoom]

I forgot to mention, there's one wart that I'm planning to address. The dashed tail currently extends into the vector head, and is visible at the tip, so we don't have a nice sharp point on the tip. E.g.:

[pixelzoom]

In the above commit, the tail length is adjusted so that it doesn't overlap the tip. See example screenshot below, compare to #177 (comment).

[pixelzoom]

Hmm... e3528b9 broke the Explore 2D screen icon, and a couple of the Components icons.

[pixelzoom]

Issues mentioned in #177 (comment) are fixed in the above commit.

[pixelzoom]

@ariel-phet and I (via Zoom) discussed some tweaks to the dash and colors. Before making those changes, I've published 1.0.0-dev.16.

[ariel-phet]

Removing my assignment until next iteration is ready to discuss

[arouinfar]

I'll also unassign myself until the changes mentioned in #177 (comment) are ready for review.

[pixelzoom]

Tail dash has been adjusted. Colors will be handled in #184.

@arouinfar and @ariel-phet please review this issue for:

• how the dashed arrows are working for component vectors
• whether [6,3] is an acceptable dash pattern

If those things are good, then we can close this issue, and address colors in #184.

[ariel-phet]

Personally, I think this is all looking quite good, we do need to dial in the colors (as will be done in #184), but all this work feels correct to me.

[arouinfar]

The dashed components are looking good to me, thanks @pixelzoom @ariel-phet! The dash pattern and relative component/axis weight looks good, even for the projected components.