simulate movement with drag
Apply a vector with a coefficient of friction. You can probably make it up. Just apply it in the opposite direction of the objects velocity.
However you might need to clarify more. Like cloth? Leaves or some other objects that float? For solid heavy objects it's simple, but if you mean like object reacting to "fluid" air under themselves it might be different. (like a realistic parachute)
However you might need to clarify more. Like cloth? Leaves or some other objects that float? For solid heavy objects it's simple, but if you mean like object reacting to "fluid" air under themselves it might be different. (like a realistic parachute)
This formula computes the normal force a fluid applies on a plane moving inside of it:
F = 0.5*C*p*A*v²
where:
C = drag constant(try something like 0.3 . . .
p = fluid density in kg/m³(air density = 1.29kg/m³)
A = surface area
v = surface velocity
Use the normal vector of the plane inside the function to correctly apply the drag when its normal is not parallel to its velocity vector(dot product)...hope this helps . . .
F = 0.5*C*p*A*v²
where:
C = drag constant(try something like 0.3 . . .
p = fluid density in kg/m³(air density = 1.29kg/m³)
A = surface area
v = surface velocity
Use the normal vector of the plane inside the function to correctly apply the drag when its normal is not parallel to its velocity vector(dot product)...hope this helps . . .
Author
Quote:Like cloth? Leaves or some other objects that float?No, a flying robot.
Quote:F = 0.5*C*p*A*v²Yes that is the problem I'm having ATM. If I use different time intervals to calculate the acceleration changes. It has a non-uniform acceleration (changes at every instant in time) which affects final velocity. So I'm trying to find an equation to calculate the velocity at a specified time since acceleration can't be used.
you need to compute the velocity through acceleration. To simulate this drag equation with more precision, try using Runge-Kutta4 Integration.
Is this not accurate enough for your purposes?
//gameloop
//your physics here
velocity*=0.9f;
//render
//end of loop
and if your timestep is not fixed, well, fix it
heh, bad pun...
//gameloop
//your physics here
velocity*=0.9f;
//render
//end of loop
and if your timestep is not fixed, well, fix it
heh, bad pun...
Author
Quote:you need to compute the velocity through acceleration. To simulate this drag equation with more precision, try using Runge-Kutta4 Integration.I don't think I should be using the acceleration since it can't be used to predict future velocities because after that point in time the acceleration changes. What type of graph is RK4? y = x^2? y = 1/x?
Quote://gameloop"your physics here" is what I'm trying to figure out. By timestep I'm guessing you mean the time difference between each loop of the program. Technically there's no way to make it "fixed", or either I haven't learned to make a program execute in exact loops/second. Is that what you mean by timestep?
//your physics here
velocity*=0.9f;
//render
//end of loop
and if your timestep is not fixed, well, fix it
heh, bad pun...
edit: I see that RK4 might be helpful but I was hoping there was a precise way of doing it. I thought there would be an equation for this?
Quote:Original post by biscuitz
your physics here" is what I'm trying to figure out.
In many games, the velocity*=.9f is a decent semblance of drag. (dont quote me on this, but I think it ends up being equivalent to a first order apprxomation)
You sure that wasnt what your game needed?
Quote:Original post by biscuitz
By timestep I'm guessing you mean the time difference between each loop of the program. Technically there's no way to make it "fixed", or either I haven't learned to make a program execute in exact loops/second. Is that what you mean by timestep?
Not exactly, by timestep, I mean the base unit of time you use when calculating physics and game logic.
At the moment, you probably have a physics update function, and every loop you call it, then in there you plug a time value into your physics equations for motion and whatnot. And you eiter get the time value from the number of loops so far, or from looking at the system clock... but the point is that it changes and could be anything.
Well, with a timestep, rather than plug unknown time values into your equations; you choose some constant time interval to use every time. To do this, on each loop you check the system clock and see how much time has passed since the last physics update, you then see how many of those timesteps can fit into that time passed, and call the physics functions that many times.
The point being that your motion equations use a constant timestep interval, rather than one that could change depending on how lagged your computer was at the moment. This makes your physics calculations more consistent. It also makes time a constant for many calculations and thus simplifies work.
Using a fixed timestep is important for the drag approximation method I listed above.
Author
atm I haven't coded anything yet because I'm stuck at the mathematics behind this. I don't see an advantage to using a constant for time interval. It won't make it any faster. Actually it sounds like it will add a divide into the mix. I'd rather use a time-difference technique so it looks better because you'll see what it is supposed to look like at that point in time. Are you talking about calculating the acceleration during that time frame? Is there any way that's not based off of acceleration because it's non-uniform.
Quote:You sure that wasnt what your game needed?I won't know unless I understand the extent of what this stuff is doing. As far as I can tell all these methods sound incorrect and I have no idea how far off they could be because I don't even know what the correct answer is.
Quote:Original post by biscuitz
atm I haven't coded anything yet because I'm stuck at the mathematics behind this. I don't see an advantage to using a constant for time interval. It won't make it any faster. Actually it sounds like it will add a divide into the mix. I'd rather use a time-difference technique so it looks better because you'll see what it is supposed to look like at that point in time.
Seeing as how we aren't even sure what integration method you are currently using, a single division operation is highly meaningless in the grand scheme of this game's efficiency.
Don't optimize until after it is complete.
At any rate, the purpose of a fixed timestep is not calculation speed, it is accuracy and consistancy.
Quote:Original post by biscuitz
Are you talking about calculating the acceleration during that time frame? Is there any way that's not based off of acceleration because it's non-uniform.
But that above point might not mean much for your project at this point... ...whats this talk about acceleration???
How about staring from the beggining, what you're simulating, and what integration/physics methods you are using.
Quote:Original post by biscuitz
As far as I can tell all these methods sound incorrect and I have no idea how far off they could be because I don't even know what the correct answer is.
*shrug* game physics can start to look pretty far off from the 'real' equations of motion; because in a game typically we use iterative approximations of the real integration math, and do it over succesive timesteps.
Additionally, game physics do not always have the goal of perfect realism, often times behaviour that is Stable and plays well is what we want.
What do You want though, and why?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
