#### Archived

This topic is now archived and is closed to further replies.

# Gravity

This topic is 6191 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am haveing problems creating gravity for my program. Dose anyone have a realy fast way of doing this. Give me the math or point me to a website that will give me a good idea of how to accomplish this. A man walks into a bar.....ouch!?! Ya get it, do ya huh huh well....awww I give up.

##### Share on other sites
Gravity is just a form of acceleration. If you keep the fps at constant speed will you avoid a lot of trouble.

##### Share on other sites
Where is a good place to learn how to keep your fps at a constant rate. Nate''s page used to have it but he took it down.

##### Share on other sites
  #define gravity 9.8program_speed = (1/frames_rendered)*time_since_start_in_seconds;speed.y -= gravity*program_speed;object.y += speed.y;

If your model is scaled so that one unit is one meter, then I think that is right. Things fall at a rate of 9.8 metres per second on earth. If you don't use metric, then a) you'll need to convert gravity to some other number and b) you must have a hard time with opengl (kind of hard to use fractions, feet, and inches). You can add speed*program_speed to something to make it move at a rate of speed units per second.

Edited by - £~{ÿùÖ² on ƒUƒP£ÖÿÜ -2342112, 25223 64:123:21 £m

Edited by - smart_idiot on February 1, 2001 1:25:31 PM

##### Share on other sites
sorry but i think you''re wrong....

s = 1/2 * a * t^2

s = the distance...
a = 9.81m(eter)/s^2 //const.
t = time in seconds

i won''t explain this becaus my english isn''t good enough... :-)
but this works only for the case, that the object hasn''t speed in the -y(or what ever...) direction...
else:
s = v * t + 1/2 * a * t^2

v = velocity in the same direction wich the object has already...
hope you could understand me.... :-)

##### Share on other sites
I think that the code smart_idiot showed is OK if the framerate is constant. If you start with Physiks formulas will you end in something like that code.
Right, you can remove program_speed.

Several of the NeHe tutorials is timed like lesson 23.

##### Share on other sites
Small tutorial with full source code and a demo including gravity detection & response: Physics - Gravity

(ps: It''s about a "perfect" animation - not a fast approximation)

##### Share on other sites
Thanks for all your suggestions they were quite helpfull. I have been reading quite alot about physics and I have a very basic routine set up. It should do for now ounce I refine the engin a little I will add an increaseing velocity (mine is currently constant).

##### Share on other sites
It could be wrong, but I looks right to me.

In my programs after 100 frames I calculate the speed, average it with the old speed, then I reset the start time and elapsed frame counters.

It seems to work. The idea is that if you add up the sum after rendering all the frames for one second, it adds up to one. I did it this strange way because I couldn''t figure out how to get a timer that was more accutate than 1/18th of a second. There was probably an easier way, but this works for me. You may have different needs.

##### Share on other sites
Acceleration is not linear so it is not that easy. Perhaps your test program did have an almost constant speed?

##### Share on other sites
smart_idiot is approximating. This is never accurate.

An example:
- Imagine an object falling from a building.
- The acceleration (==gravity) is constant.
- Speed is slowly increasing (not constant).
- The speed starts with 0, and hits the ground with lets say 100.

If you would use smart_idiot''s method, you''re assuming the starting speed is the same as the end speed - but it is not the case.

Physik is right with his formula''s!
"perfect" calculation - no approximation.

What the last AP exactly means - I don''t know?
Gravity is a constant acceleration!
Maybe the last AP is pointing out smart_idiot''s approximation?

##### Share on other sites
I can understand the confusion though.
If you do a search on the internet, you will find out most tutorials & stuff use the wrong method, and only approximate!!!
Watch your back! Don''t trust anyone!

##### Share on other sites
quote:
smart_idiot is approximating. This is never accurate.

If you would use smart_idiot's method, you're assuming the starting speed is the same as the end speed - but it is not the case.

i'm not sure what you're talking about, i thought smart_idiot's idea is correct. i could be wrong tho.
  program_speed = (1/frames_rendered)*time_since_start_in_seconds;speed.y -= gravity*program_speed;object.y += speed.y;
would have to be in a loop of course. so each time it loops through, you get a new velocity and a new position based on that new velocity.
say initial object.y = 100 and speed.y = 0, assumming it's 1fps, next frame would be: speed.y = -9.8, object.y =90.2
next would be -19.6,70.6
etc.

physik's method is s = 1/2 * a * t^2. yes that's the physics eqn to find of the position relative the to original point. works too, but smart_idiot's method would be better if the object already has a velocity

life is unfair, take advantage of it.
UNMB2 - if the link doesn't work, try clicking it

Edited by - thuned on February 7, 2001 1:35:42 AM

Edited by - thuned on February 7, 2001 1:40:30 AM

##### Share on other sites
thuned - sorry you''re also wrong.

##### Share on other sites
If you say, so, I guess I''m wrong.

##### Share on other sites
smart_idiot: you're (nearly) right, but the time increment you use (program_speed) is maybe not the best....

try something like:
  loop{ fps = time1-TimerGetTime(); // from Nehe Tut #? time1=TimerGetTime(); program_speed = time_scaler * 35.0/fps; // always runs as if 35fps speed.y += program_speed * gravity; // v=v + t*acc object.y += program_speed * speed.y; // s=s + t*v}

just make sure that gravity acts down (is negative)

alistair

Edited by - alistair b on February 8, 2001 8:47:32 PM

##### Share on other sites
smart_idiot''s formula is right (but still approximation) when objects don''t get too far. since ARID is probably needing gravity between object (falling object?) and earth, where direction gravitation force is constant, there is no need to calculate exact forces between two objects.
btw. every time when position must be updated, the addition to position shouldn''t depend on frame rate, but elapsed time.

but if you need correct gravity, perhaps between planet''s or atoms(particles?) where the direction on gravitation force is not constant there is more complex formula to calculate this than
physik''s - who probalby knows it - and I can post it here if needed.

##### Share on other sites
i think that the s += v*program_speed is right, i think you only need the total elapsed time if you''re calculating from the initial position s(time=0), i''m working out s(time)=s(time-1)+v*program_speed and i''m pretty sure thats ok ?

alistair