Hi Denis,
The example I gave was intended to be very crude - I was simply
describing the technique, but as I said it would require better math to
really know what the right formula would be.
With respect to finding a cubic root, currently you are doing that in 2
dimensions, but what if we converted to 1 dimension?
Consider that the control polygon is "fairly linear". What if we
rotated our perspective so that it was horizontal and then squashed it
flat? Consider instead a 1 dimensional bezier with control values of:
(where |mn| is the length of the m->n control polygon of the original
curve - sum of all segments from point m to point n)
0.0, |01|, |02|, |03|
Solve that 1 dimensional bezier for v=(leaflen*polylen)/linelen...
...jim
On 12/10/2010 8:23 AM, Denis Lila wrote:
Hi Jim.
Actually, even if the lengths aren't close the lengths may give you
enough information about the acceleration along the curve that you can
do a decent approximation of the accelerated T value. The T could be
biased by some formula that is weighted by the ratios of the control
polygon lengths. As a very crude example, say you assumed that if the
scaled leaf length fell into the first polygon segment's length then t
should be proportionally a value from 0 to 1/3, and if it fell between
the first poly len and the second then it would be proportionally a
value from 1/3 to 2/3, etc. The code might look like this:
I implemented this, and I'm not sure how to use this new approximation.
I mean, currently there are really two t's. The first one is the parameter
along the line connecting the 2 endpoints of the curve and the second
is the result that we return. We can't use this new approximation to
replace the first t, because for a curve like
(0,0),(1000,0),(1000,0),(1000,0) and a desired length of 500, the t
would be 1/6, so the computed (x,y) would be (1000/6,0) instead of
(500,0), which would be right (and which is what we compute now).
The only sensible way to use this kind of approximation would be as a
direct replacement for getTCloseTo. I tried that, and its quality to
speed ratio compared to getTCloseTo is remarkably good, but it's not
really usable because the differences are very noticeable.
I'll try to implement a good cubic root finder this weekend, and maybe
then getTCloseTo will be much faster and we won't have to worry about
this.
(Also, note that in the original code we probably would have just been
dashing along the flattened curve anyway and so we might have just
been
using the raw linear t in that case - so anything we do here is a
refinement of what we used to do and "icing on the cake" to some
extent)...
I'd say the dashing precision is better than what we used to have. It's
only slightly better, but even that is impressive when you consider that
we were doing up to 1024 subdivisions before, and now it's only 16, I think.
Regards,
Denis.
