I have created an animated SVG that cycles repeatedly. Can I set the time so that when the document is first loaded, it is 50% through the animation and proceeds from there?
I use POV-Ray sometimes and I know that you can set the current clock value to between 0.0 and 1.0 in it.
Thanks.
Assuming that you are working with SMIL animation on an HTML page, I would let the animation start at minus half of the duration, e.g.
<animate ... dur="10s" begin="-5s" repeatCount="indefinite" ...>
The animation starts immediately, but in the middle of the "previous" cycle.
I am not aware of a clock value like in POVRay to jump to a certain time within an animation.
I hope this still helps, almost one year after the question had been posted.
Related
I am trying to create an button animation in unity
When i create the clip,
frame number stays on 60 by default
then i change the frame number, but after moving the mouse pointer it go back to 60
i tried in again again by deleting the clip and recreating the clip
but no effect
still the same
for better understanding
1. when i create the clip
2. changing the frame number 60 to 0
3. after moving mouse pointer it back again to 60
You're trying to change total frame number.
Yes, It's in Unity 5.6 and upper versions, so that can be confusing.
If you look above to your sample 60 bar, you can see a place where 0 is typed:
That's your current frame
and you can make your desired animation changing the current time frame.
That number is the Sampling Rate of the animation, i.e. how many frames of that animation clip are "executed" in a second.
60 means the animation runs at 60fps, or 1 frame every 16.6ms, so the general formula is:
Sample = Number of frames / second
Hence, you can't set that value to 0, an animation that runs at 0 fps is a still frame.
To get a specific frame of the animation, you need to move the red vertical line or click on a specific time on the timeline bar.
I'm writing a toy app to experiment with some Core Animation features, including animating along a path (that's where the Sun's movement comes in) and manipulating time.
https://github.com/boredzo/WatchCompass
(Never mind the button, which isn't implemented yet.)
The sun and watch face are CALayers, each containing a static image. The hour hand is a CAShapeLayer within the watch face layer, with its anchor point set to one end ((NSPoint){ 0.5, 1.0 }).
The sun is animated using a CAKeyframeAnimation along a path. The ellipse shows the path; you can see that they're not lined up for some reason, but that's a different question.
The hour hand's transform.rotation.z is animated using a CABasicAnimation, as described in this answer.
The problem—at least the one I'm asking about in this question—is the difference in duration.
Both animations are set to exactly the same duration, but the sun arrives back at its starting position a full two clock-hours before the hour hand does.
Of course, eventually the clock's duration will be exactly half the sun's duration (or its speed set to 2), since a clock only has 12 hours. If I do that, then the hour hand falls 4 clock-hours behind the sun, rather than 2.
So, given that both animations have the same duration, or the duration of the clock's animation is an even multiple of the sun's animation, why does the clock take longer?
For that matter, although I'm not complaining, why does the sun wait for the clock to catch up?
This appears to be due to the fact that you aren’t specifying a value for the keyTimes property of the keyframe animation. Per the documentation:
For the best results, the number of elements in the array should match the number of elements in the values property or the number of control points in the path property. If they do not, the timing of your animation might not be what you expect.
Indeed, setting keyTimes to #[ #0, #0.25, #0.5, #0.75, #1 ] appears to correct this.
I've been trying D3 for a day or two now. So I'm a D3 newbie but have lots of C/C++, Java, PHP, Javascript, etc background.
I started from the tutorials page github.com/mbostock/d3/wiki/Tutorials, and went fairly meticulously through
- Introduction
- Three Little Circles
- Thinking with Joins
- How Selections Work
first trying examples verbatim, sometimes trying different changes to see if I understand the results.
I then jumped to A Bar Chart, Part 1, and Part 2.
I ended up with results pretty much exactly as expected by the end of Part 2. The tutorial only has code fragments and I don't see a spot in the tutorial where it says "here is the full finished result you should end up with", nonetheless I end up with this http://jsbin.com/oqetuw/2/edit and it looks to be working identically to the tutorial.
Note for those who haven't tried this tutorial, the key points I'm asking about are the redraw interval, 1500 ms, the transition duration, 1000 ms, and the transition ease function, which the tutorial doesn't use or specify, but I've googled to find that it defaults to cubic-in-out.
As my goal is for a continuous smooth scrolling across the screen, I changed the redraw interval to 1000, and the transition ease function to "linear", and the result is here http://jsbin.com/ijumuv/1/edit
And these are the only changes as shown here:
$ diff tut2.09.html tut2.10.html
33c33
< }, 1500);
---
> }, 1000);
78a79
> .ease("linear")
82a84
> .ease("linear")
86a89
> .ease("linear")
The strange behaviour, and thus the question is, why do occasionally the bars that reach the left edge seem to bounce back and accumulate from left to right, behind the main bars? (and also occasionally get cleared)
Undoing only the 1500 -> 1000 change, the problem seems never to happen (so it is scrolling every 1.5 s, with each scroll duration being 1 s). So it would seem maybe if D3 is busy still doing the transition, it fails to remove them? or some other explanation I can't figure yet.
Thanks in advance for any tips.
Yeah, there are issues with d3 transitions. When the interval and duration are both 1000, there is high chance for the redraw operations to occur before the prior transition() on that selection is finished. And that messes with the data binding, or something along those lines.
I modified your code such that it continuously checks whether the previous redraw transition has finished before calling the next one. This is by no means "good javascript", but it does illustrate the issue, and some way around it. To understand what I added, just look for all occurrences of __readyForNext in the code. It should make sense.
In a force layout, I'd like to slow down the animation when two distant nodes are linked.
For example: if I have 2 nodes that are 400px apart and a link is established between them (after the inital tick has completely cooled down), I'd like to link to start at 400px and then animate down towards say 100 (or as standard link distance is set).
You can set the linkStrength to a lower value to make the linking less abrupt. Like so:
force.linkStrength(0.1);
linkStrength is a value between 0 and 1.
https://github.com/mbostock/d3/wiki/Force-Layout#linkStrength
Say I want to animate a ball rolling 1000 pixels to the right, specifying a timing function in the process – something like this:
UIView *ball = [[UIView alloc] initWithFrame:CGRectMake(0,0,30,30)];
CABasicAnimation* anim =
[CABasicAnimation animationWithKeyPath:#"transform.translation.x"];
anim.toValue = [NSNumber numberWithFloat:ball.frame.origin.x + 1000.0];
// move 1000 pixels to the right
anim.duration = 10.0;
anim.timingFunction = [CAMediaTimingFunction functionWithControlPoints:
0.1 :0.0 :0.3 :1.0]; // accelerate fast, decelerate slowly
[ball.layer addAnimation:anim forKey:#"myMoveRightAnim"];
What I ultimately want is to have a method, say -(void)animationProgressCallback:(float)progress, be called during the animation, in regular intervals of the animation's progress in terms of the absolute "distance" between start and end values, i.e. ignoring the timing function.
I'll try to explain with the above example with the ball rolling 1000px to the right (charted by the y axis, in our case 100%=1000px):
I want my callback method to be invoked whenever the ball has progressed 250 pixels. Because of the timing function, the first 250 pixels might be reached in ti0=2 seconds, half the total distance reached just ti1= 0.7 seconds later (fast acceleration kicks in), the 750px mark another ti2= 1.1 seconds later, and needing the remaining ti3= 5.2 seconds to reach the 100% (1000px) mark.
What would be great, but isn't provided:
If the animation called a delegate method in animation-progress intervals as described, I wouldn't need to ask this question… ;-)
Ideas how to solve the problem:
One solution I can think of is to calculate the bezier curve's values, map that to the tik values (we know the total animation duration), and when the animation is started, we sequentially perform our animationProgresssCallback: selector with those delays manually.
Obviously, this is insane (calculating bezier curves manually??) and, more importantly, unreliable (we can't rely on the animation thread and the main thread to be in sync – or can we?).
Any ideas??
Looking forward to your ideas!
Ideas how to solve the problem:
One solution I can think of is to
calculate the bezier curve's values,
map that to the tik values (we know
the total animation duration), and
when the animation is started, we
sequentially perform our
animationProgresssCallback: selector
with those delays manually.
Obviously, this is insane (calculating
bezier curves manually??) and, more
importantly, unreliable (we can't rely
on the animation thread and the main
thread to be in sync – or can we?).
Actually this is reliable. CoreAnimation is time based, so you could use the delegate to be notified when the animation really starts.
And about calculating the bezier path... well look it this way: It could be worse if you would want to implement a surface in OpenGLES you would have to calculate a Cubic Bezier!. lol. Your case is only one dimension, is not that hard if you know the maths.