==========
Update Feb 28, 2009:
Fixed broken links
"Pool table" physics simulation script (no "gravity")
This one does not have gravity. It only does collisions. I needed to make sure it worked properly before trying to implement it into the other script.
This version has proper energy transfer based on mass and angle. IT WORKS BEAUTIFULLY!
http://www.lowrestv.com/moho_stuff/scripts/physics1.mov
Zip contains an AS file and lua script file.
http://www.lowrestv.com/moho_stuff/scripts/physics1.zip
Instructions:
bone naming is the same as the script below with two additions:
Damping value bone named damping - scale of bone - This controls how long it takes the bones to stop moving.
Bounce value bone named bounce - scale of bone. should always be a negative value. Determines the amount of energy transferred from one bone to another when they hit. "lower" number less bounce or energy transfer. Remember it's a negative number so -0.95 is lower than -0.99.
Set the scale of these bones initially on frame 1. they can be changed by key framing them in the time line.
Do NOT change the scale of the gravity bone in the pool table physics script. This script does not use gravity.
If you want balls or bones to be stationary on start just give it 0 velocity for both x and y (in the bone name as described below).
==========
Gravity simulation script:
Gravity - Collision detection
http://www.lowrestv.com/moho_stuff/scri ... ection.mov
Zip contains an AS file and lua script file.
http://www.lowrestv.com/moho_stuff/scripts/gravity4.zip
Instructions: (Same for Pool table physics)
The bone name should be as follows in these sample bone names:
bonename.grav.-0.10-0.08
bonename1.grav.-0.09+0.06
bonename2.grav.+0.15+0.08
The part after the "grav" is the initial x and y velocity with a + or - sign for direction. Sorry this is so confusing. I will try to fix it. I used this for testing.
Name the bones with .grav at the end and the script will automatically apply "gravity" or "physics" to the bone depending on which of the scrips you are using. I have set the boundary of the bouncing area in the script. I will work on making this an adjustable feature probably using bones as "collision" objects.
Keep in mind this is based on "time". You can't scrub back and forth through the time line or select a key frame in the middle or at random. In order to see the simulation you must play it starting at frame 0.
I am think of adding a feature to add actual key frames to the bones so the script could be removed.
NOTE:
Turn off Allow Frame Skipping under the Animation menu. Otherwise the animation length is misleading. It will seem to be longer than it will be when rendered.
-----------------------------------------
Gravity - NO collision detection
Instructions for script with NO collision detection:
Just add .grav to the bone name. Other instructions regarding the bone name below do not apply.
http://www.lowrestv.com/moho_stuff/scripts/gravity3.mov
Zip contains an AS file and lua script file.
http://www.lowrestv.com/moho_stuff/scripts/gravity3.zip
-----------------------------------------
==========
My original post:
As I am playing around with converting Actionscript to lua for my aimer script it just sort of hit me...
It could be possible to script physics simulations that would work with AS. Something that goes beyond the "dynamics" constraint property that already exists.
I found a bit of Flash code that does an amazing "bouncy" wiggly simulation using IK. Linked "nodes" that are connected in a springy fashion like "jello". There would be no reason that this code could not be used to create a similar effect in AS using bones.
Imagine this... a script that is applied to certain bones in a character that causes a "jiggling" fat kind of thing or possibly cloth type effects.
What got me thinking about this is the fact that lua scripting control gives AS similar script controlled animation abilities just like Actionscript does for Flash.
No promises but I am going to give this some serious thought. I may try something really really really simple first just to see if it works.
-vern
Scripted "physics" for bones! Collision detection!
Moderators: Víctor Paredes, Belgarath, slowtiger
Scripted "physics" for bones! Collision detection!
Last edited by heyvern on Sat Feb 28, 2009 5:46 pm, edited 10 times in total.
Re: A scary thought... scripted "physics" for bone
Vern,heyvern wrote:I found a bit of Flash code that does an amazing "bouncy" wiggly simulation using IK.
Did you ever look at the resource I mentioned in another thread?
http://www.dhteumeuleu.com/
Gerard does some nice IK for puppets and he also does the sort of physics, I think, you're describing.
In physics simulation there are several parameters that should be taken account. The most important one is the time. To define any physic behavior you should have maths equations but in this case not simple equations like sin(x)*cos(y)=0. You'll find differential equations and they wouldn't be alone the would be combined and depending one of each others. See http://en.wikipedia.org/wiki/Differential_equation.
Most of the differential equations systems that define physics are derivatives of other equations of the time as main variable.
On the other hand computer solutions for derivatives equations made by computers implies numerical integration and evaluation od equations at discrete values. See http://en.wikipedia.org/wiki/Numerical_ ... _equations
Said this, you'll find that in AS the minimum amount of time you can calculate the equations are 1 frame duration (so minimum time is 1/fps). This would limit the ability of make complex dynamic behaviors unless you can live with sime inestability or dynamic errors (like the ones that the dynamic bone system have when they have to skip frames).
Also you should take account that dynamic physics computer calculation can work from the starting point to a forward time. If you go backward you cannot achieve the original position with exactitude mainly for the damping forces.
I don't want to discourage you but only want to advice that you're going to gnaw the hardest bone you've never seen...
Good luck and keep us informed.
Most of the differential equations systems that define physics are derivatives of other equations of the time as main variable.
On the other hand computer solutions for derivatives equations made by computers implies numerical integration and evaluation od equations at discrete values. See http://en.wikipedia.org/wiki/Numerical_ ... _equations
Said this, you'll find that in AS the minimum amount of time you can calculate the equations are 1 frame duration (so minimum time is 1/fps). This would limit the ability of make complex dynamic behaviors unless you can live with sime inestability or dynamic errors (like the ones that the dynamic bone system have when they have to skip frames).
Also you should take account that dynamic physics computer calculation can work from the starting point to a forward time. If you go backward you cannot achieve the original position with exactitude mainly for the damping forces.
I don't want to discourage you but only want to advice that you're going to gnaw the hardest bone you've never seen...
Good luck and keep us informed.
Thanks Genete, I am aware of the many problems this could pose for me.
I am actually basing this on Flash and Actionscript which is also time based and frame rate based. Flash has been around a long time with many more users creating amazing solutions.
In the Flash examples everything happens based on FPS. Each time the script cycles through the equations it is based on the previous "frame" even though it actually runs on a single frame.
In AS this cycling of the script would be based on a target key frame later in the timeline, and calculating what the bone does on each frame before and after it passes that frame.
For instance if you had a chain of bones in AS with some sort of "gravity" and "friction" defined in a script, and rotated a bone on a later frame, each bone lower in the chain would rotate differently at a different rate based on the hierarchy of the bones in the chain. This could simulate a swinging chain, or flowing hair.
Actionscript in Flash works the same way really as scripting does in AS, each time a frame is "entered" it runs the code which creates the effect. The difference with Flash is that the user creates the "motion" that causes the effect. In AS it would be a key frame on a bone.
Obviously this wouldn't work if you didn't start the animation on frame 1... but during rendering or playback (frame skipping off) this shouldn't be a problem.
I have yet to test this so I could be completely nuts... but I think it might work. The final results would really be seen in the render.
If it does work... there are tons of cool Actionscripts out there to convert.
-vern
I am actually basing this on Flash and Actionscript which is also time based and frame rate based. Flash has been around a long time with many more users creating amazing solutions.
In the Flash examples everything happens based on FPS. Each time the script cycles through the equations it is based on the previous "frame" even though it actually runs on a single frame.
In AS this cycling of the script would be based on a target key frame later in the timeline, and calculating what the bone does on each frame before and after it passes that frame.
For instance if you had a chain of bones in AS with some sort of "gravity" and "friction" defined in a script, and rotated a bone on a later frame, each bone lower in the chain would rotate differently at a different rate based on the hierarchy of the bones in the chain. This could simulate a swinging chain, or flowing hair.
Actionscript in Flash works the same way really as scripting does in AS, each time a frame is "entered" it runs the code which creates the effect. The difference with Flash is that the user creates the "motion" that causes the effect. In AS it would be a key frame on a bone.
Obviously this wouldn't work if you didn't start the animation on frame 1... but during rendering or playback (frame skipping off) this shouldn't be a problem.
I have yet to test this so I could be completely nuts... but I think it might work. The final results would really be seen in the render.
If it does work... there are tons of cool Actionscripts out there to convert.
-vern
Well it works... but not quite.
You know how if you zoom or pan or do something within the preview it causes a script to "refresh"? Well the code works if you do that. If I hold down the right mouse key (panning) the bone bounces with gravity, but if I play the animation the code starts from frame 0 on every "loop" instead of maintaining the variables. It resets them to the frame 0 state.
It is very odd. Oh well it was a fun experiment.
-vern
You know how if you zoom or pan or do something within the preview it causes a script to "refresh"? Well the code works if you do that. If I hold down the right mouse key (panning) the bone bounces with gravity, but if I play the animation the code starts from frame 0 on every "loop" instead of maintaining the variables. It resets them to the frame 0 state.
It is very odd. Oh well it was a fun experiment.
-vern
I will post it later... it is a wild mess right now... all kinds of crazy experiments commented out.
The problem is within AS itself and how it processes layer scripts on playback. When entering each frame it "incorrectly" resets variables for bone position to the default frame 0 values.
I am putting a bone's fPos value in a variable on frame 0. Technically this value should NEVER change. It is initailized only on frame 0. This value is modified only on frames higher than 0 and then that modified value is applied to the bone's fPos. The variable is NOT updated except through modifying its value in the script ... even so that value is "reset" on entering a new frame and the bone's fPos "jumps" back to the initial value.
I think this also is a result of how AS may run a script 2 or 3 times when entering a frame. When panning or zooming in the view the script is run in sequence and you see the results update immediately... when playing the animation I think that the script is running too often or too fast before the screen or the variables are updated thus breaking the script.
I am thinking of trying one more trick... using the frame number value as a variable to increment bone position.
-vern
The problem is within AS itself and how it processes layer scripts on playback. When entering each frame it "incorrectly" resets variables for bone position to the default frame 0 values.
I am putting a bone's fPos value in a variable on frame 0. Technically this value should NEVER change. It is initailized only on frame 0. This value is modified only on frames higher than 0 and then that modified value is applied to the bone's fPos. The variable is NOT updated except through modifying its value in the script ... even so that value is "reset" on entering a new frame and the bone's fPos "jumps" back to the initial value.
I think this also is a result of how AS may run a script 2 or 3 times when entering a frame. When panning or zooming in the view the script is run in sequence and you see the results update immediately... when playing the animation I think that the script is running too often or too fast before the screen or the variables are updated thus breaking the script.
I am thinking of trying one more trick... using the frame number value as a variable to increment bone position.
-vern
Hey Vern,
In this thread here someone posted a link to an awesome website that lets you control puppets with the mouse. Perhaps you could get some ideas for your AS scripts, as long as their action script is accessible, that is.
I think this is a long requested feature. Pity it seems harder to implement than it should be. Perhaps that's why no one has seriously tackled it til now.heyvern wrote:It could be possible to script physics simulations that would work with AS...
In this thread here someone posted a link to an awesome website that lets you control puppets with the mouse. Perhaps you could get some ideas for your AS scripts, as long as their action script is accessible, that is.
YEEEEEHAAAAAAA!!!!!
It works!
This is a very rough proof of concept but the dang thing WORKS!!!
http://www.lowrestv.com/moho_stuff/scripts/gravity2.mov
Download both files below into the same folder:
-- Use scripts and AS files in the first post --
-vern
It works!
This is a very rough proof of concept but the dang thing WORKS!!!
http://www.lowrestv.com/moho_stuff/scripts/gravity2.mov
Download both files below into the same folder:
-- Use scripts and AS files in the first post --
-vern
Last edited by heyvern on Sat Feb 28, 2009 5:49 pm, edited 1 time in total.
I updated the script and the movie file:
http://www.lowrestv.com/moho_stuff/scripts/gravity2.mov
-- use the AS files and scripts from the first post --
It's the same links as before actually. You don't need a new anme file as the script will work with the previous one.
I added x translation!!!! IT BOUNCES SIDE TO SIDE NOW!!!!
This is it! ASP can do the EXACT SAME kind of scripted motion that FLASH CAN DO!!!! There is potentially no limit to the kind of physical simulations possible. Any thing done in Flash could be done in ASP!!
Just a note on use of these files. You must turn off "Allow Frame Skipping"... otherwise the animation runs twice as long as it will render. The odd thing is that it still runs the same but since it skips frames the script only gets activated on the frame it's on... so frame skipping extends what the actual rendered length would be.
-vern
http://www.lowrestv.com/moho_stuff/scripts/gravity2.mov
-- use the AS files and scripts from the first post --
It's the same links as before actually. You don't need a new anme file as the script will work with the previous one.
I added x translation!!!! IT BOUNCES SIDE TO SIDE NOW!!!!
This is it! ASP can do the EXACT SAME kind of scripted motion that FLASH CAN DO!!!! There is potentially no limit to the kind of physical simulations possible. Any thing done in Flash could be done in ASP!!
Just a note on use of these files. You must turn off "Allow Frame Skipping"... otherwise the animation runs twice as long as it will render. The odd thing is that it still runs the same but since it skips frames the script only gets activated on the frame it's on... so frame skipping extends what the actual rendered length would be.
-vern
Last edited by heyvern on Sat Feb 28, 2009 5:50 pm, edited 1 time in total.
I updated the script link again. Just a tiny change that allows for multiple bone layers:
http://www.lowrestv.com/moho_stuff/scripts/gravity3.mov
All I did was to duplicate the bone layer and move the "ball bone" to different locations on frame 0. Don't use bone offset that won't work since it doesn't change the actual location of the bone.
-vern
http://www.lowrestv.com/moho_stuff/scripts/gravity3.mov
All I did was to duplicate the bone layer and move the "ball bone" to different locations on frame 0. Don't use bone offset that won't work since it doesn't change the actual location of the bone.
-vern
Don't worry about that Genete. I plan to have those options with bone controls right in the screen. So you would have a velocity bone and a gravity bone etc etc... Each bone could have it's own set. I would probably use bone scale for the control since that makes the most sense.Genete wrote:Cooool! This must be documented to understand how to include initial position direction and speed and how to set boundary collisions.
Good stuff!!!!
-G
It is so amazing how now that I got this working everything else would be so simple to control. I knew it would work I knew it would work I knew it would work!!!!!!
-------
Genete, that code I discovered that causes scripts to only run once per frame is AMAZING!!! That was the trick!!!! It not only fixed this code but it is going to fix a bunch of my other scripts!
I have had no end of problems with scripts doing weird things it shouldn't. This script was doing the EXACT SAME THING until I added that little bit of code to run the script once per frame.
-vern