• Advertisement
Sign in to follow this  

torque due to gravity

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm working on a simple spring simulation (explicit-Euler for now, but that shouldn't matter for these purposes). A spring is connected to the top right edge of the cube (to get torque in only 2D). The spring exerts a force on the edgeof the cube towards the anchor point of the spring. A torque is generated by this force by the spring, which is handled appropriately to rotate the object. All this works fine, until I try to add gravity. I add force due to gravity to the center of mass for each object, after torque has already been calculated. The simulation works fine if I only apply linear acceleration to it (I.E., the spring attached to the center of mass of the cube instead of an edge). Calculating rotational motion makes the simulation go nuts. It obviously has something to do with the way I'm applying gravity. I tried the following but it launched the cube off to never-never land where my matrices and forces all say each value is "+1.#Q0" when I print them to screen:
o->T += CrossProduct(r, p->F); //this is correct

o->T += CrossProduct(r, vector3(0,-9.81,0) / o->inverse_mass); 
//when I add this second line it does nuts
How do I resolve this? How do you guys apply gravity? image removed to save bandwidth Red line is the spring. Text quantities are in fundamental units (ie g instead of kg). The red boxes with blue lines are cameras. Spring anchored to origin (the rgb (xyz) axes). The cube will continue to spin counter-clockwise, and the angular acceleration damping based on angular velocity will never bring angular velocity lower than .5 hz (the damping works in non-grav conditions) Apologies for 50 bazillion edits [Edited by - thedustbustr on January 5, 2005 5:45:02 PM]

Share this post


Link to post
Share on other sites
Advertisement
gravity does not generate torque, only linear acceleration. It's a constant force field (mostly). The gravity force is exerted at the centre of masse of the object.


o->T += CrossProduct(r, vector3(0,-9.81,0) / o->inverse_mass);

this will be adding a force at the point of contact between the spring and the box.

Share this post


Link to post
Share on other sites
Thats what I thought, but I couldn't come up with a different explanation for the spring going nuts.

Is it possible that the spring is causing it because the cube does not collide with it? Thus the angular momentum of the rapidly spinning cube (because its moment is pretty small) causes it to spin around until the spring can accelerate it again?

Share this post


Link to post
Share on other sites
I'm not sure I follow 100% (well, I'm sure I'm not), but yeah, that would cause weird things, I don't think there is a stable point in that kind of system where the box and spring can rest happily (whereas with normal gravity, it should all come to rest without too much trouble).

Dunno, I'm not sure how the effect looks like, but it should be pretty screwed.

Share this post


Link to post
Share on other sites
would you mind looking at an executable? My model is obviously unacceptable, but I don't know how to fix it because I'm pretty sure my spring force is correct.

exe

WASD/mouse movement, 1-6 selects camera. physics simulation only happens while space is held down (useful debugging). It's running at 1 tenth speed by default to prevent it from going out of control too fast (configurable by ini).

It is using damping proportional to velocity, by the way.

Share this post


Link to post
Share on other sites
I can't coz I am missing the .NET dlls (msvcp71d.dll, and maybe others...)...

Share this post


Link to post
Share on other sites
no matter, I found them....

well, is that with the weird gravity torque? If it is, just remove the torque.

Share this post


Link to post
Share on other sites
No, thats normal gravity applied as Force += 9.81m/s/s * mass. No torque due to gravity at all. It SHOULD work :\

Share this post


Link to post
Share on other sites
About the spring going nuts...you've admitted that you're using explicit Euler integration. If you research past threads you'll learn that explicit Euler is unstable when your system includes springs. So, that could ultimately be the problem. And maybe you just excited the springs when you added the torque from the force due to gravity. Add damping and reduce the time step to make explicit Euler stable, or switch to another integrator.

Share this post


Link to post
Share on other sites
Also, in the interest of education and enlightenment, I'll say that what oliii said about gravity/weight and torque is only sorta true. The net torque due to gravity about the center of mass is zero. (Please let me know if this is more than you wanted to know, :) !)

However, gravity/weight absolutely causes torque when rotation is considered about other points. This idea is kind of glossed over or ignored in physics simulation for games/graphics, but is part of the core curriculum of undergraduate mechanical engineering. So, I'll make a few comments that may (hopefully) help in some small way, :).

Normally, for freely moving/unconstrained rigid bodies we write the equations of motion about the center-of-mass. This simplifies the equations when the center-of-mass can move freely in space. However, when an object is rigidly hinged about a line that does not pass through the center-of-mass (for example), it is sometimes more convenient to write and solve the equations of motion about a point along that line, in which case, the net force due to gravity (the object's weight of course) does indeed cause a torque.

You actually can write the equations of motion about any point in the body, and the various forces contribute in different ways. The net torque and net force on the body is ultimately the same regardless of which point you choose for your equations of motion, though. Look at the case of a bar cantilevered onto a wall. Its center-of-mass isn't free to move anywhere it pleases. If you write the equation about the center-of-mass, the vertical shear reaction force at the wall (which balances the weight of the bar to keep it from sliding down the wall) also causes a torque about the center of mass. That torque is counteracted by the torque due to the net torque generated by a horizontal force distribution through the thickness of the bar that keeps the bar from separating from the wall. I try to illustrate below this case, which delves into the mechanics of materials a bit.

Here is a free-body diagram of the bar. The bar is cantieevered on right edge. 'x' marks the wall. P is the center-of-the-wall. The arrows, ---->, etc., represent the various forces acting on the bar. The left edge, indicated by '|', is free, not connected to anything.

|------------------------------------x -----> H
| x ---->
| x V --->
| x ^ -->
| C.M. x | ->
| | x | >
| | P <
| V x <-
| X x <--
| x <---
| x <----
|------------------------------------x <-----


Here, W is weight, acting through the center of mass. V is the vertical shear reaction force at the wall that balances the weight to keep the bar from sliding down the wall. H is a distribution of horizontal stress (force per unit area) that acts through the thickness of the bar. H is a reaction to the bar's weight trying to cause the bar to rotate. Above point P, H pulls the bar towards the wall, and below point P, H pushes the bar away from the wall. (Might be easier to think of this in terms of the equal-but-opposite force acting on the wall....Above point P, the bar pulls on the wall---the wall pulls back. Below point P, the bar pushes on the wall---and the wall pushes back. This is Newton's Third Law of Motion in action!)

If we write the equations of motion about C.M. (center of mass), the following is true:

1) weight causes no torque about C.M.
2) weight causes force in negative Z, which is counterbalanced by the shear reaction force, V
3) reaction force V causes a moment about C.M., which is counterbalanced by the torque due to the integration of H through the thickness.
4) Net horizontal force acting on the bar is zero, since H contributes half of its total force in positive X and the other have in negative X, e.g., it counterbalances itself.
5) Net vertical force is zero, since torque due to V about C.M. counterbalances torque due to H about C.M.

Now look at equations of motion about point P:

1) Weight causes a torque about P, which is balanced by the torque due to H.
2) reaction force V causes ZERO moment about P
3) H causes a torque about P that balances the torque due to weight about C.M.
4) Net horizontal force = 0 as before
5) Net vertical force is zero as before

So, there you have it. In one case gravity exerts a torque, and in the other case it does not. But the net effect on the bar is the same in either case. Hopefully this commentary has a bit enlightening and helpful.

Share this post


Link to post
Share on other sites
Thank you for the explanation.

I found this in your post history (I wish search was working, manually going through posting histories is a royal pain)- could you explain this further?
Quote:
The way a damper works is this:

Damper Force = -cv

where c is the damping factor and v is the velocity component of the object parallel to the damper and measured relative to the other end of the damper and . For example, if the damper is connected to objects O1 and O2, with velocities V1 and V2 (measured in world space), and the direction of the damper is D, the damping forces applied are:

Damping Force on O1 = -c((V1 - V2) dot D)
Damping Force on O2 = -c((V2 - V1) dot D)


Namely, is D in the opposite direction of the normalized spring force? I assume I will also have to take account the linear velocity as well as the angular velocity when making this calculation?

Share this post


Link to post
Share on other sites
Quote:
Original post by thedustbustr
Thank you for the explanation.

I found this in your post history (I wish search was working, manually going through posting histories is a royal pain)- could you explain this further?


I wish search were working also. You can use google to search gamedev.net, but, as you way, it is currently a royal pain. I'm not sure what the status of search is.

From my old post, in general the damper and spring may not be colinear---might be connected to different points. But, since they often go together (even in real life----think of automobile shocks) its easiest to treat them as colinear with the same endpoints. That said, D is a unit vector in the direction from the point on O1 to the point on O2 where the spring/damper is connected.

So, then, D is defined purely in terms of geometry and has absolutely nothing to do with the spring force (a spring/damper aligned with the x axis will have exactly the same D regardless of whether the spring is at its rest length, or is compressed or stretched).

And, yes, you have to find the actual velocity at the points on O1 and O2 where the spring/damper is connected, which means you have to include center-of-mass translational velocity plus the kinematic increment due to rotation.

Share this post


Link to post
Share on other sites
This is what I came up with, but it seems not to have any effect. Is this right? [edit]OK< if I jack the constant up to 1000, it pushes the springs into a square shape with the masses at the corners... not exactly the effect I wanted.

void Spring::tick(double dt)
{
vector3 dxv=(b->world_position() - a->world_position()); //direction of force on a by b
double dx=dxv.length()-N;
vector3 F = k*dx*Normalized(dxv);

//Grhodes_at_work
//Damping Force on O1 = -c((V1 - V2) dot D)
//Damping Force on O2 = -c((V2 - V1) dot D)
vector3 va = a->parent->v + CrossProduct( a->parent->w, (a->o - a->parent->cm->o) );
vector3 vb = b->parent->v + CrossProduct( b->parent->w, (b->o - b->parent->cm->o) );
vector3 Fd = -.5 * DotProduct( (va - vb), Normalized(a->o - b->o) ) * Normalized(F);

F += Fd;

a->F += F;
b->F += -F;
}

Share this post


Link to post
Share on other sites
No, that's not correct. Do not use Normalized(F) since Normalized(F) still carries the sign of the spring force, which you do NOT want (Normalized(F) might point in the opposite direction as D, which'd put the sign on damping wrong). I guess my original post didn't have the final vector eqn for damping force. Here's what you want instead:


Vector3 D = Normalized(b->o - a->o);
vector3 Fd = -.5 * DotProduct( (va - vb), D) * D;


[Note I reversed the order of the *->o items in Normalized() for consistency with my previous, though it really doesn't matter whether you have (b->o - a->o) or (a->o - b->o) since the sign of that vector cancels out]

Then, a->F += Fd and b->F -= Fd;

Also, you've got some parent stuff in there. You need to make sure that your kinematic velocity at the point of connection of the spring/damper is represented in world coordinates for both objects....

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement