Bezier "bendiness"?

Hey Dimiter!

[check your mail]

That;s effectively what I initially proposed. Integrate d2 and you end up with tangent. Evaluate tangent at start and end of curve. Difference between them is angle "displaced".

The tangent of a cubic bezier at its endpoints is trivially available.

The problem is that you don't know if the curve "changed directions" (and how *many* times it did so!) between those two points.

The scheme I proposed identifies the points where the curve changes direction (poor choice of words). With it, you can cut the cubic bezier into 1, 2 or 3 adjoining curves each of which bends in a single "direction".

You can then "trivially" compute the angle displaced in each of these curves and sum them (adjusting signs as appropriate).

It also lets you identify points where cusps may exist at which the derivatives go to hell. With knowledge of which way the curve was "bending" before this and *after* this (i.e., the two "subcurves" on either side of that point), you can give a rational interpretation to what the curve is doing *at* that cusp (instead of just letting the math blow up).

This assumes that "total absolute angle displaced" is a good choice of implementation for "bendiness". (I have yet to convince myself that it is the *best* choice)

Reply to
Don Y
Loading thread data ...

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ that's a good way to express it to relate it to my use of the term "effort" (though some appear to take issue with *my* use of the term "follow" :> )

I don't *dislike* it.

I posted a proposed definition for a way of quantifying a

*bogus* characteristic that I called "bendiness".

I posted an algorithm for computing this (would pseudo code have helped?)

The purpose of the post was:

- to see if others could come up with a better "definition" for this bogus term (not just a "quantification")

- to see how people relate to the *term* "bendiness" (i.e., I am firmly convinced that I would have less trouble explaining it in a bar room than I have had, here :> )

- to see if another "definition" might have a better *implementation*

- to see if the implementation I proposed had any holes in it (i.e., cases where it falls apart)

E.g., I've outlined other sorts of metrics that could be used to try to describe the "non-straightness" of the curves. And, the problems that I saw in the actual *use* of those definitions -- where they "fell down" in practice. This one "seems" to be the best possible -- given the audience constraints I laid out. (?)

So far, the comments have been "why don't you compute it

*this* way, instead". But, I don't see that they've thought through the *mechanics* of those computations to see how they differ from what I am proposing (I believe my math should be simpler/cleaner and more intuitive) [at the very least, my approach has a certain elegance to it in that it decomposes beziers *into* beziers -- albeit "better-behaved" ones!]
Reply to
Don Y

Did you forget to mark this as "off-topic"? For this and similar posts, I would suggest you create a group called "Random thinking aloud by Don Y".

Reply to
Bob

would suggest you create a group called "Random thinking aloud by Don Y".

Because it is *not* off-topic.

*I* use this METRIC (i.e., computed numerical quantity) in my gesture recognizer (you may have heard of gestures? some folks use them in things like, oh, let's see, tablet computing, cell phones, etc.) and a colleague is exploring the use of similar metrics in evaluating CNC "programs" (tool trajectories).

Last time I checked, both of these sorts of application domains fall under the heading of "embedded systems"...

Just because *you* can't wrap your head around it doesn't mean it's "off-topic"...

If this sort of thing bothers you, add my name to your kill file. Note that I am very consistent about how and where from I post -- so it's VERY EASY to avoid my posts (if you simply can't discipline yourself to avoid *clicking* on one!) :>

Reply to
Don Y

The notion of treating the "bendiness" as the total acceleration needed to follow the curve at a fixed (forward) velocity (obviously divided by the length of the curve) would seem to produce fairly intuitive results.

For example, a path with four alternating 90 degree left and right turns, comes to the same value as a circle of the same radius.

A curve with a tighter radius rates as bendier.

A shorter curve with the same total "bending" is bendier.

Visually there might be scale issues, for example, if a curve was made of a very large number of alternating very small bends, it might look less bendy at a macro scale than (say) a circle of equivalent radius, but certainly when the view is zoomed in the wiggle would be obvious.

As an intuitive comparison, this would be exactly equivalent to the amount of acceleration ("delta-V") a space ship in free fall would need to follow the curve (again, you'd divide that by the length of the curve for the actual metric). And it seems that this results in an obvious explanation of "how hard it is to follow the curve" as being the measure of bendiness. Of course other physical vehicles would have the same result, but the complexities of the interface between (say) the wheels of a car and the road would certainly obscure things a bit.

As far as I can seen the annoyance of integrating an abs() is the major downside to this. Not that it's hard, but it is going to be a bit tedious, although if you're assuming Beziers, the number of zero crossings of the second derivative is strictly limited by the number of control points.

Reply to
Robert Wessel

This is what I *don't* like about it -- it ties in "size". E.g., the diameter of a circle shouldn't affect the "bendiness" metric, only the "size" metric (whatever *that* might be...)

This is why I like the "total abs angle" approach -- it ignores arc lengths, etc. O and o are equally bendy. It ignores the magnitude of the tangent vectors and just looks at their actual angles.

But, I like the *explanation* in terms of acceleration.

I.e., it's hard to come up with a metric that "feels right" and also has a "rational, technical basis" that *feels* just as good! :>

Of course. I am trying to make a verbal analogy that makes sense of a bogus term :-/

And, the analogy implies certain other issues (e.g., scale): one would find the effort to follow a 3 ft diameter circle in a boat to be considerably harder than following a 3000 ft diameter circle in said same boat! :>

Yes. The difference between integrating d2 and the "total angle" approach is d2 is a linear function so only has two *possible* ranges over which it has to be evaluated -- total angle has three.

Dunno. What I should do is instrument the little "drawing" application that I wrote so that it shows me these metrics

*as* I interactively modify individual curves. So, I can see where they produce significantly different results and see which seems more intuitively correct.

Actually, this is *exactly* what I should do!! And just plug in the various implementations for metrics that I'm considering so I can empirically evaluate them! (assuming I can imagine all the appropriate degenerate conditions for each metric!)

[that's the problem with beziers... you look at a couple of control points and it doesn't tell you anything about the curve *unless* you actually "draw" it! I imagine you could develop an intuitive feel for it, given time. OTOH, I have no desire to make a *career* out of visualizing beziers in my head! :> Solve the problem, document it and move on! ]
Reply to
Don Y

It is obviously off-topic. Or are we to allow discussion about games, since Angry Birds runs on smartphones?

Don, you are a persistent offender when it comes to off-topic posts. Recently you have generated over 100's posts on topics such as gestures, documentation and programming techniques, none of which are specifically to do with embedded programming.

I am quite bored of you treating this newsgroup as your personal sounding board. In future, I will not hesitate to flag your posts as spam.

Reply to
Bob

*HOW* is it off-topic?

I want to recognize two shapes as being similar. One

*defining* a template for a particular "gesture" -- the other an instance of live data from a user. Based on which, if any, template the user's live input matches, a motor will drive a mechanism one way, the other way or cause it to be disengaged.

You could similarly use the recognition of that gesture to dial a predefined user from your phone book.

Or, enlarge an image currently displayed on a screen.

Or...

It is not only appropriate to embedded systems but, also, REAL TIME embedded systems since there are timeliness constraints on producing a valid result -- the user won't wait more than dozens of milliseconds for you to have made a decision regarding his gestural input! (i.e., choice of algorithm is very significant)

Do you truly NOT see the difference between these two issues? Do you think S Jobs yelled at the folks writing his recognizers accusing them of PLAYING GAMES (Angry Birds)? Wouldn't you consider it a key part of the iPad/iPhone user experience?? (or, do you not consider an iPad/iPhone to be an embedded system?)

Let's turn this around. Why don't you enumerate which input modalities we are allowed to discuss, here. Can I describe the hardware to scan a keyswitch matrix? And, the algorithms to decode which, if any, keys are currently depressed? Do I, instead, have to assume keystrokes arrive over a serial interface? Or, over a network interface? (But, gee, desktop machines use networking so that must be an off-topic issue so not suitable for discussion here)

Or, perhaps, only whatever mechanism *you** use is considered appropriate for discussion?

Google claims that I have originated the following threads "recently" Bezier "bendiness" "ethics" of forced supply purchases Documentation containers Deferring media removal Renegotiating "contracts" Way OT: Wackiest movie, ever! USB Hub SNAFUs Apologies if I've missed any...

*How* do they pertain to embedded systems?

- Bezier "bendiness" I've described this already. If you've never dealt with a feature-based recognizer, google "Rubine". If you've never dealt with a gesture recognizer in an embedded system, borrow someone's iPhone. (note gestures are not the same as "handwriting"/writing -- see how many different input modalities you can IMAGINE for a gesture recognizer! :> )

- "ethics" of forced supply purchases I have to take a stand on whether to recommend designing a product with supplies INTENTIONALLY created to be "sole source" and, whether *we* should be the sole source supplier of those supplies vs. letting or encouraging other vendors to take on that role (or, use some existing, non-proprietary supplies). Perhaps you're just a programmer and aren't involved in the hardware design of the devices that you produce. Even so, you should realize that whether the device has a *readily* user-removable battery plays a big role in how you program the device to "tolerate" its removal. Or, a proprietary MEMORY MODULE. etc.

- Documentation containers How do *you* document your products? Both for other developers that follow behind you *and* your customers? How would *you* explain the functioning of a gesture recognizer? The audible qualities of a speech synthesizer? (perhaps you believe only desktop systems can use speech??) Or, don't embedded systems need documentation? Perhaps mimeographed sheets??

- Deferring media removal How would *you* implement a 16GB DBMS on a handheld device intended for use in rugged environments? Would you just write "FRAGILE" in big letters and hope the user didn't DROP it (i.e., rotating media)? Would you use solid state media and constantly flush all writes to the media (so it could be removed WITHOUT deferral)? Then, how would you address the durability issue for that media? (your solution: redefine it as a NON-EMBEDDED application and wonder why the user dragged the device out into the field!)

- Renegotiating "contracts" How would you allow a service running inside a device to renegotiate it's contractual requirements with its clients? Since you don't consider this an embedded systems issue, I feel pretty sure you *don't* use this level of sophistication in your designs.

- Way OT: Wackiest movie, ever! I *clearly* marked this as "off-topic" -- WAY off-topic!

- USB Hub SNAFUs OK, *I* had a hub issue. I solved it (as I stated in my post). But, it got me thinking about how *my* USB stack will interact with other devices (hubs) that the user can opt to attach to it. Or, aren't embedded systems allowed to be USB masters? Or, perhaps, not allowed to support *hubs*??

Are these all unique *solely* to "embedded programming"? No. Of course, the charter doesn't restrict topics to "embedded programming" but, rather "embedded systems development". So, I guess talking about *hardware* shouldn't raise any eyebrows (and consequences thereof)

What, *specifically*, do you consider the domain of this newsgroup? Can't talk about sorting algorithms -- because those aren't "specifically to do with embedded programming". Heck, can't talk about *any* algorithms because an algorithm could conceivably apply (or be applied) to a non-embedded system!

Please feel free to do so! From where I sit, your comments seem to convey a "failure of imagination" -- expecting all embedded systems to fit some nice, "vanilla" concept that you've internalized. Do I have to begin my posts by "setting the stage" for how the question I am about to pose DOES apply to embedded systems? My posts are already lengthy/verbose as it is -- you want me to make them even LONGER so you can figure out which cubbyhole to file them under?

Some of us actually work on interesting projects! Hopefully you'll get a chance to do so, someday! Instead of thinking, "what the heck is this guy rambling about?" or "this guy doesn't know what the heck he's talking about!", you might want to, instead, ask yourself, "gee, what the hell is he working on that would cause him to be concerned with this issue? what have *I* NOT considered?". You might actually get exposed to something new! *Or*, be able to expose *me* to something new (hint: I only pose questions after the folks that I regularly correspond with have run out of ideas).

Or, just use your killfile.

Reply to
Don Y

You really can't have the concept of acceleration without taking into account the radius of the bend. But it really seems like you should - after all, consider a long bit of string on the floor with a very loose knot in it - or the same string with the knot pulled tight. I'd certainly consider the latter to be bendier, even if they're topologically equivalent.

And that's an area you consider exploring - I'm sure the topologists have a number of formal methods beyond the elementary notions of deformability to describe similarity.

And, of course, the inevitable topologist joke: "Why don't topologists wear gloves? Because they can't tell their right glove from their left glove."

Reply to
Robert Wessel

Hi Robert,

Correct. Which is what I dislike about using acceleration. :<

I see them as largely scale issues (in practical terms).

When I (informally) quiz friends and associates with casual examples (they all already know I'm eccentric :> ), they don't seem to relate size to bendiness. I.e., a large/small C invariably is regarded as less bendy than an S -- regardless of which is physically larger/smaller.

[Keep in mind, I am not constrained to the sorts of shapes I can easily represent with a "glyph" in a USENET post. This may be a factor in their evaluations -- it's a lot harder to draw an EXTREMELY "bendy" curve on a small scale so I think they subconsciously factor the size out of their evaluations. Its as if they count the number of "bumps". Or, how far "around" the curve bends. etc.]

I've seen some research where they try to quantify "deformation energy" (which sounds just as bogus a term as my "bendiness" :> )

The challenge is to come up with a metric that non-technical users can "relate to" -- something that they don't NEED to "question" ("why is that small s bendier than this large S?"). Putting numbers on it just makes it harder, still: ("why is that *3* times bendier than this?")

I have an application that I wrote that lets me play with bezier's interactively (many CAD and drawing programs do, as well -- but, they don't spit out coordinates of {control,end}-points readily!) I've been making a list of various ways of quantifying bendiness (and, other characteristics).

It should be relatively easy to add a framework to the drawing application that will invoke a list of such metrics and display their computed results in real-time. I can then get a feel for how well each correlates with particular curve shapes. Especially, any counterintuitive results (i.e., this *feels* bendier yet the metric went *down*).

Once I've got a feel for how various schemes correspond with particular curves, I'll reimplement a select few with an eye towards efficiency (gesture recognizer needs to be *fast*) and see what their relative *costs* are. Hopefully, the "goodness" of the metric will also be the *cheapest* metric -- but, I don't believe in Santa Claus so I'm not holding my breath on that score!

Actually, I thought it was because they couldn't decide whether it goes on the *inside* of the hand -- or the OUTside! :>

Reply to
Don Y

Yet if you ask them about driving a car down a road with long gentle curves, or a road with the same number of short radius curves of the same angles, they'll all rate the latter "bendier." Even if they drive the second course at a lower speed (most drives will probably drive the two courses at equal lateral accelerations, varying their velocity to maintain that). So obviously this is at least somewhat application specific.

There are going to be issues trying to make things intuitively obvious to people who don't actually understand what they're looking at.

Reply to
Robert Wessel

Yes, but this implicitly relates the curves to their size, etc. I think it is easier for people to "distance" themselves from two abstract "curves" that they are viewing from a pseudo-omniscient perspective. It's easier to imagine the same curve "off in the distance" or "up close" -- to intrinsically feel they are the same curve (since they are!) just viewed from different references.

I.e., if you view a tall, slender person up close or from afar, you would still call them "slender" (tall varies with distance, slenderness? doesn't)

Hence the need to come up with a definition that fits *their* idea of "what they are looking at" and not a "mathematician's".

Let me see what the numbers associated with each "algorithm" yield and see if they "feel" rational. (I guess I could install this on a PDA/Phone/Tablet to make it easy to show to others: "This curve has a of X. This other curve has a of Y. What do you

*feel* the for *this* curve would be?"

And, tabulate the number of blank stares and "approximately correct" replies...

Reply to
Don Y

Grrr... by "their size" I mean the occupants of the car (not the curves themselves).

Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.