paperJS (paper.js) JavaScript Library walk through by Brett Paufler -
9-10-13
JavaScript Tutorial & paper.js primer
COMPOUND PENDULUM - FOR LOOP,
FIRSTSEGMENT, ANIMATION, & QUANTUM MECHANICS
FOR LOOP
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.
ANIMATION
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){
updateFeedbackPointText();
animateObjects();
}
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:
onFrame.event
event.count
tool.event
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.
QUANTUM MECHANICS
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'.
Whatever.
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):
- 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.
- 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.
- 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.
- 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.)
PHILOSOPHY OF WRITING
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:
- One needs to clarify their thoughts so as to bring some sort of
order to them
- 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 (view.center)
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 = http://www.paperJS.org
© Copyright 2013 Brett Paufler (Master
Of & He Who Has Insight Into All)