I came across a situation whereby I needed to find the length/pct on a ofPolyline in relation to the closest point (using the getClosestPoint(ofVec2f) method. However, there wasn’t any way to get this using the already existing functions.
Hence, I modified the existing getClosestPoint function to suit my requirement.
It worked fine for me, but I’m not sure if there’s anything that could be done to make it more efficient. That aside, I might propose adding the following function to ofPolyline? (The name of the function probably could use a bit of summarization )
this seems like a great function (and one that I’d probably use / have written in the past) but maybe it’s worth considering if it’s not great as part of an addon with more advanced or specific polyline functionality? as you describe I think it would benefit from a readme and an actual example.
Yes you are right. Half distance between vertex 3 and 4 would return 3.5.
All I did was really just alter the last few lines of the ‘getClosestPoint()’ function that already exists in ofPolyline.
The section that assigns a value to an unsigned int pointer, added an extra step that rounded off the number to the closest vertex (which also has its uses) and I essentially just removed that and set it to return a float instead.
Either way I’ll put together an example that compares the 2 functions (is that what you meant by PR?) and add some proper comments as soon as I get a chance to.
While building this, I’ve noticed a bug with the function when it comes to closed polylines. It lerps between the last and first vertex indices when the closest point resides between the two at the ‘closed’ end (ie. the full range of vertices). I suppose the behavior should be a lerp between the last vertex and the last vertex+1? Hence if there was a polyline with 12 vertices, and the point in question was midway between index 11 and index 0, it should read 11.5. Would everyone agree?
I’ll try to think of how to implement this, however, the reset of the example should demonstrate the function and how it can be applied.
After a bit more testing, it seems its the other existing functions that the lerp is working correctly, but it’s the other existing functions that use an interpolated index as an argument, which become buggy when the value of the index is higher than the index of the last vertex. Not sure how to take this forward…