When a vehicle trajectory is placed in a scene, the user may want to make sure that the vehicle driving the trajectory arrives at certain points at certain times (cue points) so as to interact in a nice way with other vehicles driving on other trajectories. For example, if the user wished to simulate a ’near miss’, it is important that one car pass very close to another car at a certain time in the scenario. Perhaps later, the same vehicle must also arrive at another point to do something similar with a third vehicle. The options for scenarios are broad, and the options available for editing are designed to cater for all cases.
There are various ways in which to edit vehicle trajectories in both space and time. Here, we will cover both separately.
Spatial Editing (space):
General spatial editing is performed by dragging trajectory waypoints on the map manually with the mouse. When the user hovers the mouse close to any of the waypoints, the waypoint is highlighted with a grey glow. Left-clicking the mouse will pick the node up and it can be dragged to another place on the map.
When selecting a waypoint on the map, notice that the waypoint is also selected on the Trajectory Edit Window which corresponds to that trajectory.
The user has control over how reactive such movements are, using the Force Field slider in the Trajectory Edit Window. If the Force Field slider is kept small, any dragging of waypoints will only make changes to the trajectory locally (the neighboring waypoints will node move or move only a little). If the Force Field slider is large, it will affect the neighboring waypoints more drastically. A balance can be found. When hovering over a node, the extent of the Force Field can be seen – the reactive section of the trajectory will be highlighted in grey along with the node.
If the user wishes to add new waypoints, or remove selected waypoints, the Trajectory Edit Window allows this from button clicks. Adding a waypoint would involve selecting the waypoint which the user wishes to add a new waypoint after, then clicking the button. Removing simply involves selecting a waypoint and clicking remove. For more information about these features and similar features, this documentation has a page regarding the Trajectory Edit Window itself, where each button and function is described.
Locking:
Waypoints can be locked and unlocked using the Trajectory Edit Window. By default, all waypoints are unlocked. This means they are free to move around, such as when the user drags them. If a waypoint is locked, however, the position (and time) is fixed and cannot move. Unlocked waypoints appear on the trajectory as spheres, while locked waypoints appear as cuboids. See the images below.
In the illustration below, waypoints 4 and 7 are locked. This divides the shown vehicle trajectory into three distinct sections; a free section at the start (from waypoint 1 to waypoint 4), a locked section (from waypoint 4 to waypoint 7), and a free section (from waypoint 7 to waypoint 9). Vehicle trajectories can be split into as many sections as there are waypoints, but each section will either be ’locked’ (that is to say that there exist locked waypoints at each end point), or ‘free’ (at least one end of the section is free/unlocked). If there are no locks used on a vehicle trajectory, the trajectory is still said to be free, but both ends will have ‘free’ waypoints.
If we attempt to move one of the waypoints, for example waypoint 5, we will see that any changes to do not propagate beyond the locks, even with the largest Force Field value.
When using locking, the user may find that it is not possible to move some waypoints beyond certain limits - the dragging will appear to stop in such cases. This is due to the fact that when moving positions where there are locked regions, the waypoint times can start to go out of order. For example, moving waypoint 6 far enough may mean that the time-stamp becomes later than the time-stamp of node 7. This is not allowed, since the waypoints of a vehicle trajectory must be monotonously-increasing. The user should also take care when even reaching this limit, since velocities can increase considerably. This, again, is limited by the ScriptAI Editor, but it is still possible to create adjacent sections of a vehicle trajectory which go from, eg, 15kph to 150kph in the next section. This is unlikely to be desired behavior.
Temporal Editing (time):
In order for the user to have a vehicle arrive at a specific point at a specific time, temporal editing can be used.
In the simplest case, where we have a completey free vehicle trajectory (no locking), the user can simply select a time on the Tool Window time-transport slider, then move the vehicle trajectory’s black guide box to the desired position. The direction in which to drag can be found by clicking on the black box once it is highlighted with a grey outline, then moving the mouse. The user will quickly be able to see the bi-directional nature of the dragging here. Note that the mouse direction is unrelated to the local trajectory direction. The image below shows how guide boxes typically appear in the ScriptAI Editor.
In the above simple case, there are no locks. This means that every waypoint time is free to adjust itself as it likes. They will all be translated accordingly to ensure that the vehicle arrives at the chosen position at the chosen time. For vehicle trajectories which only have one cue point, this may be sufficient. It may mean that vehicles appear to start with a delay of some time before moving anywhere, depending on the direction of movement of the guide box.
Locking (revisited):
A more challenging case would involve a vehicle trajectory which had two distinct cue points, which is it to say that it has to be at two places at two different times. If we used the above approach, we could set one of these cues, but when setting the second, the editing involved would alter the first and ruin its precision. This is where locking would be used.
As each desired cue point is fixed, locks can be placed on waypoints around the region of interest. This will stop any editing propagating into this region, so these locks act as a ‘barrier’ to prevent it from being touched. It is recommended to do this sequentially with a vehicle trajectory - starting at one end, and doing the cue points in order.
In the illustration below, where we have used the ‘velocities’ display option, we have start at the ‘start’ waypoint and progressively worked our way towards the end, adjusting the guide box in various sections to create an increase in velocity, followed by a decrease in velocity. Note that waypoints 4 through 8 are locked. We started by locking waypoint 4, fixing the velocity in the section between waypoints 4 and 5 to what we wanted, then locking waypoint 5, fixing the velocity in the section between waypoints 5 and 6, and so on. This process can be continued across the whole length of the vehicle trajectory, as required. In typical cases, the user may have multiple vehicle trajectories and wish to sync them together in some way. These ideas are the foundation of how to achieve such things.
