Contraints with only one body added to space

[dieterweb]

Hi,

I want to connect a body which is handled by chipmunk to a body which is handled by our game engine (not added to space) with a constraint. But is seems that contraint do only work when both bodies are added to the space.

Any way to do what I want with chipmunk.


Thomas

[slembcke]

Well, it can work, it's just a bit trickier.

In the trunk version of Chipmunk, constraints work exclusively by modifying the velocity of bodies. I assume you are on trunk as you are using the word constraint. In that case, all you need to do is make sure you aren't overwriting the velocity change that was added by the constraint. If you are controlling the body by explicitly modifying it's velocity and/or position, then you might be in a bit of a pickle as ultimately you'll just be undoing any work that the constraint did.

What I would recommend in that case is to try using constraints to control the body instead of what you are doing now. What are you doing with the body in order to control it now?

[dieterweb]

You are right, I am on trunk.

I set the position and rotation of bodies, we handle. I do this, so The collision handling is working. In some cases we are adding the body to the sapce to let chipmunk continue to handle it.

[dieterweb]

Constraints do not work for what we are doing, I am pretty sure about that.

When I set the position of the body not added to the space, I would assume will not have any effect on the velocity of the body added to the space.

Thomas

[slembcke]

By adding the body to the space, you are asking it to update the velocity and position. The velocity is updated first by using gravity, the other forces. After that, the collisions and constraints are processed (based on the existence of collisions or constraints added to the space, not the presence of the body in the space). Finally the position is updated based on the velocity.

In your case, you aren't adding the body to the space so it's velocity is not updated by gravity and other forces. It's velocity is still modified by collisions and constraints if there are any. By simply setting the position explicitly without taking it's velocity into account, the constraints have no way of having any control. Also, by setting the position explicitly, but not making sure that the velocity is synchronized, objects colliding with any of it's shapes will not know that it is moving and the collisions may look soft.

[dieterweb]

Ok, I got the point that I should update the velocity when changing the position. Can you point me to the right direction how I caculate the velocity and rotational velocity based when changing this on my side?

A rough estimate should be enough.

But let me explain my problem again, as I think you maybe misunderstood it.

I have two bodies (A and B), each with one shape. I connect the two bodies with a pivot joint. Body B is added together with its shape to the space. Body A is not added to the space, but its shape is added to the space. The joint is added to the space.

Now I move body A with my own code by setting its position and rotation.

I would assume that body B is behaving as if body A was moved by chipmunk, but it is not. It is following body B, but very slowly.

Hope thats understandable.

Thanks for your help.

Thomas

btw: Just saw your new upcoming iPhone game. Looks fantastic.

[slembcke]

Ah, Ok. Now I see what you are trying to do.

If you aren't updating the velocity of body B, then the only thing that the joint sees is that it needs to correct the distance between the objects, and this is done slowly over time. Because Body B has no velocity, it doesn't know to transfer the movement to Body A.

To keep the position and velocity in sync when updating the position of Body B, you would just need to calculate the velocity as the displacement/time:

Code: Select all

        cpVect delta = cpvsub(newPos, body->p);
        body->p = newPos;
        body->v = cpvmult(delta, 1.0/dt);

This works best when you make smooth movements of the body. Making sudden or large changes in position will still have issues. Beware of mouse input coming from your OS for this reason. Instead of getting a mouse position update every frame your game renders, you will likely get 10 of them a second. If you link the physics directly to this, you will mostly have non-movements with an occasional sudden movement. It's always best to smooth the input first.

[dieterweb]

Again, thx for your fast and helpful reply.

We do not use this for mouse input. Its for slow moving objects.

Thomas

[dieterweb]

I have not tried the contraints yet, but I now change the velocity of self managed bodies correctly. Makes the simulation even better, thx!

One more (maybe silly) question. What formula do I use to change the rotation velocity when changing the rotation within our code?

Ok, I noew tested the contraint thing:
Its not really working. The chipmunk controlled body is moving faster than the self controlled one. Its also drifting down. My theory is that this happens because the updating of the position and velocity of the self controlled body is not synchronised to the chipmunk space step. The space step happens with a fixed time step so depending on the fps more or less often than the function updating non-space bodies. On the other hand this should be no problem as this should be handled by the dt-time each function receives.

When I think more about it the reason for the drift down of the chipmunk body could be that I do not add a component to the velocity taking care of the gravity as self controlled bodies are not effected by it.

Any more ideas?
thomas

[slembcke]

Setting angular velocity is basically the same thing, but instead of displacement/dt you use anglar displacement/dt. If you know the angular change you want, it's easy. If you just know the resulting rotation, and want to get the shortest angle you would do this:

Code: Select all

cpvtoangle(cpvunrotate(rotation_vector_b, rotation_vector_a))

If you aren't moving the body during the same fixed update as other bodies are moved during the space step, that could be problematic. As for the downward drift, there are a couple of possibilities I can think of. If the externally controlled body didn't have an infinite mass and/or moment of inertia, the constraint could be affecting the velocity of it between the times when the body's velocity updates are done and when the physics steps are done. The body would have a slight downward velocity that would get transfered through the constraint and the other body would fall until it met an equilibrium point between the correction impulse applied by the constraint and the phantom velocity that it was imparting on the externally controlled body. Adding a few logging statements of the velocity before and after stepping the space can verify. The other possibility is that the calculated velocity for the body is incorrect. This is also easily verified with some logging statements.

One of the few advantages of simple vertlet integration and distance constraints to do physics is that it's basically impossible to get the position and velocity out of sync. The velocity is stored implicitly, and you can move things around simply be setting particle positions. On the other hand, having a separate velocity and position state allows you to do some interesting effects in a rigid body physics system. For instance you can approximate an earthquake by randomly setting the velocity of your static body and leaving the position alone. Anything touching the ground will get tossed around. You can use the same trick to make bumpers, conveyors, or jump pads.