Jump to content

  • Log In with Google      Sign In   
  • Create Account

14 years ago on June 15th Gamedev.net was first launched! We want to thank all of you for being part of our community and hope the best years are ahead of us. Happy birthday Gamedev.net!

jjd

Member Since 15 Aug 2005
Offline Last Active May 05 2013 06:44 AM
-----

Posts I've Made

In Topic: [BULLET] Camera/object positions?

02 April 2013 - 08:03 PM

You might find what you are looking for in the demo code that comes with Bullet. I don't really use DirectX so I can't say for sure, but there is DirectX cloth demo, and you may be able to figure out how to manage the camera from that.

 

-Josh


In Topic: Velocity Verlet Integration

09 March 2013 - 06:06 PM

When you average the acceleration you are essentially using information from all previous timesteps and I believe that is incorrect.

I don't understand. newAcceleration is the thing that's just been worked out, by my math, making half of the average from previous timesteps and half based on new calculations.

 

Right, but it's from *all* previous timesteps and Verlet uses the acceleration from only the current and the previous timestep. The result will be that the effect of a force will persist for longer.

 

Let me put it into a mathematical form. If a_n is the acceleration at the nth timestep and there is only an effect due to gravity what you get is,

 

a(n) = (a(n-1) - g) / 2

 

Now suppose on the first iteration you have a force due to a jump, j, so the force is the sum of the jump and gravity. The acceleration of the next timestep will be

 

a(1) = (j - g) / 2

 

and after that, assuming only gravity each iteration,

 

a(2) = (j / 2 - g) / 2

a(3) = (j / 4 - g) / 2

a(4) = (j / 8 - g) / 2

 

etc, or,

 

a(n) = (j / 2^n - g) / 2

 

The effect of the jump on the first iteration will get become smaller and smaller each iteration, but it will continue to be present. And this is not what you want in the acceleration. Also, this simply adds the accelerations from different iterations without taking into account the timestep; If your delta is frame-rate dependent, then the situation becomes even messier. In general, if your are going to use multistep integration methods you should make sure that you are using a constant timestep.

 

If you want to allow delta to vary I would suggest you use something like semi-implicit Euler. Otherwise you are going to have to explicitly store the previous acceleration rather than the average to use velocity verlet.

 

-Josh


In Topic: Velocity Verlet Integration

09 March 2013 - 10:43 AM

Are you suggesting I get rid of the Verlet integration altogether?

 

No, what you are doing is not verlet integration. 

 

[edit] I shouldn't say that, what I should say is that explicitly retaining the acceleration between iterations is not something you should be doing with any of the common integration schemes.

 

[edit + apology] Apparently I have not looked carefully enough at velocity verlet in a while and I am totally wrong. I see how it is retaining the acceleration from the previous time step, so clearly I need to familiarize myself with this material again. However, there is a difference between using the acceleration from the previous timestep and averaging the acceleration. When you average the acceleration you are essentially using information from all previous timesteps and I believe that is incorrect.


In Topic: Velocity Verlet Integration

09 March 2013 - 09:08 AM

I need the air resistance to slow the player down, else there is noting to stop it. Isn't the gravity constant in this? And technically The jump acceleration is only applied one, as after it's accelerated into the air once, yCollision is no longer true and it no longer accelerates.

 

In a platformer, I don't think you should need air resistance to slow you down. If you find it is necessary you are probably doing something wrong. This is part of the reason why you should remove it because it could be masking a larger problem with the way you are handling acceleration. You can always put it back in, but I would remove it to debug the problem.

 

As I said, you should not be storing the acceleration over successive iterations. Remove the averaging. The acceleration should be zero at the beginning of the iteration. The "memory" of the effect of the acceleration will naturally persist through the velocity. 

 

-Josh


In Topic: Velocity Verlet Integration

09 March 2013 - 08:27 AM

There are a couple of things that I would suggest to try. The first is to simplify the solver -- since it is not working the way you expect -- by removing the air resistance (my guess is that you're going to end up getting rid of it eventually anyway). Secondly, you don't want to store the acceleration over successive iterations. Gravity should be a constant source of acceleration and the acceleration due to, say, jumping should only be applied once.

 

-Josh


PARTNERS