Momentum

[Senseï]

Hi all,
I've been playing with this handy physic engine for a week.

I'm defining new Force implementation and I wonder how to apply an
angular momentum to a body. Should I use applyImpulseToMomentums ?
Unfortunately I don't understand what are 'r' and 'J'.

Can you help me ?

Tanks.

[mo]

Hi :)

The intended way is using

applyForce( r, F, dt)

which adds the contribution of your force to the body. However, i
realized there was not really a simple way of applying torque (the
angular part of the force) directly. So I added this method to svn:

Body.applyGeneralizedForce( Vector3 f, Vector3 tau, double dt )

Now, if you only want to apply an angular effect, set f=0 and put the
contribution in tau. Let me know how it works.

[Pierre LABATUT]

Hello,
   I would like to talk about geometry positioning, and convex hull sharing.

We previously said that it is assumed that Geometry instance center of mass is at (0,0,0) of geometry local coordinates. A side effect is that ConvexHull instances translate the vertex that composes the hull to place the center of mass in zero when it is not the case.  As a consequence it uneasy to draw a complex mesh at the same place as the hull, cause this translation is unknown.

1- Change Geometry interface to publish a mass center coordinate. The inertia matrix is still computed at the mass center place. This one makes Geometry interface more complex. Do you think it is going to be necessary for future feature ?
2- Set the current local transformation of the geometry to the inverse of the one applied to convex hull vertices's. Then the vertex doesn't moved in Body's space.

Do you thinks it is affordable ?

The second point is convex hull data & computation sharing. I created lots (5000) of body and ConvexHull Geometry. I solved a blocking performance issue by implementing an alternative to MassProperties. QuickHull algorithm still takes time, a I fear that some day, I will have memory consumption issues. For now it works, but I would like to have your view on how could we share Inertia matrix, hull & dual over geometries, or even geometries over bodies.

 

Pierre

[Morten Silcowitz]

> 2- Set the current local transformation of the geometry to the inverse of
> the one applied to convex hull vertices's. Then the vertex doesn't moved in
> Body's space.

I'm not sure how this correlates to this idea, but I also have some
ideas on how the body/geometry thing should work out in practice:

1. when a geometry is added, then the tensors and mass stuff is
updated incrementally, so that we avoid having the method finalize().
This should be the same when removing a geometry.

2. when you add/remove a geometry, all geometries should remain in
the same world-space position and orientation. We therefore update the
local transforms of the geometries AND the position of the Body.

3. The centre of mass point that is computed by convex hull is just
stored in Geometry as you say. Then, it can be taken into account when
computing the tensors, but we avoid having to move the vertices to the
centre of mass frame.

> The second point is convex hull data & computation sharing. I created lots
> (5000) of body and ConvexHull Geometry. I solved a blocking performance
> issue by implementing an alternative to MassProperties. QuickHull algorithm
> still takes time, a I fear that some day, I will have memory consumption
> issues. For now it works, but I would like to have your view on how could we
> share Inertia matrix, hull & dual over geometries, or even geometries over
> bodies.

Yes this is an issue for sure. I think it should not be very hard to
make a copy a ConvexHull that shares the same geometry data. I'll
think about that :)