paperJS (paper.js) JavaScript Library walk through by Brett Paufler - 9-10-13
JavaScript Tutorial & paper.js primer


This does exactly (exactly) what I wanted it to do and it just didn't take that long to code.  It's a chain of thirteen (count them, thirteen), but it could be a chain a hundred items long -- the animation would just move slow, but coding it wouldn't be any harder.  The center of the next item in the chain rotates around the radius (an endPoint) of the previous item.

To creat the objects, I used a for loop.

This line of code creates an array to hold the Path.Star objects.  An array is ideal as its contents are easy to cycle through utilizing a for loop.
var myStar = [];

This next line of code assigns a shorter name to one of my pr-existing variables, nothing else.  It's for convenience.  squareScreen is a variable I put in my default code that tells me the maximum square I can place on the viewer's screen (the viewer's screen being the size of the canvas).  halfSquareScreen is half that size (the size of a circle's diameter that the user would see all at once.  And hSS is the same as halfSquareScreen.
var hSS = halfSquareScreen;

The next few lines of code sets up the for loop.
for (i = 1; i <= 13; i++){
    myStar[i] = Path.Star(CP, 5 + i, hSS/(4 * i), 1);
    myStar[i].strokeColor = 'black';

This is the barebones basic of a for loop:
for (i  = minVal; i <= maxVal; i++){
    // code to be iterated over
Note, I haven't defined either minVal or maxVal in my code, these are just placeholding variables, but for loops will work with variables in place of any number; and therefor, they can be updated dynamically at runtime.

In this line of the for loop, the Star Object is created (one for each i):
myStar[i] = Path.Star(CP, 5 + i, hSS/(4 * i), 1);

To set the starting position, each myStar[i] Objects is placed onto an outside point (the first one, in this case) of the preceding star.  Since the first myStar[1] Object is anchored on the centerPoint of the screen (CP), the for loop starts at 2.
for (i = 2; i <= 13; i++){
    myStar[i].position = myStar[i - 1].firstSegment.point;

Finally, the last star is given a different color, so it will be easier to recognize at runTime.


The onFrame() function is called +/- 60 times a second.  And since, I've place my own animateObject() function in the onFrame() function, this gets called whenever onFrame is called.
function onFrame(event){

Tthis is the code to create the animateObjects() function:
function animateObjects(){
    // all the stars are rotated, some in opposite directions by use of Math.pow(-1, i)
    for (i = 1; i <= 13; i++){
        myStar[i] = myStar[i].rotate(i * Math.pow(-1, i));
    // centerPoint of the stars are updated
    for (i = 2; i <= 13; i++){
        myStar[i].position = myStar[i - 1].firstSegment.point;

The order of these two inner for loops is important.
The first for loop rotates the stars.
The second for loop reorientates the stars back onto the end points of the preceding star.

I have NEVER been able to get any of the onFrame(event) event properties to work.
In the pointText feedback area, I tried to list out:
And so on in countless variations (not all shown).  I was unable to locate anything useful.  And this would go a long way towards explaining why I've never been able to successfully implement the event.count property (starts at 0 and is incremented +1 every time onFrame() is called, or so I am led to believe).

(And then, the next day, I discovered that I wasn't passing the event through as an argument.  So, if this is of interest, see the next tutorial onMouseDown(event), in which the Event Object is expored a little more, but not as much as I'd have liked as I hit another glitch.  So, who knows how much further down the line it will be before I can get all the kinks worked out on that one.)

Anyway, the pattern repeats itself indefinitely (over and over again, doing the same thing) as all the myStar[i].rotate are in lockstep.  After 360 onFrame() calls, incremented +1 each time, and we've gone 360 through the circle, and are back at the start, exactly where we started.  One could introduce randomness or slippage to avoid that, but not today, not by me.


I will however take a moment to talk about Quantum Mechanics.  I don't believe that subatomic particles move about based on probability.  I believe probability can predict their movement, but not that it describes it.  The difference is a lot like the difference between whether you are a boy or a girl.  Quantum Probability is often interpreted as saying no one knows -- how can I the coder know at code time who will view my words at run time, whether they be a boy or a girl?  And this then is extrapolated into the nonsensical claim that it is unknown and unknowable whether the viewer is a boy or a girl and even more ludicrous that this hasn't even been determined until the viewer reads the words on this page.  It's a silly claim.  It may be mathematically valid (I have no doubt that it is), but that doesn't mean it's true.

This crux of this confusion (in my ever so humble opinion) arises from a mis-definition of the concept of the universe.  I take 'universe' to mean everything.  Another way to interpret 'universe' however is a more restrictive one that says that the 'universe' is only that which one knows about, can interact with, and so on.  It's far more subjective (as in personal and mutable).  Because if an observer cannot see something or interact with something, then as far as that observer is concerned, it doesn't exist (and therefor, one need not worry about it when solving complex higher order mathematical equations, which is quite a handy thing, I can assure you).  For example, it's quite handy that one doesn't have to take into consideration the distance to the moon, when one solves for the square root of three.  And because of that, from a mathematical perspective (i.e. the prevailing perspective of Quantum Mechanics), the two problems exist in different 'Mathematical Universes'.  But if one deconstructs the problem, it quickly becomes appearant that it's all syntactical nonsense.  (The distance to the moon may not have any bearing on the square root of three, but that doesn't mean the two exist in separate universes, becuase as we all know, they do.)

And by the same token (the exact same line of reasoning), just because an observer doesn't know where a subatomic particle is at any given moment, doesn't mean said particle doesn't exist, doesn't have a location, or all the rest.  What it really means is that when solving for the location of a subatomic particle (now), where it was a moment ago has little bearing (because it's just not part of the mathematical equation).  And the reason it's not part of the equation is because our equations just aren't that good.  They're actually quite fuzzy, because that's what a probabilistic equation is: a fuzzy estimate.

I know I'm wrong.
I know 'Big Science' disagrees.
As do Any and All 'Real Scientists'.
I'm not a real scientist and the powers that be have done a crappy job of selling me on Quantum Mechanics.

But saying someone else is wrong is trivial (everyone is wrong at the edge cases or if you drill down far enough), so a complaint is only meaningful if some contrarian insight is offered.  And here's my two bits as to what I really think is going on down at the subatomic level (one and all):
  1. The equations that would describe the actions are so complex and interactive that we just don't understand them yet.  (Too many loops in the pendulum.)  And so, we can approximate an answer, but not know it exactly.
  2. It's also possible that the particles slip sideways through the Ether.  (Do you like that?  Does it sound mumbo jumbo enough and make my ideas easy to dismiss?  Whatever.  It's just differnet words for the same thing.  If we don't know, we don't know, and whatever one calls this 'I don't know land' is sort of beside the point.)  Anyway, if the universe is limited to only what we can see (and not everything as I claim), then if a particle goes where we can't see it, it's left the universe behind (doesn't exist for a moment) before returning to the realm in which we live.  This is not some Sixth Dimensional nonsense, it's just a statement of the obvious.  There is a limit to our perceptions.  If one is going to nonsensically define the universe as that which can be perceived (as seems to be the current trend these days), then it follows that at some point something is going to leave the universe at large (go to its own pocket universe or whatever); and then after a while, quite possibly return.  Predicting anything about that object or what happens to that object while it is in its own pocket universe is by definition impossible.  However, that doesn't mean that it doesn't exist or that whatever happens to it in that pocket universe doesn't happen to it in that pocket universe until it returns to we the holy viewer can observe it.
  3. Or to put it all more simply, if we don't know, we don't know, and no amount of saying that we know or that this is a leading theory or seems likely changes the fact that we don't know.
  4. But then, as long as folks seem to enjoy throwing wild theories about all willy-nilly (I know I do), then I might as well throw this one out here and now.  And the theory ties in nicely with computer programing, which is why I got started on this tangent in the first place.  So, follow along as best you can, maybe I'll write this up better some day.  The graphics on a computer screen aren't really what's important, the underlying code is what's important.  In the days of old, they split the universe up into the physical and the mental (spiritual, I believed they called it).  Well, in code, there is very clearly the lines of code (as written) and then what happens during execution (write time, run time, & compile time, and probably a few others).  And so, using the same progression of abstraction, the only thing that's important about subatomic particles (or anything for that matter) is their underlying code.  But as any good programmer knows, it's impossible to determine the code (the exact code, not just it's nature or it's output) from looking at the screen.  You actually have to look at the code.  One cannot see remarks without looking at the code.  And it is impossible to know what values are slowly being incremented, waiting until they hit a specific value when their predetermined (yes, predetermined) if/then statements will be executed.
So, in short, I believe it would be silly (and wrong) to say that a computer program executes randomly or is inherently probabilistic or that one or more of it's subroutines execute in a different universe from the base code or that a web page doesn't exist (no where, not even on the server) until some viewer calls if forth and makes an inquiry.

And I think it is silly, wrong, and just plain stupid to say the same thing about subatomic particles or any other portion of the Universe (the complete and whole universe).

If a tree falls in the forest, it doesn't matter if someone is there to hear it or not.
The tree has fallen.
It makes a loud noise.
End of story.

The Great Brett has spoken.
I can get a chain of thirteen stars to rotate in tandem.
Ergo sum: I know all.

(All code provided as is.  Scientific knowledge is NOT deemed reliable by anyone the author knows.  Occasional rants are the price of admission and come with the territory.  Heisenberg was wrong.  Einstein was right.  God does not play dice; he's more of a All In, Texas Hold 'em Poker type guy.  And the onMouseDown function wrapper is next.)


Seriously, the great part about writing fiction (see link below) is that one gets to explore all the ideas one has in great depth.  It's a lot like writing a code tutorial.  In that in both cases, one is trying to explain the workings of one's mind to another.  And from that, there are two awesome benefits:
  1. One needs to clarify their thoughts so as to bring some sort of order to them
  2. Having ordered them, the thoughts immediately go to the next level.  It's like a springboard for creativity.  It really is.  And here I should say something about how a good teacher is always the best student in their class, but sometimes, I fear I am the only student in my class.
Oh, well.
Next class in an hour.
I'm anxious to get moving on that onMouseDown() method, which is essentially the same as onClick() in some other libraries.

previous (          paper.js tutorial index       next -- onMouseDown()

Back to BrettCode Home

Brett Words
my writing site (Home to the writing of Celli the Happy Go Lucky Celaphopod, Eddie Takosori, Fritz Heinmillerstein, Morgan Feldstone, Kevin Stillwater, and of course, me, your host, Brett Paufler)

paper.js official site =

© Copyright 2013 Brett Paufler (Master Of & He Who Has Insight Into All)