UI.Highlihght class?

[originalfoo]

Suggestion: Split out the code that highlights nodes/segments/lanes/whatever in to a separate class?

So we could have things like:

// highlight selection candidates
Highlight.SuggestNode(...) // eg. could gently pulse a subtle highlight over node
// etc...

// highlight selections
Highlight.Node(...)
Highlight.Segment(...)
Highlight.SegmentEnd(...)
Highlight.Lane(...)

That way we can centralise all the highlight functions rather than duplicating them, and any optimisations can be done centrally.

For example, there might be some benefit to batching the rendering, like, rather than creating new mesh each time for a node highlight, could we create it once and then duplicate it for each highligted node?

Also, we could have central methods to clear all current highlights (or highlights of given type or matching specific criteria, etc).

Later, we could have abstract classes for interacting with networks, so we could have something like:

SomeAbstractNode.Suggest(...) // --> Highlight.SuggestNode(this as NetNode, ...)
SomeAbstractNode.Highlight(...) // --> Highlight.Node(this as NetNode, ...)

[kvakvs]

Nice!
If you don't have time to do actual changes, make a list of things which highlight objects, and I can refactor them out for you - that's the most enjoyable thing for me to do, also can be done on Linux when i have a free minute at work

[originalfoo]

It needs some more ponderance first.

For example, I'm wondering if Highlight is best name fo the class; would it be better called Overlays?

Some examples:

Overlays.SuggestNode(...) // gently pulse a node
Overlays.HoverNode(...) // hover selection overlay
Overlays.SelectNode(...) // static selection overlay

Overlays.Icon(where, what, action) // add an icon

Could such a class handle things like camera view caching (ie. what stuff is currently visible)? It could potentially have stuff like...

Overlays.GetVisibleJunctionNodes() // list of junction nodes in camera view
// etc...

So the various tools would just farm stuff out to the Overlays class - suggest these junction nodes, add icons to these segments, etc... The Overlays class then works out what actually needs to be shown based on what camera is looking at. Also, knowing what camera can see, it could maybe even go so far as to handle mouse interaction (eg. no need to check entire map to see what mouse is hovered if we already have short list of stuff that's in camera view just check that instead)?

[kvakvs]

Don't design megaclasses which do everything.
A cache helper class.
A static class for rendering stuff (or maybe a stateful class if something has to be stored).
A static class for information gathering helpers, like GetVisibleJunctionNodes etc. Again can be a part of a stateful overlay renderer helper class.

Maybe even subdivide duties:

• So a class which only does nodes.
• A class which only does edges (segments).
• A class for lanes maybe as a part of segments renderer (composition with segments class).

For example for Lane Connectors we need to highlight nodes, and lanes. And segments to hover. Then the consumer of this API would create a node renderer, and a lane and segment renderer. Three renderers which all cache their visible lanes, nodes, and segments and can be invoked independently in any order.

[kvakvs]

The rendering can be:

• Render single item overlay
• Render a list of items by their ids or refs (do we need by refs?)
  • List can be maintained in the renderer object, or passed for every frame
• A functional approach: Pass two functions, a filter function over all visible elements, then a render function for each element satisfying the filter.

[originalfoo]

For the cache class, I assume it would just cache all visible nodes/segments (I assume lanes are always part of a segment?) that are applicalbe to any TMPE tool or overlay, even if they might not be relevant. My assumption is that quick built list is better than trying to add all sorts of excessive filtering logic in the cache class; and that way we wouldn't need to invalidate cache just to toggle certain overlays - everything relevant would always be there.

We'd need a toggle to turn it on/off. For example, TMPE toolbar is open but no persistent overlays therefore it should be off to conserve frame rate. If persistent overlays is on, or a tool is active, then it gets enabled.

The cache would be updated whenever camera moves more than certain delta, but ideally also have some de-spamming in there (eg. max 1 cache refresh per X milliseconds) to prevent laggy map scrolling on potato computers.

A functional approach: Pass two functions, a filter function over all visible elements, then a render function for each element satisfying the filter.

Yup, would be good for jitter hot-pathing and branch predication. The filter would be run over the 'view cached' whatever (nodes/segments).