hi,

"Bald Eagle" <cre### [at] netscapenet> wrote:
> "jr" <cre### [at] gmailcom> wrote:
>
> > one question is: in the #for() loop near bottom, you test for IFlag and OFlag.
> > naively, given two circles A + B which do not touch/overlap, you always get 4
> > tangents, no?  by mandating "sane" scenarios you might be able to get rid of
> > some conditional code.
>
> Right, but computing the arcs and tangent lines wasn't meant to solely address
> the "belt/pulley problem" - the point was to get tangent lines to circles to
> design a prism.  I don't much care about the conditional code, and it all seems
> fast enough, especially since it won't be in a loop that gets executed 1000
> times.
>
> It would also be nice to have a block of code that doesn't crap out if the
> "wrong" data gets entered into the circle array.

that's kind of what I meant by "sane".  should be easy enough to write a bit of
code which checks the input arguments.

I think the existing macros/code can easily be "wrapped" in two distinct,
specialised macros: one to make prisms, the other for pulley systems.

> > the comments in the code suggest that you can "classify" the tangents (order +
> > direction) and used colour to see that info; is that code available too?
>
> Right.  If you look at the original thread, ALL the tangents and arcs get shown.
> Then you can eliminate the tangents that don't apply, and then with only two
> endpoints on a circle, you can then highlight two discrete arcs to choose from.
> Then you can select/correct the direction so that the ordering of the points to
> generate the prism is correct.

all the arc stuff is missing from the code, as posted, though.  ;-)

> Let me see where I'm at with that scene file - just put it back on my radar if I
> don't get back to you on it in the next week or so.
>
> > > Certainly I'd love to work out the logic of animating it, and doing something
> > > like a toothed belt or chain to run along gears or sprockets.
> > given knowledge of radius of A, and the number of degrees it revolves from one
> > frame to the next, it would just require to map that length of arc to B to get
> > the corresponding angle (not that I could actually do it).
>
> That's great for - one arc.  Now picture 5 pulleys and you want to highlight one
> link in the chain and follow that around the whole system.
>
> It's sounds - excessive to do, but from an animator's standpoint - to give the
> viewer that visual cue with which to infer motion and direction... it makes a
> BIG difference.

number of pulleys is a bit of a red herring.  for me, the focus is (ought to be)
on the chain/belt/cable.

say you have a structure like

#declare D = dictionary {
  .pulleys:  array {
               array mixed {<x,y,z>, r, cc, texture{}},
                 ...
             },
  .route:    array {3,1,0,2},
  .ndegree:  n.n
};

then "only" .route needs processing, and the belt gets "threaded" according to
pulley index and counter-clockwise (cc) flag; assuming .ndegree is number of
degrees first pulley turns per frame all other pulleys can be derived knowing
the frame number.  and some other keys for belt texture, start and end points
(if provided draw a cable), etc too.

but I just read Leroy's post, and while I've no idea of the complexity involved,
having one mesh vs many separate parts does sound good/better.

> > I hope I can make some headway understanding the code, and hopefully learn how
> > to "assemble" the correct tangents into a belt or cable.  I probably won't be
> > able to avoid stumbling into problems.  :-)
>
> Well in that end section, there's the parts that control the outer tangents, and
> the inner tangents.  Just change "pigment {LinePigment}" into something
> different for all 4 lines, and you'll see exactly which one is which.

now the main "problem" is not having a code example to glean the usage of the
Bezier_* macros to shape the connecting arcs.


Leroy:

your code is compiled for Windows, which I do not have.  have you published the
source?


regards. jr.

Post a reply to this message