You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if you want to manually construct RoadPoints into the scene and then later connect them together, you have the connect_roadpoint function on the RoadPoint class per here.
So if you have, say, RPA at the origin and another RPB at (0, 0, 20) you might do a call like:
RPA.connect_roadpoint( # arbitrarily starting "from" the first roadpoint ARoadPoint.PointInit.NEXT, # presume RPA is rotated such that the "next" side is facing RPBRPB, # the one we want to connect toRoadPoint.PointInit.PRIOR# if RPB is facing the same way as RPA, then it would be it's PRIOR side that is closest/facing RPA
)
That's all good and dandy, but it's a quite a bit of extra work on each developer to try and figure out which ones to connect. In many cases, the road generator could probably easily guess which one the user wants by doing a simple dot product comparison of which way each one is facing relative to the other and then pick PRIOR/NEXT appropriate for each roadpoint.
We could accomplish this by introducing a new direction type, though we'd have to be very clear where this is allowed to be used or not:
RPA.connect_roadpoint( # arbitrarily starting "from" the first roadpoint ARoadPoint.PointInit.AUTO, # let the road generator figure out which direction of RPA is facing RPBRPB, # the one we want to connect toRoadPoint.PointInit.AUTO# let the road generator figure out which direction of RPB is facing RPA
)
If RPA is entirely unconnected, then it would check whether the -z or +z basis is more oriented towards PRB to decide PRIOR vs NEXT
If RPA is connected on one side e.g. it already has a "next" connection, then it should just directly use the other direction ie "prior"
Ditto checks for PRB
With the above, it also adds flexibility: maybe you know that on RPA that it's the "next" that needs connecting or has a more ambiguous orientation, you could specify that one specifically but still let the other side be auto-figured out.
Alternatively, we could just provide the simplest possible function like connect_roadpoint_auto which only lets you pass in another roadpoint. This function itself could call connect_roadpoint internally after determining the right orientations.
The text was updated successfully, but these errors were encountered:
Right now, if you want to manually construct RoadPoints into the scene and then later connect them together, you have the
connect_roadpoint
function on the RoadPoint class per here.So if you have, say, RPA at the origin and another RPB at (0, 0, 20) you might do a call like:
That's all good and dandy, but it's a quite a bit of extra work on each developer to try and figure out which ones to connect. In many cases, the road generator could probably easily guess which one the user wants by doing a simple dot product comparison of which way each one is facing relative to the other and then pick PRIOR/NEXT appropriate for each roadpoint.
We could accomplish this by introducing a new direction type, though we'd have to be very clear where this is allowed to be used or not:
With the above, it also adds flexibility: maybe you know that on RPA that it's the "next" that needs connecting or has a more ambiguous orientation, you could specify that one specifically but still let the other side be auto-figured out.
Alternatively, we could just provide the simplest possible function like
connect_roadpoint_auto
which only lets you pass in another roadpoint. This function itself could callconnect_roadpoint
internally after determining the right orientations.The text was updated successfully, but these errors were encountered: