Skip to content

Conversation

althea28
Copy link
Contributor

@althea28 althea28 commented Aug 19, 2025

The aim of this PR is to compare the lane arrows visualisation with PR #370. The implementation of this lane arrow shader is the same as PR #370. The only difference between both PRs is the shader file code, and the color of the arrows moving in the reverse direction.

This shader shows arrows moving in different directions as adjacent lines as per below. This PR is to be compared with PR #370 that show overlapping arrows instead.

Screen.recording.2025-08-20.9.44.20.PM.mp4

@mxgrey mxgrey added this to PMC Board Aug 19, 2025
@github-project-automation github-project-automation bot moved this to Inbox in PMC Board Aug 19, 2025
@mxgrey mxgrey moved this from Inbox to In Review in PMC Board Aug 26, 2025
@luca-della-vedova
Copy link
Member

This has been stuck for some time because of the two different approaches. I propose, to solve it and move forward, can we just make the behavior a parameter (a constant defined in the shader is OK) so that we can have an approach first (perhaps this one?) but if we change our mind can easily change the appearance later?

My proposed parameters would be something like:

float LEFT_ARROW_WIDTH_RATIO = 0.5;
float RIGHT_ARROW_WIDTH_RATIO = 0.5;

Where the value is the percentage of width that the arrow takes, two values of 0.5 will show this behavior, two values of 1.0 will show the overlapping behavior, intermediate values (i.e. > 0.5 but < 1.0) will have partially overlapping behavior.
Then we can easily tune in the future if this show to be misleading

@mxgrey
Copy link
Collaborator

mxgrey commented Aug 29, 2025

@luca-della-vedova I think the consensus from the PMC is that the adjacent-arrow approach in this PR feels better, even if it's potentially a bit misleading. I like your idea of making the arrow size into a parameter if that's feasible.

The main blockers for this PR, which I discussed with @althea28 yesterday in person are the following:

  • We'd like to only show the arrows moving when the lane is hovered or selected, because otherwise it's too much visual activity
  • When the arrows aren't moving, bidirectional lanes should just render without any arrows at all
  • The base color for a lane needs to be based on the nav graph(s) that the lane is associated with. In the current state of the PR, the lane colors are all hard-coded as orange.

@althea28
Copy link
Contributor Author

Noted on the points above! @mxgrey created a branch earlier that edits a system to return the Nav Graph color. I've built on those changes and opened a new PR #378 based on the above discussions.

@mxgrey
Copy link
Collaborator

mxgrey commented Sep 1, 2025

Closing this PR in favor of #378

@mxgrey mxgrey closed this Sep 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Review
Development

Successfully merging this pull request may close these issues.

3 participants