Closed TheDuckCow closed 6 months ago
As we discussed, Edge curves will be placed on each RoadPoint. However, the "Create Edge Curves" flag that enables/disables them will be on the RoadContainer.
Per the requirements, if Create Edge Curves is disabled, it it will clear all of the edge curves on scene load or when a rebuild is triggered.
Also, the logic that drives much of the program behavior is such that only the selected RoadPoint gets updated when a change is made. Not the entire network. Hence, edge curves only get created for RoadPoints that are updated in some way (and on scene load). This may or may not be the desired behavior. Feel free to weigh in.
Lastly, since each RoadPoint will have a left and a right curve, they will be named "edge_L" and "edge_R". They will be unique on a per RoadPoint basis. Thus, complex naming isn't needed.
Minor update: The edge curves will actually be called "edge_F" and "edge_R" for "Forward" and "Reverse".
Hey @bdog2112! Thanks for laying out the additional details here. Agreed on all points above, including the naming. I appreciate the revision there, since that nicely parallels the pre-existing terminology. Couple things to upack a little further:
Per the requirements, if Create Edge Curves is disabled, it it will clear all of the edge curves on scene load or when a rebuild is triggered.
To be more explicit, let's go with:
Another thought I had is whether we should try to create some kind of warning or popup if a user tries to disable edges on a container when such edges already have pre-existing children. This would probably be tricky, especially since we'll still need to use export vars. So, I'm shelving that idea for now but something to consider in the future.
One other thing to watch out for is how the behavior works with undo (and redo). There's already some cases today that aren't ideal (bug here: https://github.com/TheDuckCow/godot-road-generator/issues/84) so we could potentially just tack onto that if we have new problems arise. So, don't fret if it's not perfect out of the box.
Ah I'm now realizing I already wrote much of this in the above description - anyhow, main priority is getting the reusable edges in place, other polishing features like popups and undo/redo we can take in a second stride.
Need some input on desired curve behavior when manipulating RoadPoints.
During RoadPoint Rotation/Translation (manipulation), RoadLanes are cleared. But, when mouse button is released, RoadLanes are rebuilt. Meanwhile, road geometry is updated throughout the manipulation process. What is the desired behavior for RoadEdges?
RoadEdges will have attached objects. Hence, the above alternatives are applicable, there, as well. What is the desired behavior for attached objects?
For the moment, I will proceed with option 1 for RoadEdges and option 3 for attached objects.
FYI: Attached objects, more or less, follow the starting RoadPoint. Hence, no further action is needed for them unless an alternative behavior is desired.
I actually am liking the idea of number two - since the objects aren't being destroyed and created each time, just updating some curves, it should remain pretty responsive. Plus it may be useful for users to preview how roadside elements will be before they release. On Mar 1, 2024 1:29 PM, "B. Rhoades" @.***> wrote: Need some input on desired curve behavior when manipulating RoadPoints. During RoadPoint Rotation/Translation (manipulation), RoadLanes are cleared. But, when mouse button is released, RoadLanes are rebuilt. Meanwhile, road geometry is updated throughout the manipulation process. What is the desired behavior for RoadEdges? Hide RoadEdge on manipulation start. Then, show RoadEdge on manipulation end.Update RoadEdge continuously during RoadEdge manipulation.Leave RoadEdge visible during manipulation. But, don't update until manipulation end. RoadEdges will have attached objects. Hence, the above alternatives are applicable, there, as well. What is the desired behavior for attached objects? For the moment, I will proceed with option 1 for RoadEdges and option 3 for attached objects.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Alright! Just pushed an update. Here are the deets:
TTD:
Curves appear fine on first RoadSegment. But, something is wrong on subsequent segments. Investigating...
Nice update @bdog2112! Had fun playing around with it here :D
Only comment is it seems there might be some global to local mixup (I guess that's the godot equivalent of "off by 1"), see here, just in case you weren't already aware. Really excited to see this working once we have intersection offsets accounted for, making great progress.
Pushed latest WIP. Previously, refactored code so that it would update instead of add curve points if they already existed. Determined that a couple of local/global coordinate conversions were needed in the refactored code. Curves should now plot as expected.
Nice - we can start moving the discussion more into the PR itself now, so we don't have to post in both locations - my latest comment (and future ones) will be there
I'm going to mark this task as done, since they are working in dev to spec. Good work!
Right now, we generate RoadLanes (for AI) but we don't have any way to fetch the edge along a curve/road. Someone who wants to, for example, create a sidewalk or barrier following the edge of a road would have to place their own curve.
Let's use the same approximation mentioned here to construct one or more "Road edge curves".
For Wheel Steal Game, since RoadPoints are always added one RoadPoint at a time, we will need to be able to have these curves be per-RoadSegments. But there should also be an option/mode to create them per RoadContainer. The RoadContainer use case is likely much nicer for many users, as they can have one barrier that extends the entire road, whereas per RoadSegment they'd have to set up the configuration on each individual RoadPoint.
Some considerations: