Articulated Line

[Hey Ken]

Wapperdude:

   You cannot imagine how big a smile I had when I saw those arrowheads tracking so nicely with the line segments.  But I can bet you can imagine my bewilderment when I looked at the shapesheet!  And my degree is in Physics, so you’d think I’d be more comfortable with all the trig.  It’ll take some doing before I figure it all out, but at least the solution is there.  An interesting problem for sure, and it appears you’ve spent as much time on it as I have.  You can get some sleep, now.  ;- )

   - Ken

[wapperdude]

The joys of being retired.  I don't have a steady job that dictates my time schedule.  But having been an engineer, doing circuit design (custom IC's) for 42 years, there's still this need to solve intriguing problems.  This one was fascinating because of the sliding arrowheads.  Your approach gave me enough "outside the box" perspective to tackle this. 

I'm going to repost the solution here, I changed the angular "results" from "Direct" and "Calculated" to "DirX" and "DirY" as being more meaningful.  That is, if "DirX", then the AH2 control's Xpos is derived directly from its actual location, and the Ypos is calculated.  But, if "DirY" is the result, than the Ypos is derived directly from location and the Xpos is calculated.  The results could have been more easily "1" and "0", but that's not very instructive.  However, using the Boolean results would have eliminated the "Strsame" function in the AH2 control cells.

Another FYI note:  for the Controls.AH2, the direct calculation uses the setatref functions, and the calculated position calls an User.CalcAHD2 formula.

Wapperdude

[Hey Ken]

Wapperdude:

   Thought you might like to see the context that drove my need for an arrowed articulated line.  Sadly, I have not had the chance to generalize your solution into a reliable packaged product (it still has some interesting behaviors in some corners of its operational envelope), so I’m still building things manually.  Someday, perhaps, in my copious free time.

   You’ll also notice an additional need for the articulated line to branch out into multiple endpoint lines.  But once the basic articulated line is tamed, it should be trivial to expand its functionality to fan out the ending segments.

   Another item that calls for a solution are the barrels you see in the sanitized JPEG.  When I change the height or width of the entire barrel, the height of the not-oval at the top also changes.  My goal is to keep the height constant regardless of topological changes to the overall shape.  I’ve played with it on occasion, but never managed to get it right.  There are numerous examples of database symbols on various stencils that can come close to what I need, but none of them retain a constant height of the not-oval when adjusting either the overall shape height and/or the width.  Sure wish I knew someone who was retired and likes to take time to “solve intriguing problems”.  (Hint, hint.  ;- )

   - Ken

[wapperdude]

Fascinating!

My first thought for the barrel problem would be...
1) make the oval as a separate geometry section
2) let the width be controlled by the overall shape
3) oval thickness options
        > use literal dimensions, not based upon geometry
        > use a fixed ratio of the width
        > use setatref with 2nd option to allow settable ratio (control point, data entry)
4) the upper end points of the vertical sides and the horizontal oval inflection points must "tied" together

Hope that helps

[wapperdude]

Here's simple cylinder implementation.  Has placeholder for oval thickness...User.Thk.  You can treat that however best suits your working style.      

[wapperdude]

Well, that was too simple.  Kinda misbehaves with changes to oval height.  So, here's an update.  Seems to behave better.  The culprit is the DCell in the elipse geometry rows.  Took Excel analysis to curve fit the DCell values.  This seems reasonably close with a 4th order equation.  Whee!

It allows the oval height to be set via shape data.  Double click the shape to get the entry form.

Wapperdude

[wapperdude]

Free time!!!  Did you say FREE time!?!

Well, pardner, let me tell ya...

Attached is 3 segment version of the loquacious line shape.  It also has Action menu to show either 1, 2, or all 3 segments.  I've not noticed any unusual artifacts with this.  Please let me know.  Hmmm, is this a tax deductible political contribution? 

Just asking.

Your lucky day... 2 out of 3 issues addressed (and solved???).  Good thing for free time.

Wapperdude

[wapperdude]

.and here's a triple ending...

[Yacine]

@Wapperdude,
I also suffer from free time .

Had a look at your cylinder and was rude enough to think it could be improved.

Added a property angle to define from which angle the cylinder is seen. This way you can set the proportions of the ovals (x/y) to depend only on the width and the angle.

Did also add a control point to adjust the angle, but realised that it would end in a "ref-stuff" issue. May the "Master of references" have a look at it ? (change prop.angle via the control point, while keeping the angle connection formulas set)

[wapperdude]

@Yacine:  Not rude.  There's no exclusivity.  Besides, it's always nice to have options.  The group approach is nice and clean.  So, HeyKen has two solutions:  one "integrated" and one grouped.  Both work.  Your approach is clearly easier to understand how it works. 

Yeah, I hate that group - subgroup reference thing.

[wapperdude]

As I thought about it, there's no reference issue with the Cntl Pt, everything is done at group level.  I modified your first shape to allow docmd(1312) and made it group only selection.  Oh, removed the control point.  Duplicated it, and made a Cntl Pt only version.

The attached file has all three versions.

[Yacine]

@Wapperdude,
this is not really what I meant.
The control point shall define the view angle. The height of the oval is a function of the width and the angle ( = width * sin(angle)).
Now the control point being in the Y cell, to better show the correlation oval "height" to angle, depends on the height of the cylinder.

You could now set the angle as function of the control point alone, but you wouldn't be able to set its value manually in the shapes data.
That's where your "REF" wisdom could come in the game.
Cheers,
Y.

[wapperdude]

Hmmm.  Now I am confused.   I thought the control point goal was to provide another means of entering the angle in the sine fcn.  Anyway, that's what I implemented.  Thought it was too simple to be the solution.  Ah, the light just went on...I didn't check this, and I'm not at my computer.  But as implemented, the angle changes as both function of c control point and changes in height...oops.

Ok.  That should be solvable with settler.  Doh!  Simple indeed!!!     My bad.   

[wapperdude]

Error corrected!

[wapperdude]

Well, Yacine's control point idea is convenient, so, added it to my original shape.  Plus, improved the elipse curvatures as elipse height / angle is varied.