Junction Lane Arrows Editor rework with preview

[kvakvs]

Note to Reviewers

Please use "Ignore whitespace" in ⚙️ menu in the Diff view.

Description and Checklist

State machine editor for junction lane arrows, featuring 3 states: Node selection, Incoming (lane) Selection with hover preview, and Outgoing Selection with hover preview. Replaces the old Lane Arrows GUI.

• State machine class and states defined
• Lane hover feature added to base tool class
• Hovering incoming lane will show outgoing lane connections (white)
• Hovering outgoing segment will highlight all affected segments in that direction
• Clicking outgoing segment will allow all turns to all segments in that direction
• Right click leaves the state and returns to the previous state
• Clicking a node switches straight into Incoming Selection mode
• (On Screen Display with Help and Keyboard Hints #421) Simple On-Screen Display (OSD) implementation to show the current mode and shortcuts
• Clear/reset button, back button (maybe)
• Shader animations to show the lane in/out directions

State Machine visualisation for the editor modes:

Fixes #361
Fixes #368
Updates #33

[originalfoo]

The alignment should ideally be determined a small distance from the node, rather than the angle the road connects to the node. In the second image in OP it's too rotated (from user perspective) IMO.

Would it be possible to just have one button, lane width, over the lane? Then left / right click would cycle through arrows in that direction? For example: A lane is currently right turn only. Left click makes it forward + right. Another left click makes it forward + left. Another left click makes it left turn only. A right click makes it forward + left...

In fact, the button could be invisible as the lane arrow on road will update (and, at later date, I suspect we'll also have lane connector lines visible while hovering a lane arrow as additional source of visual feedback + vital for roads that don't have lane arrow decals).

[kvakvs]

Ok let me explain my flow of thought.

• Since we're editing that end of the segment and not the node, the arrows are displayed on the road and the GUI is rotated in the same direction. If the road was upside down, the GUI would be too upside down.

• Having ground plane GUI stand up and be aligned to the projected screen like it's normal GUI or AR (augmented reality) GUI maybe is not a terrible idea but then we lose the benefit of orientation. I rather see the button rotation as a usability improvement. In general rendering an UI standing vertically is no different from the other pull request using a regular IMGUI window.

• Having user click up to 8 times (2 to the power of 3 directions) to set up the lane is not a good UX. But having a turn sign and 3 smaller buttons (forward, right, left) around it might work.

  • Like so

• Lane width button would be too narrow. Too easy to miss. Having no UI at all will give user no visual clue that something is clickable, not good.

• Reducing the amount of GUI and showing small buttons 1 per lane which then expand into a direction editor is again adding extra clicks, which might be a good UX or not good. I don't like the amount of clicks it takes to edit a segment in this case.

  • Like so
  • or so

• If we go lane connector way, this is too easy to do wrong with terrible UX taking user dozens of clicks to set up. And what if user misses a smaller control and the GUI closes, this will be annoying.

[originalfoo]

Looking at the last image in comment above seems like that would be ideal situation - only one extra click to select a lane, then the three (or fewer, depending on what is possible at junction) buttons appear to set the arrow for that junction. IMO that would be better than showing all the buttons at once, for following reasons:

• Some roads have insane number of lanes or strange layouts, for example:
  • https://steamcommunity.com/sharedfiles/filedetails/?id=1565832628
  • https://steamcommunity.com/sharedfiles/filedetails/?id=1270405359
  • There are more insane roads to test in the wiki
• In some cases there is lots of stuff happening at a junction, for example:
  • Detailing props/trees which might cover the buttons
  • Particularly things like concrete supports for overhead road would likely completely cover buttons if they are not entirely on a road

With the 'show all buttons' approach, it's taking up too much space on the ground increasing the risk that some of those buttons get covered, and for insanely large roads or weird layouts it's going to be confusing working out which buttons relate to which lane.

In terms of finding out what directions are possible at a junction, check the Junction Restrictions tool - I think there's some stuff in there (like the turn on red feature in particular) that has to work out if traffic can go left/right depending on driving direction and other roads connected to segment.

[kvakvs]

I will re-consider this when i return from work.
Small buttons and pop-up per-lane controls sound good.
One thing to note: I will be using a shader which ignores depth buffer and will render through the world geometry.

[originalfoo]

The current lane connector renders through world geometry and that can still sometimes be difficult to use, for example, try lane connecting a node that's directly below a large elevated road. Luckily, with the lane arrow feature it only occurs at junctions which generally don't have stuff over the top of them.

One other option I considered some time ago was a feature that could flatten nearby props/buildings when working on a road, making it easier for the user to see what they are doing. No idea if that is possible though and suspect it would be difficult to implement.

[kvakvs]

With the correct shader it will become a 3d overlay ignoring the world under it.
We do not need to modify any world geometry for it to work, it will be always visible and always clickable.

This Unity3d scene uses this shader for GUI

[kvakvs]

These will be small buttons one per lane
Click on a small button will unfold 3 more control buttons ⬅⬆➡

[originalfoo]

This is exactly the sort of direction I hoped lane arrows would go in. Very much looking forward to testing this once it progresses a bit.

[kvakvs]

There you have it for testing
TODO: It prints error sometimes, there's some check failing in the lane change code (the game)
TODO: Some rare segments invert the lane arrows orientation by 180°, might need correction here
TODO: Detect impossible lane directions, i have texture for them too

[originalfoo]

Regarding the 180° inversion, I think that's a standard thing with segments; they alternate their orientation so that any slight different in road texture edges doesn't create striping pattern. No idea how you would check for that though. There's probably some info on https://cslmodding.info in the networks section.

[originalfoo]

Looks like this PR will fix #368

[kvakvs]

Current lane is highlighted
Changed button graphics
Added detection for impossible turns
If there is only 1 lane, the direction buttons open right away

[originalfoo]

This is starting to look really great!

When a lane is selected, is it possible to highlight connected outgoing lanes with green 'sausage' outline? That would be great visual feedback showing players exactly which outgoing lanes the current lane connects to.

The lane highlighting feature will be super useful for adding to several other TMPE features in future PRs.

[krzychu124]

@kvakvs
I am using this approach to load shaders. Here is the code I use.
I've made simple Unity Editor extension:
(drop file to /Assets/Editor folder to get it working - you should see Example menu in Unity Editor)

public class Bundler : MonoBehaviour {
#if UNITY_EDITOR
    [UnityEditor.MenuItem("Example/Build Asset Bundles Using BuildMap")]
    static void BuildMapABs() {
        UnityEditor.AssetBundleBuild[] buildMap = new UnityEditor.AssetBundleBuild[1];
        buildMap[0].assetBundleName = "CustomShaders"; //bundle name, obviously
        string[] shaderAssets = new string[1];
        shaderAssets[0] = "Assets/CustomShaders/CustomShaderMin.shader";// path to asset source
        buildMap[0].assetNames = shaderAssets;
        UnityEditor.BuildPipeline.BuildAssetBundles("Assets/ShaderBundle", buildMap, 
        UnityEditor.BuildAssetBundleOptions.UncompressedAssetBundle, 
        UnityEditor.BuildTarget.StandaloneWindows64);
    }
#endif
}

Then in the mod I use this code to load from dll mod resources:

private void LoadShapeShaderBundle() {
    var myAssembly = System.Reflection.Assembly.GetExecutingAssembly();
    var myStream = myAssembly.GetManifestResourceStream("TrafficManager.Resources.shaders.customshaders");//added asset as Embedded resource of mod
    byte[] shader = TextureResources.ReadToEnd(myStream); //changed access from private to public
    AssetBundle bundle = AssetBundle.LoadFromMemory(shader);
    Shader sh = bundle.LoadAsset<Shader>("Assets/ShapeShader/CustomShaderMin.shader");//you can read that path to asset from bundle manifest but I hardcoded that because I am lazy :-)
//from now shader should be accessible via Shader.Find("Internal-Shader-Name"); (didn't tested)
    Material newMaterial = new Material(sh); //new material with shader
}

[kvakvs]

@krzychu124 Let's see if the Unity editor can be removed from the build process, ideally i want to press build in VS and have it done, not having to visit Unity.

[krzychu124]

Ok, but this is one time operation, I mean you have to just export shader as asset bundle and then you can even uninstall Unity editor ;)
That's the only way I found to load external assets at runtime.

I am still testing new shader so it's way faster to write scripts directly in Unity and do some tests before migrating to mod ;)

[kvakvs]

OK let's say I am happy to use bundle, if it is possible to embed that C# bundle call into a build script and run from Visual Studio, or have a standalone import tool that will be called from Visual Studio. Because we can store more in it than just 1 shader, like everything even.

Or if there is no other way to load a shader.

[krzychu124]

So in other words, you want an ability to create asset bundle each time from scratch when you build mod dlls to be able to alter bundle content without involving Unity to create that bundle?

I will dig for more info about loading external assets and I will try to create automated script to bundle whole content of assets folder which we can create for shaders and more new things, like you've said :)

[kvakvs]

Added outgoing lanes display, using 1m width bright green
Added ESC handling on the tool window closing
All outgoing lanes are shown, no actual respect is given to the manual lane connections

[originalfoo]

Looking good, some feedback...

When tool is activated, there's no indication of which nodes I can click until I hover the mouse over a node. For example, there are at least 5 nodes I can edit in this screenshot, but I have no visual cues to that effect:

If no node is currently selected, could the applicable nodes pulse so the user can clearly see what can be clicked?

Some transition nodes are perhaps not applicable to the lane arrow tool, for example there's not really anything I can do with this node:

If the number of vehicle lanes is the same on either side of the transition node, treat it like a segment node?

Mouse out doesn't seem to be happening properly, for example in the following screenshot my mouse is over the Parking Restrictions button:

The white lane should be blue, as the mouse is nowhere near it.

It would be great if, when hovering an incoming lane, its currently assigned outgoing lanes were highlighted on the map. That way I could quickly scan the lanes around a node just by hovering them to see what they connect to.

[originalfoo]

If I click a node (eg. see "parking restrictions" screenshot above), the node select circle remains, making it look like I can click it again. But it's already selected. Because of the large mouse 'hit areas' around lanes (and nodes) if I click the node as second time I'm actually selecting an incoming lane.

IMO it would be better, for selected node, to hide the node circle and prevent the node from being primary-clicked unless I exit out of that node first.

[kvakvs]

@aubergine10 we should consider changing these overlays here, to some magic shader tech, like running arrow animation maybe? https://dl.ledtronics.com/ImagesAll/web-arrow-mat.gif

Also it would be so much better with on-screen hints, i'll maybe i quickly slap together a simpler on-screen UI to display that until we get a good looking OSD

[kvakvs]

Now allowed turns show as slow blinking green on hover (trying to keep it easy for the colorblind players by not using red and green simultaneously and using brightness, shapes and animation rather than colors) and trying to keep it not too christmasy-tree-like everything is blinking. Maybe we could use some sprites at this point.

Added OnChangedHovered(Node|Segment|Lane) to the Main tool class, and using the lane hover change to set up the allowed turns structure.

[originalfoo]

trying to keep it easy for the colorblind players

Hrm, that reminds me, I need to complete #287 - the idea is that we'd put a setting in mod options for choosing color palette. It would default to material style colors but users could select different palette based on their vision needs.

Maybe we could use some sprites at this point.

IMO sprites will make it more christmasy-tree-like

[kvakvs]

Also fixed lane hovering/unhovering.
Now mouse cursor has to hit the ground within 50m from the lane end, otherwise it clears the hover.

[originalfoo]

I still have some issues with hover, for example in the following image the mouse is over the blue sausage (just under the lamp post near the red letter box) but the node to the left is treated as being hovered:

The current '50m from lane end' (and I suspect something similar for nodes) is too big margin for error.

For nodes, I think the mouse bust be over the node circle to treat it as hovered. For segments, I assume the issue is extra calculations required to deal with the fact they are curved?

Could we do something along these lines (pseudo-code):

function WhatAmIHovering() {

    for ( node in findNodesNearMouse() ) {
        if ( actuallyHovering( node ) ) return node
    }

    for ( lane in findLanesNearMouse() ) {
        if ( actuallyHovering( lane ) ) return lane
    }

    return null

}

And before calling that fictional function, check to see if what we were previously hovering is still being hovered (so as to avoid calling function unnecessarily).

---

Regarding the green circles that show current connections, I suggest remove the pulsing and leave them dimmed. I think ultimately those will need replacing with lane connection lines as it still took me a while to work out what they were showing, but they can be left for now as a placeholder (Krzychu is having some issues getting his new shader working in-game so might be a while before lane connection lines are ready for integration).

---

In terms of the pulsing effect, btw, is it possible to make it ease-in-ease-out? Think gently pulsing 'heartbeat' sleep/power indicator on Macbooks. The current pulsing seems to be a sawtooth pattern which feels like I'm getting visually slapped in the face over and over 🤣

---

When I have a lane selected, and there are other lanes on that same segment:

It would be nice if I could click the other lanes to select them without first having to deselect the current lane.

[originalfoo]

If I select a node, then right click to exit that node, then right-click again to exit tool - it exits tool, but the lane arrows button is still shown as selected on the TM:PE menu bar.

[kvakvs]

Have a try now, looking good.

Regarding switching editable lane, it means i need to render incoming sausages additionally, and they need to look different from outgoing. Maybe some shader with rolling colors or moving wave or something to show incoming.
https://www.androidpolice.com/wp-content/uploads/2016/01/nexus2cee_newanimationwaze4.gif

[originalfoo]

This is the first time I've felt in control of lane arrows tool. Instead of guessing what it's doing I can see exactly what it's doing. Once krzychu gets the other shader working, I think it will benefit from triangles on the outgoing lanes to more clearly differentiate incoming vs. outgoing. But it's definitely already a massive improvement on the original lane connector.

[originalfoo]

Some of the files updated in this PR don't seem relevant to the PR?