Add Spline Curve to Trajectory

added Actions label

mentioned in issue simulation/opendrive-group/opendrive-standard#178

changed the description

I found out that splines can be modeled by NURBS, which is surprisingly to me not as tricky as expected and that my statement above "only start and end point are on the actual trajetory" is wrong.

I would therefore first try to better describe what is possible with NURBS and how to in detail use them. Additionally providing examples for e.g. what influence the knot vector or the weight of a CP has on the resulting trajectory, could drastically reduce the hurdle to start with NURBS. Maybe @emil.knabe you could help in the next OpenSCENARIO project with creating some examples as you seem to be quite fit with NURBS.

Interesting!

I must warn that I'm still noob when it comes to NURBS, hard to get a full understanding of it all (weights, knots...)

But since NURBS seems to span multiple possibilities (curve types and use cases) I'd be interested to learn more and try to collaborate in providing useful examples.

This is interesting for me as well since I am following this in both standards. Currently I see the Bezier Splines as the most promising candidate due to its wide tool and library support. Usually the tools include an option to manipulate the conditions for the transition point of the segments which allow the user to easily specify the continuity of the curve.

When someone says that a Bezier Spline Curve can be stored as a NURBS and this is not necessary I would like to point out (again) that

This conversion is not a lossless operation which can be inverted (not all NURBS are Bezier spline curves and we don't know if it was one before the conversion) so it becomes very difficult to read an edit an OpenSCENARIO file in that case.
It is very difficult to store additional information such as the required speed on each segment when using NURBS curves due to the way a NURBS curve is defined (it has no segments).

(Maybe someone can proof me wrong regarding these two concerns?)

Another side note: For OpenDRIVE such spline curves are useful to model roads based on map and/or laser scan data where you have to fit the curve to the data. Nowadays in OpenDRIVE this is also a lossy operation since the Bezier Curve which is often used inside the modeling tool will be converted to multiple (independent) ParamPoly3 curve geometries in the OpenDRIVE file. So when loading the file the information that those segments belong together is not explicitly available and it is difficult to convert it back. Also there is no guarantee that they fit together.

@adrian.vernickel I believe that I can provide some simple NURBS based example(s) if you tell me what you need.

Regarding 1:

As I understood it, this can be told by the knot vector and the degree of the NURBS curve. See an example representation of a bezier spline as nurbs curve. (image by http://nurbscalculator.in/)

When the knot vector is structured as in the example image ("equidistant" and same entry number of degree times in the vector) and additionally the CPs, which are directly on the function, and their predecessor and sucessor are on a straight line, the NURBS curve is equivalent to a continous spline (e.g. bezier or cubic spline). So, if those requirements apply they can be transformed back and forth without loss.

Regarding 2:

Good point. It can have but must not have segments, which is the same for bezier splines. If the NURBS curve is a bezier spline, it has the same "segements", which start at the index the knot vector is changing its value.

Cool. I like this relation between NURBS and Bezier Spline.

Maybe it could be possible to have a check, based on the prerequisites that you mention, to determine whether the curve is a Bezier or not. Which then could be utilized in an editor tool. I mean, if the NURBS is concluded to be a Bezier, then it also can be edited like one, and saved again.

I think that would be a better approach than introducing a type or flag to indicate Bezier compatibility - since the flag might lie.

I think it may be hard to squeeze in a new curve type for the upcoming OpenSCENARIO project. So it's an advantage if we instead can make use of and potentially extend what's already available.

Regarding "saving Bezier spline curves as NURBS": Although it is nice that we have clarified this relationship I do not like this approach of jamming a Bezier Curve into the NURBS "container" very much because this does not seem robust to me. Problems I see:

People will have a hard time understanding this since it is not intuitive
This is a leaky abstraction of the underlying math since people would now in many cases be forced to understand the inner workings of both curve types in order to implement related features into their tools
There is no easy way to guarantee that you will receive a Bezier curve since it is up to any tool in the ecosystem to fill in any parameters they want when exporting the NURBS. This sounds like a compatibility nightmare to me.

Overall a very "hacky" approach. I believe there is a reason for many content generation tools to handle these two curve types explicitly separate. I also think we are not creating so much extra effort for the consuming tools by adding Bezier Splines because they can convert the Bezier curve to a NURBS curve and then during runtime process both curves in the same way. If there is not enough time in 1.3 to properly add a new curve type, I would then rather not add any features to the NURBS which facilitate this kind of hack and then make it more difficult in the future to properly work on this. Better wait for 1.4 instead.

Regarding the segments: I think it is correct that you can design the knot vector in such a way that they are equivalent to a Bezier spline. However, first, you have now added some very specific constraints and second, now you need to design another fitting vector into the OpenSCENARIO interface in order to provide the additional trajectory data such as speed for each segment alongside it. Now when implementing a consumer of this "construct" they will have to combine the information in such a way that this additional information and the internals of their NURBS library properly function together which sound problematic to me. It sounds much easier to me when you have "explicit" spline segments. I am open for discussions though regarding this point.

Overall again, if this issue is to difficult to move forward within the 1.3 sessions I suggest we at least move forward with the sister issue #506 (closed) in order to better enable NCAP scenarios. When it comes to the session to discuss this I am also willing to create/show a little prototype, which shows the difference between NURBS and Bezier Splines when edited by a human in a content generation tool. This can probably give many people in the meeting a much better intuitive understanding.

Overall again, if this issue is to difficult to move forward within the 1.3 sessions I suggest we at least move forward with the sister issue #506 (closed) in order to better enable NCAP scenarios.

I would agree. Let's see if there is time, but first we should focus on clothoids!

I'm fine with this conclusion as well. But I wouldn't expect any major additions to OpenSCENARIO 1.X, neither 1.2.1 nor a potential 1.3. So that's why my mindset, in general, is to find low hanging fruits.

@emil.knabe I don't fully agree with the conclusion that we can not add new stuff to OpenSCENARIO 1.x. If there is enough interest (from our side there is and looks like from your side as well(?)) this should be enabled by ASAM in 2023. As of now I don't see that 2.0 can cover all the use cases of 1.x and vise versa. So both must coexist for some time such that we can keep going and moving forward.

True. I was unclear. I had the next upcoming project in mind. Initially I expected a OpenSCENARIO 1.3 project. But instead it will be a common OpenSCENARIO "patch" project for 1.2.1 and 2.0.1. Limited in time and focusing on fixes and specifically the way forward (e.g. migration path). But AFTER that I also hope there will be a 1.3 project (and so on). That said, I think there are other wills and opinions so nothing is set yet.

And finally, the door is of course not totally closed for feature additions in 1.2.1 as well but I'd say that the door-gap is quite narrow. I have myself some stuff on the wish list :)

@adrian.vernickel @emil.knabe How can I add a link to another issue? The (+) button for that seems to be missing, maybe I don't have the rights for that? I would like to add a link to #506 (closed)

That can be done underneath the issue description. I have done it

marked this issue as related to #506 (closed)

changed the description

added 1 deleted label

changed milestone to %1.3 & 2.1

changed due date to July 31, 2023

added DomainModelAlignment label

added 1 deleted label and removed 1 deleted label

added isType:NewFeature label and removed 1 deleted label

assigned to @bhanu.rathore

Add Spline Curve to Trajectory

Describe the feature

Describe the solution you would like

Describe alternatives you have considered

Describe the backwards compatibility

Additional context

Child items

Activity

Add Spline Curve to Trajectory

Describe the feature

Describe the solution you would like

Describe alternatives you have considered

Describe the backwards compatibility

Additional context

Child items

Linked items

Activity