> Yep. I understand. With trails being only a segment of a pipe,
> longer or shorter based on speed I presume.

Each trail will be a linear spline if that's what you mean by
segment of pipe.  Its more then just the last cylinder on the
spline.  For now I'm assuming all the 'flyers' have a fixed
constant speed.  So if all started at the same time they would
all have the same total length.  The number of bends would
depend on the path they took.  The length of the individual
cylinders (what I think you may mean by segment) only
depends on the path chosen, not speed.  At some point I'll
play with giving the 'flyers' variable speed but I don't expect
that to be too hard once I've got the constant speed problem
fixed.

> As a bell... I'm just not thinking good this time of night. And
> I'm beginning to think this thread ought to move on to the
> general or advanced-users group.

Ok... Let me think of the best way to state this problem and
I'll make a post in the general group.  Its just that I consider
myself very new to this and I didn't think this problem was
as hard as I was making it.  Maybe it is.

> A motion spline and sphere_sweep can definitely be done,
> unchanging in number of points but changing vectors so that
> it moves away from its last position and stretching in a
> manner consistent with speed.

Yes... that's what I want.

> What I hadn't considered before is that you're intending to
> orient the objects in more than one plane so that the objects
> will have varying ups.

I'll be doing both.  I want to do some clasic Light Cycle
animations where they will be leaving trails on a 2D grid.
In those cases up will always be +y.  But I also want to
play with light flyers on a 3D game grid.  So I want to
solve the more general problem.

> But that shouldn't matter really. Hmmmm, before I forget
> what I'm saying I'll write it out in SDL form to make more
> sense of it.
>
> spline {
>     linear_spline
>     5,
>     t1,<x1,y1,z1>,
>     t2,<x2,y2,z2>,
>     t3,<x3,y3,z3>,
>     t4,<x4,y4,z4>,
>     t5,<x5,y5,z5>
> }

Yes... something like this:

spline {
  linear_spline
  5,
  0.0, <0,0,0>
  0.1, <0,0,1>
  0.3, <2,0,1>
  0.6, <2,3,1>
  1.0, <2,3,5>
}

Note:  its easy enough to choose the times and the segment
lengths such that the flyer will have a constant speed.

> So the variables would need to range farther apart as time
> goes by. Say all start at zero, next the 1's remain at zero but
> each of the others increase, with other t's always being of
> higher value than the previous. The xyz 2's through 5's
> would need to increase toward their intended paths while
> shifting from the 5's back toward the 1's as time goes along.

Ok... you lost me.  The path doesn't need to stop where it
started.  And the location of the bends is fixed.  And I assume
its ok to assume they'll all start at zero.  When I animate more
then one 'light flyer' though the paths should never cross so
they will be starting at different points.  The paths can be
chosen manually to assure they don't cross though.  To somehow
automate the process of path generation is more work then
I wanted to put into this.  It would be nice to be able to pull a
few paths out of the "3D Pipes" screen saver as that is the
effect I'm trying to copy but I can make my own.

> Just wish I were thinking more clearly to figure what would be
> the best way to do that.

Oh I've got some of my own ideas.  For the above 5 segment
path I could have 5 different sphere sweeps.  The first could look
like this:

sphere_sweep {
  linear_spline
  2,
  <0,0,0>
  <0,0,clock*10>

And have alot of If statements such the the above was only
used between 0 and 0.1 clock values.

But I want a macro that I can feed a series of points to and
have it do all that for me.  The above way would be a very
manual process that would have to be redone for each
different path.  I'm thinking surely there has to be a better
way.  Say I define the spline as path_1.  I'd like to be able
to do:

sphere_sweep {
   clock/1 of path_1

So when the clock has a value of 0.5 I'll get just the first
half of path_1.  After that's solved I need to be able to define
up as a function of clock.  Forward I see how to do.

Thanks,
Carl

Post a reply to this message