Looks awesome, but tens of seconds need to morph faster. By the time 4 is clearly formed and visible seconds read 48. While continuous motion is aesthetic, it is hard to tell time.
It looks like it uses linear interpolation between the different glyphs, which makes it look a bit jerky. The author might want to try a sinusoidal interpolation so that velocity reaches zero at the key frames and the whole thing thus spends more time dwelling on the legible parts of the animation and looks smoother.
One trick I've noticed to make animations/transitions "snappier" and more natural is to use quadratic/square (power of 2) scaling. For fun I did it on this clock just saving it locally - you can do it by modifying line 140 of `bezier_clock.pde` to square the ratio instead of simply assign it:
animationRatio = ratio * ratio; // can also replace with sqrt(ratio)
Again, just makes it a little bit 'snappier' (remember you have to hit spacebar to turn on continual animation), and scales it so you can determine the numbers a bit more clear earlier in the cycle because of the scaling on (0.0, 1.0]. This is certainly a fun piece of code to play with.
I've updated it with quad, cubic and sinusoidal modes. They all look good. Only problem is that because it's no longer linear, the various points can change at different rates and thus create 'kinks' in the curve. When it's linear, the 'line points' and the associated 'control points' are always in a line locally tangential to the curve (don't know the proper terminology but hopefully you understand).
That shouldn't happen if you do the motion transform uniformly on all axes. It should just be equivalent to changing the speed of time, rather than actually changing the trajectories.
Fun. I'd say you should have every number at x/60 or whatever of the way between first and next state, including hour and such, but that would probably just result in a bunch of unrecognizable squiggles.
Wow, that's awesome. Reminds me of Timely Alarm Clock[1] which I use every day and still tout as probably the single most beautiful Android app ever.
However, for this Bézier clock, it would be more practical if the animation was finished before it had to change again, so that we could read the numbers.
Seems like open is a requirement, since not all the numerals are closed and I'm not sure how one would morph between open and closed spines. Playing around here (http://www.victoriakirst.com/beziertool/ anyone know a similar tool that has bookmarkable results so we can share work?) I'm thinking three control points should be achievable (haven't found a way to make a nice looking 4 yet, but most other numerals aren't that hard to pull off).
I'm curious about the code organization: it seems that processing.js contains both the application code for the clock as well as the libraries for interpreting the Processing code. Is that true? Is that the best organization? Would it not be better to have have a processing.js which is the interpreter/libraries and a bezier_clock.js?
Per the Processing.js site, you include the processing.js file and then set an attribute on the canvas showing where to get the PDE file (your code). In this case they set it to: data-processing-sources="bezier_clock.pde"
72 comments
[ 3.5 ms ] story [ 130 ms ] threadIf you've got an extended clock (days, months, years, centuries, millennia), morphing could take a while.
It looks like it uses linear interpolation between the different glyphs, which makes it look a bit jerky. The author might want to try a sinusoidal interpolation so that velocity reaches zero at the key frames and the whole thing thus spends more time dwelling on the legible parts of the animation and looks smoother.
edit: thanks
http://www.robertpenner.com/easing/
edit: oops, RTFM devin
Edit: oops, three of us got here at the same time
[0]: https://play.google.com/store/apps/details?id=ch.bitspin.tim...
[1]: http://p5js.org/
However, for this Bézier clock, it would be more practical if the animation was finished before it had to change again, so that we could read the numbers.
[1]: https://play.google.com/store/apps/details?id=ch.bitspin.tim...
So pretty.
'nuf said.
Did it in about 12 hours for a Google I/O competition 3 years ago. It's a countdown clock instead of a normal clock, but similar idea.
I'll throw mine in too then – an "analog" clock drawn by 64 fast-moving LEDs: http://www.thisissurreal.com/shai/hologram/hologram.html (clock is at the bottom)
Uncaught SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document. processing.js:9503
Not sure why processing.js needs local storage to work.
I'm curious about the code organization: it seems that processing.js contains both the application code for the clock as well as the libraries for interpreting the Processing code. Is that true? Is that the best organization? Would it not be better to have have a processing.js which is the interpreter/libraries and a bezier_clock.js?
Making the sources to the clock available here: http://jackf.net/bezier-clock/bezier_clock.pde
http://www.animaclock.com/
http://www.animaclock.com/viewfont?font=anifont4_bez&clean=1...
http://www.animaclock.com/viewfont?font=mrcl_kk_ghost&clean=...