[Feature Request / Question] Mitered paths with different start/finish line widths
Closed this issue · 7 comments
I'm trying to find a way to draw a mitered open path with a starting line width different from the ending line width. I'm thinking the approach is likely to involve interpolating between the two line widths at the point of the join (in relation to the entire path length) and using that line width (halved) as halfLineWidth in drawPathWithJoin. That might be enough, if lucky?
I was wondering if there was already a way to do this and I'm just not seeing it, or if you had a different approach in mind that might work better.
This idea is fine in principle - I'll have a look at the PR this week and see if it needs modification.
Any news on something like this?
Hey sorry for the long delay, regarding your PR - you've got the right idea but I can see a couple of issues, so I've implemented something myself which is similar but a bit more general. It's mostly done, but I just need to test it and adjust the build, since I'll also update it to Java 8. Should hopefully be in master this week.
@rubybrowncoat you can check it out now, it's in this branch.
I still need to add javadoc, but you can specify a line width with a LineWidthFunction, it takes two arguments i (the index of the vertex at which the width is being specified) and t (the relative distance the vertex is along the path, in [0,1]). So for example you could call drawer.path(path, joinType, open, (i, t) -> Interpolation.linear.apply(10, 20, t)), which would draw your path with a starting width of 10 and ending at 20.
There might be some hiccups in the implementation - let me know your observations.
I've been trying to test it but I'm running into some issues, namely with the i parameter of the LineWidthFunction. On a path of 41 points I'm expecting i to go from 0 to 40 and it does go from 0 to 39 and then instead of 40 I get 18. On a path of 4 points I get an i of 0 1 2 and 0 again. And on a path of 3 segments i it is 0 1 and -1 which is the real issue because I need to use the index to get the width at that location and -1 is out of bounds.
Sorry I changed the indices from representing the float index to representing the vertex index and forgot to change the line for the last index, that should be fixed now. There still seems to be a small problem with the parameter t though - it seems to fluctuate slightly as the number of points on the path varies, I'll see if I can fix that.
Just wanted to confirm that the feature seems to be working as intended.
I haven't stress tested it, but it looks alright. 👍