Scripted "physics" for bones! Collision detection!

[dueyftw]

Bit take two forms one would be math and the other would be logic. I’m going to skip the math and go right to the logic.

Every line of comparison code (don’t matter what language) is true (1) or false (0).

So:

And
If (statement=0) and (statement=0) then false

If (statement=1) and (statement=0) then false

If (statement=0) and (statement=1) then false

If (statement=1) and (statement=1) then true

or
If (statement=0) or (statement=0) then true

If (statement=1) or (statement=0) then true

If (statement=0) or (statement=1) then true

If (statement=1) or (statement=1) then false

This could be wrong. I’m tired and need sleep. But operators just control the logic.

Look at a logic tables and you will see. I hop this is what you are asking otherwise, never mind.

Dale

I just checked 'and' and 'or' are reserved words. Just type them in.

[Genete]

In computer programming, a bitwise operation operates on one or two bit patterns or binary numerals at the level of their individual bits. On many computers, bitwise operations are slightly faster than addition and subtraction operations and significantly faster than multiplication and division operations.

See : http://en.wikipedia.org/wiki/Bitwise_operation

If lua doesn't have a binary conversion and operation library you can always use the clasical way:

http://en.wikipedia.org/wiki/Binary_num ... em#Decimal

storing the binary number in a table or array and operating as described by the AND operation.

I'm curious about where is the binary level AND opeartion used in a physic simulation. Maybe this?:

bitwise operations are slightly faster than addition and subtraction operations and significantly faster than multiplication and division operations

-G

[heyvern]

Not sure if that's it.

However I did find a function I can use that "fakes" a bitwise comparison.

From the definition for my purposes it takes two numbers converted to "binary" and compares the locations of "1" and "0" and if one matches it is true and returns the location... or something like that. I may have this wrong as well. I don't even understand why you would need to do this. I'm sure there is a good reason for it... like that service contract they want you to buy for a new DVD player.

It may turn out that I don't even need it. The code I am converting creates "flexible" springy connections. A lot of the code is changing a line segments bias handles when the nodes compress. Since AS doesn't have those types of lines I might add in an extra bone between the connection bones to simulate this up/down spring motion... or I might just leave that out completely... it is an optional feature in the code.

I am getting excited now that I find many of the abilities of ASP are similar to Flash. Things like getting the boundaries of a mesh for irregular shape physics. The math used in Flash to get the area of a drawn shape can be used in ASP.

-vern

[human]

The math used in Flash to get the area of a drawn shape can be used in ASP.

In other words, automated squash and stretch?

[heyvern]

The math used in Flash to get the area of a drawn shape can be used in ASP.

In other words, automated squash and stretch?

Possibly, yes. I was thinking more along the lines of "irregular shape" detection.

Instead of a bounding box defining object collision it might be defined by the mesh BOUND to the bone instead.

The start and end of a "line" defined in Flash is two sets of points just as it is in ASP. Actually all the tricks I'm doing with bones is done entirely with "shapes" in Flash or movie instances since Flash doesn't have bones.

The script in this thread could probably be done on a vector layer to the mesh shapes themselves... using bones is WAY easier though.

-vern

[heyvern]

I've been thinking of ways to apply and store physics information for use with these scripts.

One crazy idea that I really like would be to use a menu script to set bones in a list to apply different types of physical properties. This would then save this info to a "preference file" that is read in each time the file is open (don't know how to do THAT yet).

The benefits of this would be great. First off you wouldn't need to name bones to apply the physics. The bone list/table would be created by the menu script storing the list of bones in the text file.

Another aspect of this would be to put the physics scripts into a utility script file. Then you could apply any number of different physics properties to bones. Only the ones referenced would be used from the utility script.

Hopefully this would work so that you could have a bone that is the root of a chain or spring, that also uses gravity.

Lot of work involved to do it this way but another benefit would be the ability to add to this "physics library" to expand it without starting from scratch. A lot of the code is very repetitious and could be in the utility script.

-vern

[dueyftw]

Ok Heyvern
I look at your code.

The walls are defined with;

layer.SH = 0.84
layer.SW = 1.3

But the gravity is defined by,

local gbn = string.find(boneName, '.grav') -- gravity bone
if (gbn) then
local velY = string.sub(boneName, gbn+6, gbn+10)
local velX = string.sub(boneName, gbn+11)


Where gbn+6 and gbn+10 give the values for local velY

So if you add two more numbers in the name with

local wallpostionH = string.sub(boneName, gbn+16)
local wallpostionW = string.sub(boneName, gbn+21)
if local wallpostionH = 0 then layer.SH = 0.84 end
layer.SH = 0.84
if local wallpostionW = 0 then layer.SH = 1.3 end
layer.SH = 0.84


This should make the gravity grow or shrink as needed.
I suck a programming so I don’t know if this correct, but Heyvern I hope you get the idea

Dale

[heyvern]

This should make the gravity grow or shrink as needed.

Thanks, but putting values in the bone name is just a temporary workaround at the moment. I don't like this way of setting values. It is prone to many errors. It is hard to read the values and you can easily mistype them.

Plus you are limited to the numbers that can be used. Can't go less than the value of the substring of the bone name.

If I don't go with the other idea of using a preference file I will just use other bones to edit these values using the scale of the bone.

-vern

[dueyftw]

Ok

My next idea was too add two more numbers to the name start frame and end frame so you could turn on and off the gravity. But a better way is to add a layer to the time line turning gravity on and off, same as visibility.


Dale

[heyvern]

Yeeehaaaa!

Haven't posted the new version yet, but I found some NEW code that is smaller AND BETTER!

This new code handles proper transfer of energy based on angle of collision, mass and momentum!!!

You will be able to have pool table physics that look amazingly "real". I plan to add in a mass property based on the size of the bone!!! The larger the bone the more mass and momentum the object has.

The best part for me is the code is so clean and compact.

-vern

[Genete]

If you plan to change mass over the time then scale is a good value to store that. If you don't plan to change it over the time you can store the mass at the bone's strength? (I guess that the layer/shape would be region or directly bound so it doesn't matter the strength amount for the animation (if it is bigger than 0 of course)

Then you can use the scale to simulate velocity amount and the angle could be the direction... more velocity more deformed is the layer... ha ha it is cartoon like! (store where you want, man )

Regarding to momentum read this article if any doubt arises...

http://en.wikipedia.org/wiki/Momentum

You're close to a simulate a billiard pool... Nice!

-G

[heyvern]

I have a rough version of the script that has gravity linked to a bone scale. It is cooool!

I can turn gravity on and off, change it's value with key frames.

It is so funny to see those balls bouncing around and suddenly the gravity gets turned off and they all start to float and drift away... then I turn it back on and they all start to fall again!

I definately think as many of these values as possible should be keyable. It just makes sense to have that control.

I so much want to use some kind of pop up menu interface with an external project preference file. It would be great not having to name bones. The only drawback is that some of the properties couldn't be keyed using that technique. Unless I can figure out a way to "key" a custom variable... I don't think I can though.

I can't wait to add in some bone rotation to the bouncing. Then I can use something besides "ball" shapes.

-vern

[heyvern]

I did it!

Check the first post for updates.

http://www.lowrestv.com/moho_stuff/scripts/physics1.mov

This is the best implementation so far. Perfect "edge" detection of the bones width when colliding with objects. Previous versions of the scripts didn't do that so well.


Currently the mass value is based on the bone length which is pretty cool. Make the bone longer that object has more mass. Later I will add in the variable controls to change the mass separately from width.

Then you could have big "soft" objects that absorb more energy... or are totally immovable... you could have light bouncy balls with less mass like ping-pong balls or beach balls.

-vern

[Genete]

Let's plat a billiard pool game?
Cool!
-G

[heyvern]

There is a bug in the script. It won't let you add new bones. I have fixed this and will upload a new script when I get a chance.

The problem is that I created all the gravity bones in sequence. When you add a new bone it messed up my "converted" AS code so one of the "for" loops was incorrect.

I fixed it by using an incremented variable to sequentially index the grav bone table.

Another problem that popped up was using string.find() and not turning off the regular expression search feature so searching for ".grav" would match any bone with just "grav" in it since the "." is a regex symbol.

-vern