thanks for the feedback Sean. Specifically I was looking for better solutions to finding points of inflection or maximum deviation from the approximate biarc.
I've added HIDDEN to all the auxillary functions. I agree that the bezier_inflection() function needs work. the current version was a rough idea that would "just work", but it can certainly be refined. I'll consider your suggestion to adaptively step based on the derivative. For the recursive subdivision in approx_bezier(): I found an error in my algorithm (which was supposed to be the S4 strategy mentioned in the paper), approx_bezier() was dividing the bezier at EVERY interval point which deviated by more than tolerance, and was producing 249 carc_segs for the first example bezier used in the paper (their algorithm produced 6-8 for the same tolerance). I changed to the S2 strategy (maximum point of deviation) and the number of carcs dropped to 9, which is much more reasonable. Again trying S4 (first point of deviation greater than tolerance), but correctly, produces 12 carc_segs. I'm not sure if using EQUAL to test the deviation would be a good idea, because the deviation may be more than tolerance at some point but wouldn't necessarily ever be EQUAL at any point, unless I'm misunderstanding. On 07/16/2012 11:50 AM, Christopher Sean Morrison wrote: > On Jul 13, 2012, at 10:16 PM, crdueck wrote: > >> I'd like some feedback on the new functions, in particular >> bezier_inflection() and approx_bezier(), which both use an iterative >> method to walk the curve. > What sort of feedback? Coding-wise, there's a ton of functions in there that > need to be labeled as HIDDEN (static) so as to not explode librt API. The > calculation of the inflection point and the recursive subdivision are rather > flimsy given the fixed step size. That'll likely be a problem for > high-curvature / complex bezier curves, but it's certainly acceptable as a > first solution. You'd probably want to adaptively step based on the local > derivative. > >> currently, bezier_inflection() returns the first point where the >> curvature vector evaluated at that point has greater magnitude than the >> curvature vector evaluated one half interval forwards, which doesn't >> seem very elegant or precise. Is there a better way to find a point of >> inflection on the curve? > good question. :) > >> similarly, approx_bezier() walks the curve in intervals, and computes >> the minimum distance from the approximating circular arc to the bezier >> curve evaluated at the interval. Is there a better way to determine when >> the two curves diverge by more than a given tolerance? > Other than the fixed interval size, that sounds like a pretty good solution > to me. You might want to calculate *below* the distance tolerance instead of > halting at/near it. You could either add an EQUAL() test or even use > something like half the distance tolerance. > > Cheers! > Sean > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats.http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
