Gravity Pads

[CheeseFriez]

Can somone give me a step by step or a brief explanation how to make a gravity pad? (point A: go up Point B: Regular gravity)

[Kilinich]

Box with thruster?

[FRA32]

Very simple:

e.other.postStep = (e)=>{
vel = vel + [0,9.81*2]/sim.frequency
}
it adds the default gravity force times 2 to the object, 1 time to negate the default gravity, and another time to apply inverted gravity. It also works with sideways gravity, check some of my scenes for examples

[Kilinich]

it's better use gravityStrength in formula instead of value.

[Xray]

Why divide by sim.frequency?

[Kilinich]

Why divide by sim.frequency?

Because you add velocity every step. More frequent you do - less delta velocity you need.
Acceleration is m/s^2 so to get V (m/s) you need to multiply to time (s). Frequency is (s^-1) so you need to divide.

btw that code is better:

Code: Select all

(e)=>{
    vel = vel + [ - math.sin(sim.gravityAngleOffset), math.cos(sim.gravityAngleOffset)] * Sim.gravityStrength / Sim.frequency
}

[Xray]

Because you add velocity every step. More frequent you do - less delta velocity you need.
Acceleration is m/s^2 so to get V (m/s) you need to multiply to time (s). Frequency is (s^-1) so you need to divide.

That makes sense. Thanks!

[FRA32]

@Xray

Formula for accelleration:
v=a*t
so delta-v = a*delta-t
and delta-t gets smaller the more frequent the frames get, so divide by sim.frequency to get the proper value per second. After all, if the frequency is 60, and you divide t by 60, you will add 60 times 1 60th of t to the value, and after a full second, it's 1*t in total. Makes sense rite?

[Xray]

Yes sir!

[ThatDudeIt]

The first pad:

e.other.density = 0.005

The second pad:

e.other.density = 2 (Change the number if the original density was different)

[Xray]

Why divide by sim.frequency?

Because you add velocity every step. More frequent you do - less delta velocity you need.
Acceleration is m/s^2 so to get V (m/s) you need to multiply to time (s). Frequency is (s^-1) so you need to divide.

btw that code is better:

Code: Select all

(e)=>{
    vel = vel + [ - math.sin(sim.gravityAngleOffset), math.cos(sim.gravityAngleOffset)] * Sim.gravityStrength / Sim.frequency
}

I was playing around with kilinich's code (shown above) and it caused some very odd movements of a circle and a box. Please take a look at the simple scene that I created and tell me what you think is causing the strange behavior that I have experienced.

[FRA32]

What you are experiencing there is a common error of algodoo. Attempting to apply velocity to a fixed object is nonsensical, so what algodoo seems to do is give the entire static scenery(everything with body=0) that velocity when doing collision calculation, thus causing everything to bounce up in the sky when touching anything fixed to the ground. This is only a theory of mine, but seems to make sense(considering this behavior is quite nonsensical and quite a dumb oversight, but oh well, thyme is "experimental")

[Xray]

Attempting to apply velocity to a fixed object is nonsensical,

Really? I thought users did that often in scenes, such as when a rocket lifts off the launch pad. Its velocity is zero while at rest, then suddenly gets a huge boost in the +Y direction during liftoff.

what algodoo seems to do is give the entire static scenery(everything with body=0) that velocity when doing collision calculation

The bouncing objects in my scene do not have body = 0. It is my understanding that all objects that have body = 0 are objects that are glued to the background. All other objects not glued to the background have body > 0.
I have been using Algodoo and Thyme scripting since 2012, and I have never witnessed this behavior until now. Since kilinich's code is responsible for this, I hope that he will chime in and give his opinion about what might be causing this strange behavior.

Thanks!

[Xray]

Fra32 - I misunderstood what you meant when you said "Attempting to apply velocity to a fixed object is nonsensical". I did not realize that what you meant was a GLUED object. You are correct that it does not make sense to apply velocity to an object that is glued to the background. When you do that, it makes other objects move with a velocity even though their velocity was not changed by the user or by the Thyme script. Most assuredly a strange bug!

Sorry for misunderstanding your comment, and thinks for your input which is always appreciated.

[FRA32]

You could imagine it like this:

If you had a glued object with the code vel = [1,0], then it would try to move with that velocity, but fails to do so since it belongs to bodygroup 0(glued to background). What algodoo does now is take ALL The objects that have this body group(fixated objects, glued objects, planes) and pretends that all of these are having said velocity of [1,0] without actually moving them. The consequence is the following: Whenever a moving object touched, say, the ground plane, or any glued object for that matter, algodoo calculates "oh, this moving object fell into an object that is moving 1 to the right per second, so friction/collision should transfer some of that velocity over" and what happens? The object bounces to the right, despite hitting a staitonary object. As the velocity of the glued parts does not change from collisions, this state is permanent until you forcefully set the velocity of any glued object to [0,0] again, or add a new glued object to the scene, thus resetting the "fake velocity" to 0 again.

[Xray]

That makes sense. Thanks again, FRA32!

[Ken3344]

Yeah, gravity pads are a tricky one! Many people I know on Algodoo use this script:

Code: Select all

(e)=>{
    e.other.density = 0.005
}


However, I don't find the gravity for those to be realistic. (I call them float pads for that reason!) I use a more advanced version of it which has the added bonus of setting the gravity to what angle you want!

Code: Select all

(e)=>{
    e.other.poststep = (e)=>{
        vel = vel + [ - math.sin(3.1415925), math.cos(sim.gravityAngleOffset)] * (Sim.gravityStrength) * 2 / Sim.frequency
    }
}


Can't believe Algoryx decided to end development back in 2013...

[FRA32]

Hey ken, that answer is basically the generalized version of my answer. however it is slightly more calculation-intensive(due to sin and cos) and not perfectly correct, as gravity would instantly malfunction the very moment you changed the angle.

The correct formula would be:

vel = vel + ([-math.sin(sim.gravityAngleOffset),math.cos(sim.gravityAngleOffset)]+[math.cos(newAngle),math.sin(newAngle)])*sim.gravityStrength/sim.frequency;

First this formula neutralizes the default gravity, regardless of gravity Offset, then it adds the custom gravity, and finally the numbers are scaled accordingly.