Simulate a pendulum

[rumplestiltskin]

Roger.

Very nice indeed. I think this should be required reading.

There is a small bug somewhere. When the sine wave gets to the right edge of the screen, the gravity increases. I only mention it because I believe this stack will be needed by others in the future.

Craig Newman

Agreed! Would be helpful to have the card script heavily commented (as my math skills haven't been developed much beyond what I learned in school...35 years ago).

I showed this stack to my students (Intro to Computers & Info Tech) this morning and they were blown away.

[sturgis]

Does the gravity actually increase, or do things speed up because there is no longer the delay caused by drawing the sine wave visibly on the screen? Either way it is a great stack. Gonna have to dig through it and understand things that I currently don't. (funnest part of life)

[dunbarx]

Sturgis.

I looked through the script and could not find anything that was screen related. But I guess what you mean is that even though the script still contains the code to draw the sine wave, albeit off screen, it does not, and that is what saves a bit of time.

Never thought of that.

Craig

[dunbarx]

Sturgis.

And Roger.

That was it. Roger knew about this and set a right side limit, that he commented out while developing. When the sine wave stops being drawn, the script speeds up by quite a bit.

I fixed it by adding an ugly modification to Roger's elegant script. Just so it will keep time. Roger, I apologize.

I modified as:

Code: Select all

 if T < the width of this stack then 
      choose Pencil tool
      drag from the loc of grc "dot" to xz+t,yz+L*sin(theta)/3.5
      set the loc of grc "dot" to xz+t,yz+L*sin(theta)/3.5
   else
        choose Pencil tool
      drag from the loc of grc "dot" to the loc of grc "dot" 
      set the loc of grc "dot" to the loc of grc "dot"
    end if

Talk about brute force ugly...

Craig

[sturgis]

Yeah, that was the theory at least.

Haven't looked at the code yet but looking forward to it when I get a moment. Its gorgeous when compared to what I shoved together. (good design and I are not on speaking terms)

[dunbarx]

Sturgis.

The imperative is getting in first, not best. I joked once that I simply must stop posting to this forum while driving.

Craig

[rumplestiltskin]

Sturgis.

The imperative is getting in first, not best. I joked once that I simply must stop posting to this forum while driving.

Craig

That's depressing for those of us who are busting our chops trying to understand all this. (*grin*)

Considering all the stuff going on behind the curtain, it's even more amazing how beautiful this looks on-screen. However, I think I'm going to go back to the "move" command as it seems to require much less horsepower (and is certainly easier for me to understand and modify as necessary).

[dunbarx]

Sure.

But you see how a sinusoidal motion is critical to a good looking pendulum. So if you use "move" to change the position of the weight, is that so different than setting its loc? You will need the same information to do either.

Anyway, write back with what you make.

Craig Newman

[RogGuay]

Hi all,

Sorry I'm not attending to this in real time as I use the digest.

My Pendulum was improved and is just one of the harmonic oscillators of my Harmonic Oscillators stack available at my PhunPhysics website.

http://phunphysics.net/PhunPhysics.net/Downloads.html

I appreciate all the nice comments and I'm sorry for not commenting more in my code . . . one of my many failings.

Cheers,
Roger

[rumplestiltskin]

Sure.

But you see how a sinusoidal motion is critical to a good looking pendulum. So if you use "move" to change the position of the weight, is that so different than setting its loc? You will need the same information to do either.

Anyway, write back with what you make.

Craig Newman

Craig,

Unless I'm missing something, I can:

Code: Select all

move graphic "ball" to the points of graphic "line" in 2 seconds

but I can't:

Code: Select all

set the loc of graphic "ball" to the points of graphic "line"

...without using a repeat loop like this:

Code: Select all

on mouseUp
   repeat with x = 1 to the number of lines in the points of graphic "line"
      set the loc of graphic "ball" to item 1 of line x of the points of graphic "line",item 2 of line x of the points of graphic "line"
      wait .5 second -- set this with a user entered number in a field or popup
   end repeat
end mouseUp

...and I'd just have the ball "popping" into existence at the endpoints. If I want to have smooth motion, I guess I'd have to add many points between the two endpoints and then I'd have the major processing overhead of the loop (which is why I'm back at the "move" command for its simplicity). I agree the sinusoidal motion of the pendulum is critical if I must have a pendulum. I'm abandoning that idea now as I can see trying to maintain code using mathematics I don't understand (although can experience with the pendulum stack) might be a headache I'm not willing to accept. What's the old saying? I beat my head against the wall because it feels so good when I stop. Um...nah.

I'm even thinking about a pulsing light and sound (although I haven't looked into what a pulsing light might take in terms of code - I'm not looking to complicate this app - )

Thanks,
Barry

[sturgis]

You could cheat again maybe. Make a graphic line that has the curve you wish the motion to follow, hide it, and then do as you say. move it to the points of grc "line" in 2 seconds.

You can mess with code that generates a line if you like. Here are 3 functions that may help. (if you just want to play)

Code: Select all

## takes radians and converts to degrees
function rToDegrees pRadians
   return pRadians * 180 / pi
end rToDegrees

## takes a length and and angle and returns a vector pair. 
function aLenToVector pLen pAngle
   return round(pLen * sin(pAngle)),round(pLen * cos(pAngle))
end aLenToVector

### Function takes start degrees, end degrees, radius and the number of steps to take between start and end
function genPath pStartDegrees, pEndDegrees, pRadius, pSteps
   put pStartDegrees into tCurrentDegrees
   put(pStartDegrees - pEndDegrees) / pSteps into tStepsize
   repeat pSteps times
      put dToRadians(tCurrentDegrees) into tRadians
      put aLenToVector(pRadius,tRadians) & cr after tPointsList
      add tStepsize to tCurrentDegrees
   end repeat
   delete the last char of tPointsList
   return tPointsList -- returns a curve based in input
end genPath

#### A sample handler that uses the above functions
command getPath
lock screen
   set the points of grc "templateCurve" to genPath(290,150,200,180) -- templatecurve must already exist
   set the loc of grc "templateCurve" to the loc of this card -- points generated may not be on the card (they won't be)
   -- so move the grc into position after points generation.   290 is start angle, 150 is end angle, 200 is radius, 180 is the number of steps to take between start and end
unlock screen
end getPath

[Simon]

OK, so I'm very late to this but with good cause... really... (I'm slow):

Code: Select all

local tSwing,tCount,tDirect

on mouseUp
   if tSwing <> true then
      put true into tSwing
      put 270 into tCount --start angle
      put 1 into tDirect --start direction
      pendulus
   else
      put false into tSwing
      wait 10 millisecs with messages --could use cancel the pendingMessages
      set the angle of grc "myImage" to 270 --reset to rest position
   end if
end mouseUp

on pendulus
   --if trunc(tCount) = 340 then put -1.7 into tDirect --trunc is used so fractional values can be used
   --if trunc(tCount) = 200 then put 1.7 into tDirect
   
   if tCount >= 340 then 
      put true into tMax
   else 
      put false into tMax
   end if
   if tCount <= 200 then
      put true into tMin
   else 
      put false into tMin
   end if
   
   if (tMax = true) and (tMin = false) then
      put -1.7 into tDirect
   else if (tMax = false) and (tMin = true) then
      put 1.7 into tDirect
   end if
   
   put tCount + tDirect into tCount
   
   set the angle of grc "myImage" to tCount
   
   if tSwing = true then send pendulus to me in 10 milliseconds
end pendulus

This part that I commented out
--if trunc(tCount) = 340
and the following line, is very wrong to me and I couldn't figure out a formula for how to fix it. It's that "=" I thought was bad but I couldn't use ">=" as that, in this case, does not work.
At any rate you can see how I finally fixed it.

Barry, there is no "big" math in this and I did it mostly to get you away from using a repeat loop which should not be used when a send can do the trick.

This is based on sturigs's upside down windshield washer.

Simon
EDIT: Boring linear motion in mine

[sturgis]

You know, I was wondering how to handle any pendulum movements that break the > 360 barrier or the < 0 barrier... Gave myself a headache till I realized it makes no difference. Setting the angle to an angle > 360 automatically modulos. DOH.

BTW, nice smooth swing you got there.

Mind if I throw a twist out there? If you were going to write this based (loosely) on the passage of time rather than a set increment each time, how would you go about it? (This would be to allow frame skipping, positioning the pendulum based on how much time has passed since the last update)

I've done something like this before but for some reason i'm not seeing it this time and can't find my old code.

[dave_probertGA6e24]

Sturgis,

Look for the frame rate smoothing from the Game Academy. There was an example used in that, and other people did variations.

Cheers,
Dave

[sturgis]

THATS where I remember it from. Thx dave!