Can't access the video (it's private) - it'd be interesting to see what you're talking about though.

In any case, if you're still looking for a solution, I'd recommend at least giving my previous suggestion a try. I can't guarantee it's what you're looking for, but it shouldn't take too long to implement it and try it out.

Thanks for posting the video.

Needless to say, that's a bit more complicated case than your original example

Maybe you already said this, but are you doing the path smoothing yourself? Or are you using third-party code for that and trying to compute the new deltas as a post-processing step? I ask because if you're doing the smoothing yourself, then I'd think computing the new deltas could be rolled into that process, but without knowing how the smoothing algorithm works I couldn't say exactly how to do that.

There are a couple potential issues with my suggestion with respect to your new example:

- With that many points you may run into performance problems with a brute-force approach (which my suggestion is, essentially).

- You could run into problems where the path intersects itself due to points from the smoothed curve associating themselves with the wrong segments from the original curve.

In any case, I think it'd be useful to know at this point whether you're doing the smoothing yourself or not.

It seems likely that the optimal solution would involve computing the new time values as part of the smoothing operation. It may not necessarily be the case, but I wouldn't be surprised if all the information you needed was available during the course of those operations.

For example, according to Wikipedia at least, the points returned by Ramer–Douglas–Peucker are a subset of the input points. So for that algorithm at least, the problem is trivial - just retain the time values for the points that survive the process.

Chaikin appears to involve interpolating between points of the input curve, in which case time values can be interpolated as well. Similarly for your third step.

If those three steps are easily separable, you could tackle the problem one step at a time. First get your Ramer–Douglas–Peucker implementation to preserve the time values, then try to get Chaikin to interpolate those values along with the positions, and then similarly with the last step. Test each step as you go to see how it's working.

Note that throughout this discussion I'm assuming absolute time values, not deltas. If you start with deltas or need deltas at the end, you can convert back and forth to and from absolute values as needed.

Although I only took a quick look at the algorithms you're using, I do wonder a little how robust they themselves are in the face of arbitrary paths (e.g. self-intersecting). For example, based on Wikipedia's description at least, it seems like Ramer–Douglas–Peucker could fail if the first and last points in the path are coincident. I looked around online a little and didn't find any discussion of this, so I may be missing something. In any case, you might be unlikely to encounter failure cases in practice, but it's something to keep in mind.

Similarly, my proposed post-processing solution wouldn't be reliable in the face of arbitrary paths - it could fail if the path intersects or even passes very close to itself. I'll post back if I have any other ideas though.

In case performance ever becomes an issue for you, I'll mention that I see some places where the RamerDouglasPeucker() function may be doing considerably more work than is needed. So, there may be some opportunities for optimization there.

As for revising the code to meet your needs, here are some suggestions.

Recursive algorithms can generally be expressed iteratively (in a loop or loops, as you suggest), but you really don't need to dig into that if you don't want to. There are other ways to address the issue.

Similarly, you could fairly easily revise the code to return an array rather than operating on an input array, as you mention, but you could also avoid that if you're not that comfortable with the code. You could just give up on that one (as it's ancillary to your problem), or you could write a wrapper function that creates an array locally, passes it to the function that does the actual work, and then returns the local array. That way, from the outside a new array would be returned, but internally it would be using the code you have currently with no modification.

Anyway, on to the real issue. If you're not too comfortable with the code, you might want to modify it as little as possible in order to avoid introducing bugs or errors. With that in mind, if you've already made significant changes, you might want to go back to the original code and start over.

The reason I suggest this is that getting the original time values back from the code should require minimal changes - probably fewer than you've made already. The code expects a type, RDPpoint, that includes fields 'first' and 'second' (the vector x and y value). There's no reason I can see that RDPpoint can't instead be a struct/class of your own creation that has 'first' and 'second' fields of type double, and also an 'absolute time' field.

Given that change, your original code would work exactly as before, but every time it copied one of these values, it would copy the time value as well. (I only see copying/moving of these values in the code, but if there are other things involved, like creating new std::pair instances, you should easily be able to adapt those parts.)

In summary, my suggestion is to use the original code, and replace RDPpoint with a struct/class of your own that stores the time values along with the coordinates so that the time values are included in the output.