- From: Ryan Arnold <ryan.arnold@gmail.com>
- Date: Sun, 12 Dec 2010 17:57:31 -0600
- To: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>
- Cc: www-svg@w3.org
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