# Re: animateMotion - specifying a start position along a path that is not the beginning of the path

From: Ryan Arnold <ryan.arnold@gmail.com>
Date: Sun, 12 Dec 2010 17:57:31 -0600
Message-ID: <AANLkTimLPve6CsjBvYyp7kBYtGUdUyhUY243fXxc0X6X@mail.gmail.com>
To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>

```2010/12/12 Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>:
> Hello,
>
> the example seems to be pessimised with scripting,
> therefore the example is presented as an empty file
> for me ;o)

I've only tested this in the Chrome browser so I apologize for the
inconvenience.

> However following your explanation my idea would
> be
> 1. to determine/calculate the length of the path and
> the lengths of each car as a fraction of the length of
> the path (if you have problems with calculation for the
> path, you can use stroke-dasharray to iterate it manually)

I don't understand how to use stroke-dasharray in this way but..

> 2. to use corresponding keyPoints and keyTimes
> (for each car the sum of the fractions of the cars before,
> respectively behind, depending on the order, see below)

I tinkered with this (any may end up using it for a positioning
circuit later) but I settled on the method you describe later...

> For a closed path it might be necessary to repeat
> the motion path to be able to provide keyPoints for
> one complete turn for every car.
> For an open path you might need additional motions
> (maybe discrete) to remove the cars from the path
> at the right time - or whatever might happen, if they
> are at the end of the path.

I suppose I can default the visibility to 'zero' until it gets to the
position I want very quickly on a positioning circuit, and then set
visibility="visible" for the remainder of the circuit.  And then dupe
the animateMotion and when the first circuit completes it'll cascade
into the second animateMotion which won't have a positioning circuit.

> It is maybe a good idea to to turn around the order of cars
> to get a simpler method to position the cars correctly
> with the keyPoints.

This seems like a very good idea, which I'll try.

> There can be more complications if calcMode is
> not paced or the lengths of cars change within the
> active duration.

Yes, there will be more complications based upon the tightness of the
turns, number of cars, terrain, increasing speed, etc.

> If you want to use your approach with different
> begin times (what could be simpler for several
> viewers/user-agents), the approach is almost
> the same, first the determination of the length
> of the path and the lengths of each car, then
> use corresponding vales for begin (active
> duration multiplied by sum for fractions of cars
> before).

Thanks to the SVG primer document pointed to by David Bailey and your
suggestion I've found that I can set the begin times of each car to
the begin time of the preceding car plus an offset of half of each
car's length (plus time/space for a coupling). Then I use the length
of the path to determine the offset between the cars.
This ended up working out well.

> If you agree to simplify the car presentation to a
> basic stroke (I like abstraction ;o),
> you can try to realise it with an animation
> of stroke-dasharray as well, avoiding advanced
> calculations of path and car lengths, fractions,
> keyTimes and keyPoints ;o)
>
> Olaf

The stroke-dasharray method sounds a bit scary :-)

I'll probably wrap this up into a little utility/helper lib for later
reuse and may write a white-paper on the techniques.

Thanks for the help!

Ryan S. Arnold
```
Received on Sunday, 12 December 2010 23:58:00 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:23 UTC