Add 3D gizmo controls for lane counts

[TheDuckCow]

As the next step extension to https://github.com/TheDuckCow/godot-road-generator/issues/34, we should update the 3D view such that we can easily change the number of lanes visually by dragging the control points inwards or outwards.

Some requirements:

• Each RoadPoint should have 2 additional control points. It should follow the same rules of being visible as the existing 3D gizmo handles.
• They should slide only along the local X axis.
• The actual handles should be placed 0.25lane_width unites to the outside* direction of the outermost lane "edge"
  • This prevents issues with the points overlapping if one side or the other is cut down to 0 lanes
  • Much like the minus lane button, it should not let you slide it below 0 lanes (at zero lanes, the handle will be 0.25*lane_width units away from the center divider).
• They should snap into place after the user has finished dragging them
  • How can we accomplish this? Can we created stepped motion without it messing with interactivity? May require some research or asking questions e.g. in the godot discord
• We should make the handle color unique. Per prior mockups, blue would be appropriate.
• The value that these gizmos connect to should not be visible as export variables.
  • There may not need to be even a class variable at all. Instead, it should functionally call the existing add/remove lane function once the threshold has been met (for the first time, to avoid repeat calls) for a particular count of lanes.

[bdog2112]

The following should adhere to the above constraints. At present, I'm thinking it'll work like this:

• There are 3 key visual components: 1 Arrows, 2 Handles, 3 Road
• When user selects RoadPoint, Arrows and Handles are shown and old widget is/is not shown (TBD)
• When user deselects RoadPoint, Arrows and Handles are no longer shown. This will, essentially, inherit the same behavior as prior widget.
• User moves and fully controls Handles (no snapping while moving)
• Arrows snap, interactively, to nearest lane edge (plus 0.25lw).
• Road does not update while user is moving Handles because that is processor intensive and it also causes the RoadPoint to re-center.
• When user releases Handle, it snaps to lane edge (plus 0.25lw) and then the Road updates.

One detail that isn't exlicitly mentioned is widget Lane Markers. Although, they are often pictured in mockups.

At present, the intent is to leave the lane markers as an option on the table. But, initially, the focus will be on Handles, Arrows, and Road. If Lane Markers are needed, then we need some additional requirements.

[TheDuckCow]

Good callout that the lane markers requirements aren't present yet. Let's leave that out of scope for now, easily added in later once we see the system we like and working well.

For now, let's not display the handles for not-currently-selected RoadPoints. This way we only ever have one set in the scene at a time. In fact, you might even get away with actually having only one set in the scene, and just keep moving and/or hiding them based on current selection.. this could be most optimal and avoid constant creation/queue_free'ing. Endpoint is, I don't want to end in a state where every single road point has 3-some additional children meshes that are present but hidden until selected.

User moves and fully controls Handles (no snapping while moving) Arrows snap, interactively, to nearest lane edge (plus 0.25lw).

Yup I think this works well. Though we'll probably want to "snap" the lane count to the integer multiplier position once the user has let go (similar to how roads switch from low poly to full rendering after you have stopped moving them).

Road does not update while user is moving Handles because that is processor intensive and it also causes the RoadPoint to re-center.

I think this is ok for now. In the future, we could update to insert additional lane markings to sort of "preview" when new lanes will be updated before release. It may also be that we just want to move to having the roadpoint's lanes generate out from the center (that align center setting we spoke of long ago.. but out of scope for now).

Let me know if that's all clear or if it raises any other questions!

[bdog2112]

old widget is/is not shown (TBD)

Should we continue to display the old (red/yellow) widget along with the new one?

In fact, you might even get away with actually having only one set in the scene, and just keep moving and/or hiding them based on current selection.. this could be most optimal and avoid constant creation/queue_free'ing.

Right now, the widget geo is created/freed by each individual instance of the RoadPoint class. We could create a single copy directly in the GizmoPlugin class and use its logic to position and show/hide it.

As for how the widget geo is created, the current process of using Immediate Geometry works well. Meaning that we don't need to import any models. We could just continue employing the old methodology. But, do it directly in the GizmoPlugin.

In the future, we could update to insert additional lane markings to sort of "preview" when new lanes will be updated before release.

Yeah, this is the perfect use case for overlaying those blue lane dividers and add/removing them interactively. Is that what you're suggesting?

[TheDuckCow]

Should we continue to display the old (red/yellow) widget along with the new one?

This new visual should replace the old red/yellow placeholder visual. We can disable it, instead of fully deleting, in the short term, but later we can entirely remove.

...Meaning that we don't need to import any models. We could just continue employing the old methodology. But, do it directly in the GizmoPlugin.

Though I do like the idea of using immediate geometry, which feels more "fit for purpose", it's just a bit more work to actually create the models that way. Having a lot of immediate geometry also quickly slows things down, a problem faced by the Lane Segment visualization. So I'm also interested to see how this goes using meshes as part of interactive selection.

Yeah, this is the perfect use case for overlaying those blue lane dividers and add/removing them interactively. Is that what you're suggesting?

Yeah exactly (plus, much further down the line, maybe some very temporary immediate geometry sort of preview "shadow" of the area being expanded). For now we'd start with just the lane marker, but we can do this as a second step once we get the initial handle placement working.

We could create a single copy directly in the GizmoPlugin class and use its logic to position and show/hide it.

Yeah I like this idea 👍 let's see if we can pull that off

[bdog2112]

Hey @TheDuckCow, the RoadPoint lane gizmo has been updated!

GIZMO FEATURES

• Appears when RoadPoint is selected
• Disappears when RoadPoint is deselected
• Displays left/right arrows and lane dividers connected by a line
• Blue circular handles manipulate left/right arrows to add/remove lanes
• Lane dividers are added/removed interactively
• Handles snap to the outermost lane divider
• Handles are prevented from crossing road divider
• Right-click cancels handle movement
• Widget geometry is re-used in order to limit memory consumption
• Widget geometry adjusts interactively when RoadPoint is translated/rotated

GIZMO ISSUES

• Handles jump at grazing angles.
• Godot "selection" feature has built-in issues.
  1. When an object with a gizmo is selected and then deselected, Godot maintains a hidden "selected" state that can't be retrieved or cleared. So, the gizmo remains shown even though nothing is selected.
  2. Godot will only display gizmo handles on the object that it considers to be selected even if multiple items or nothing is selected in the Scene dock.
  3. When multiple objects are selected, Godot randomly chooses the order to represent them in memory. Sometimes, they're stored in order of last in first out. Other times, they're stored in order of object name or Scene panel order. It may seem predictable, at first. But, eventually, it proves to be unpredictable. One can't always rely on the 1st selected item to be Godot's primary selection.

The implication is that it's impossible to reliably determine which object is the primary selection. Hence, it is difficult to consistently display a gizmo on the correct object in all situations.

Godot may redraw any gizmo at any time, whether its parent is selected or not and we don't want users altering deselected objects unintentionally. So, we have to make sure the Gizmo's redraw routine knows if it should draw handles each and every time it runs.

I've done my best to address these problems by hiding gizmos when nothing is selected. But, there is still an issue with multiple selections.

Since it's not possible to determine Godot's primary selection when multiple items are selected, it might be best to simply hide gizmos in that situation.

TTD

• Possibly, tweak gizmo position above roadpoint
• Implement gizmo "culling" material
• Improve handle manipulation at grazing angles
• Get feedback and address any issues

[TheDuckCow]

Great to see this progress! Would love it if you can go ahead and create a PR for the branch, even though it's in draft (just helpful to keep track). Happy to talk through what of this we can live on the call today.

Side note, I did get an error the first time opening the project on this current branch, and errors persisted after restarting.

Initial error (which caused a global godot popup saying the addon was disabled due to errors):

 Unable to open file: res://.import/gizmo_blue_handle.png-5b1155ef9bf6c3ffd6b3ab6d395f34ae.s3tc.stex.
 Failed loading resource: res://.import/gizmo_blue_handle.png-5b1155ef9bf6c3ffd6b3ab6d395f34ae.s3tc.stex. Make sure resources have been imported by opening the project in the editor at least once.
 Failed loading resource: res://addons/road-generator/gizmo_blue_handle.png. Make sure resources have been imported by opening the project in the editor at least once.
 res://addons/road-generator/road_point_gizmo.gd:13 - Parse Error: Can't preload resource at path: res://addons/road-generator/gizmo_blue_handle.png
 res://addons/road-generator/plugin.gd:5 - Parse Error: Couldn't fully preload the script, possible cyclic reference or compilation error. Use "load()" instead if a cyclic reference is intended.
Switch Scene Tab
 servers/visual_server.cpp:346 - Octahedral compression cannot be used to compress a zero-length vector, please use normalized normal values or disable octahedral compression
Road segs rebuilt: 6
Switch Scene Tab
 Cannot get path of node as it is not in a scene tree.
 (Node not found: "segments" (relative to "").)
 modules/gdscript/gdscript_functions.cpp:775 - Segments node path not found

After restarting (and re-enabling the plugin):

Road segs rebuilt: 6
Switch Scene Tab
 Cannot get path of node as it is not in a scene tree.
 (Node not found: "segments" (relative to "").)
 modules/gdscript/gdscript_functions.cpp:775 - Segments node path not found

[TheDuckCow]

Mild edit - it did start working fine actually for the most part, I just had to manually toggle the refresh roads on startup tick box (separate bug that this is even ever needed). So far, this is actually working quite well!