Temporary linking of objects

[lovatwest]

I am trying to link objects temporarily. I have an industrial based simulation which requires an object to be passed between various mechanisms for travel in vertical or horizontal planes. (At different times). In reality there are pneumatic locks to hold the equipment down, but rather than intricate modelling, I am trying to find some method to temporarily attach the object to another for transport and delivery. (And subsequent pickup and return).
Any ideas?

[Julio Jerez]

you can use teh apropriate joint to liek teh objects, and get teh pointe to teh joint.
then when you do no need it you can simple destroy the joint.

[lovatwest]

I had hoped there was a different method of accomplishing this. I am currently trying to get the joints to destroy cleanly, but I keep getting exception errors. Is there any particularly easy method to get rid of the joint? I suspect I do not have the destructor set up properly for the joint class.

[Julio Jerez]

this is the cleanest way

NewtonDestroyJoint(const NewtonWorld* const newtonWorld, const NewtonJoint* const joint);

Constacts are also joints, I will very surpriced if the function makes the engine crash, because that same function the engine uses to destroy contacts by the tousands during a typical simulation.
you just need get a hold of your joint pointer and call that function, the joint will be deleted

if you add a destrutor to the joint then your dectructor will be call when the joint is about to go away, but you do not need a destructor.
destructors in joints are useful for customs joints, because some of them have local data, but that is all.

[lovatwest]

Thanks for the quick reply. I had been through the mass of various functions with no success. However, it was not the functions, (of course), that was the problem. The command to latch/unlatch will come from another external program, thus one only needs to latch once, and only unlatch if latched, &etc. After much embarassment, a simple boolean flag allows/controls a single latch/unlatch cycle and the simulation development is now proceeding once again.

[lovatwest]

Ok, another question. I have on object which is connected to a slider joint in the "Y" direction and has its length oriented in the "x" axis. I have created another slider joint to suspend a second object beneath the first, such that the slider moves in the "x" axis. Because this object is suspended, the slider joint (perhaps an inverse slider) is very elastic in the "y" direction. This is very pronounced if a load is suspended from the "x" axis slider. Is there any method to adjust this apparent elasticity in the "y" direction?
I could reorder the joints to build the "x" axis slider on top of the "Y" direction slider and gravity/loads would produce a less elastic effect.

[Julio Jerez]

if you connect tow object with more than one joint, them the system because unpredictable,
this is because say you have two bodies, the number of degree of freedom between then is six.
joints eliminate or limit the ability of relative motions between the bodies by canceling degree of freedom,

each joint is designed to eleminate some of those DOF, and they do that by writing arithmetic expression that epecifi geometric relatintion between those DOF.

for example a slider will make zero motion in 5 of the 6 DOF.
if you connect the same two bodies with two or more sliders, what you are saying is that there are 12 or more DOF between those two bodies when ther can only be only 6 valid DOF.

Mathematically this translated to a matrix with rows and column who are linear combination of each other. If you know something about linear algebra,
you will know that a Matrix can only be solved if its determinant is not zero, but if a Matrix has at least two rows or Column who are linear combination of each other, then the determinant is zero.

There are ways to remove rows who are linear combination of each other, because the above example the desired effect would be motion about the free dofs.
The problem is what rows or Columns to eliminate and how to preserve the essential one from the matrix. The mathematiocal method for that is called singular value decomposition.

Newton 1.0 until 1.53 had a singular value decomposition solver to preprocess the block system matrix that is forme between tow bodies conected by a joint,
and that worked very well for joints, but it was too slow when dealling with laots of contacts.
because contacts in newton are also joints. contact has the nasty property that the generate lot of redundant rows (row who are linear combination)
for example a cylinder resting on a floor on its base will have many contacts, several of them will be redundancy, and it is was slow detrmin whci oen are essencial by using SVD..

some of the self appointed experts from Umea university started to write papers with the sole purpose to discredit me, and those test were use as trophy in some other forum.
The run plot and when teh say tthat new shod that behavior os quadraic decay with many contact, a moron from a Physios forum intepreted that as me not know what I was doing.
I tryed to explaining was happening to these people just to get very dishonest reposes from the cheerleaders, Plagiarizers and the pseudo intellectual morons on that forum.

By Newton 2.0 I decided to removed the SVD contact prune analiser from the solver and move it the functionality
to the collision system using the heuristic that contacts can only be on the perimeter of a convex plane.
This is fast but then it does not prevent the end use from doing stuff like you are trying to do.
plus it will not deal well with object link together by a joint and alloed then to collide, by that newton by defaul disable collision on bodies connectd by joints. so that is not a big problem.

The problem is that if you have an exact solver and you do not prepossess the matrix by eliminating those bad rows an and columns,
the system lead to a explosion, if you have an iterative solver that does not iterate until if finds the solution than when you get is the effect of a soft joint.
this can be explained by the follwing reason.
An iterative solver will solve each row one at a time by adding small corrections,
when it finds a row that was a linear combination of another row, the contribution of that row will almost completetly be cancelled
the contribution calculate by the previous row, so the system converge very, very slowly to a solution.
and since the solver only execute a fix number of iterations, in the end it stops with an solution that basics does nothing.
The system does not explode, but you do not get the solution either.

These erroneous solution had being interpreted as huge thenoological achievement by the self appointed experts like mister Adrian Boieng and Keenny Bodin from Umea University, (and true pair of complete itelectual morons with PHD degrees)

[lovatwest]

I understand the working for the two joints, and I do have it working at a more acceptable level.

I would not consider myself a math expert, but I understand your point that the matricies used must be solvable. Boundary conditions can be problematic and one needs to balance accuracy and computation speed, and which one of these is favoured depends on what you are doing. Redundancy will cost you speed, overly simplistic assumptions may cause inaccuracy. In some cases there is no "ideal" solution, but one that is accurate enough and fast enough.

On a different note, I am trying to use the CustomSlider to define a number of new classes of sliders. The main reason for this is to be able to individually "tune" the friction of each joint so that it behaves like the real joint. Of course, my implementation is not working. If I clone the CustomSlider class and rename it, the joints are wildly unstable. If I make new classes that use the CustomSlider class, I get the same result.

For my attempts, it seems like the joints are built, but not linked into the physics engine the same way as if I used a "standard" CustomSlider, thus the instability. Any helpful suggestions on this one?

[JoeJ]

I've used a similar way to begin with joints:
Create a new class, copy code from the joint lib, change a few things like merging with base class to keep it simple...
It should work, you can replicate anything from the joint library with little affort.
Have you tried the simplest possible joint, point to point? That should be stable and easy to extend to a little more complicated constraint.
Pick and drag interface is good to stress and test your work.
You can also post your code, so we can see what's wrong.

Also, i can't follow the description about the two sliders, illustration,screenshots would be helpful.
Maybe both sliders could be rethinked as a single joint?

[Julio Jerez]

can I see the code for your joint?

[Julio Jerez]

Maybe both sliders could be rethinked as a single joint?

yes that is the only correct solution.

[lovatwest]

First, an explanation of what I am attempting to do, then followed by some code examples. This is an industrial simulation, and for this particular setup, there are 2 columns defined approximately 10 units apart in the x-axis. The columns are 12 units tall in the Y-axis. A platform is defined between the two columns and connected to each column using a slider joint allowing movement in the y-axis only. A second object is attached to the underside of the platform by a slider joint which allows movement in the x-axis, but only over a specified portion of the platform. (i.e. it cannot travel the entire x-axis length).

I hadn't thought of this as a one dual axis joint, but I am not sure it would work here. It will work in other parts I have yet to build, but I would like to keep it simple for this one.

If I use the base "CustomSlider" class and methods, these joints work fine. The desire is to add friction to the joints, but to define the joints as separate classes to allow to customize a particular joint. So the first attempt was to plagerize the CustomJoint class and method and produce: (I have only added the initial portions)

The definition:

#if !defined(AFX_CUSTOMREACTORCOLUMNSLIDER_H__B631F556_468B_4331_B7D7_F85ECF3E9ADE__INCLUDED_)
#define AFX_CUSTOMREACTORCOLUMNSLIDER_H__B631F556_468B_4331_B7D7_F85ECF3E9ADE__INCLUDED_

#include "NewtonCustomJoint.h"

class JOINTLIBRARY_API CustomReactorColumnSlider: public NewtonCustomJoint
{
public:
CustomReactorColumnSlider (const dMatrix& pinsAndPivoFrame, const NewtonBody* child, const NewtonBody* parent = NULL);
virtual ~CustomReactorColumnSlider();

void EnableLimits(bool state);
void SetLimis(dFloat mindist, dFloat maxdist);

bool JoinHitLimit () const ;

protected:
virtual void SubmitConstraints (dFloat timestep, int threadIndex);
virtual void GetInfo (NewtonJointRecord* info) const;
dMatrix m_localMatrix0;
dMatrix m_localMatrix1;

bool m_limitsOn;
bool m_hitLimitOnLastUpdate;
dFloat m_minDist;
dFloat m_maxDist;
};

#endif // !defined(AFX_CUSTOMSLIDER_H__B631F556_468B_4331_B7D7_F85ECF3E9ADE__INCLUDED_)

And a sample of the methods:

CustomReactorColumnSlider::CustomReactorColumnSlider (const dMatrix& pinsAndPivoFrame, const NewtonBody* child, const NewtonBody* parent)
:NewtonCustomJoint(6, child, parent)
{
m_limitsOn = false;
m_hitLimitOnLastUpdate = false;
m_minDist = -1.0f;
m_maxDist = 1.0f;

// calculate the two local matrix of the pivot point
CalculateLocalMatrix (pinsAndPivoFrame, m_localMatrix0, m_localMatrix1);
}

Of course, it is called in a similar fashion as the CustomSlider.

CustomReactorColumnSlider* theSENRColumnslide;

dMatrix SERBridgelocation( dgGrammSchmidt( theSEN_RColumn->m_matrix.m_up ) );

SERBridgelocation.m_posit = theSE_RBridge->m_curPosition;
SERBridgelocation.m_posit.m_w = 1.0f;

theSENRColumnslide = (CustomReactorColumnSlider *) new CustomSlider( SERBridgelocation, SE_RBridge, SEN_RColumn );
theSENRColumnslide->EnableLimits( true );
theSENRColumnslide->SetLimis( -0.9f, 15.0f );

If I use CustomSlider, the joints behave as expected. If I use the "new" class, the joint flies apart when moved.

Obviously, I have missed something, and am doing something incorrect. Any insight would be very helpful.

[JoeJ]

Your base class is NewtonCustomJoint so SubmitConstraints (callback where the work gets done) is missing?

I could miss something myself here because i'm not so good with inheritance, use it very rarely.
That's the reason why i would copy any code from NewtonCustomJoint AND CustomSlider into your CustomReactorColumnSlider class.
For a single joint this gives less code and is easier to understand for starting up. You can avoid including and linking JointLib this way.
Sorry, i don't have a better tip than that.

However, i understood your goal and i'm sure this is possible.

[JoeJ]

Here the minimal Point To Point constraint i was talking about.
It's easy to see that on callback you use some geometrics to setup rows which newton solves for you.
It looks complex in JointLibrary, but is quite simple.
And very flexible and powerful.
I made a quaternion twist joint with semi-ellyptical swinglimit and motor - perfectly stable - that was never possible with other physics engines.

Code: Select all

class CustomJointP2P
{
public:

   Body* body0;
   Body* body1;
   Joint* joint;
   sMat4 localMatrix0; // usual 4x4 matrices to define the pin position for each body in its local space
   sMat4 localMatrix1;
   
   CustomJointP2P (World* world, Body* body0, Body* body1, sMat4& localMatrix0, sMat4& localMatrix1)
   {
      Joint* joint = NewtonConstraintCreateUserJoint (world, 3, CustomCallback, 0, body0, body1); // we use 3 rows
      NewtonJointSetUserData (joint, this);
      this->joint = joint;
      this->body0 = body0;
      this->body1 = body1;
      this->localMatrix0 = localMatrix0;
      this->localMatrix1 = localMatrix1;
   }


   void SubmitConstraints ()
   {
      //construct pin position in global space for each body
      sMat4 matrix0, matrix1;
      NewtonBodyGetMatrix (body0, matrix0); matrix0 *= localMatrix0;      
      NewtonBodyGetMatrix (body1, matrix1); matrix1 *= localMatrix1;
      
      //use body0 orientation to fuse pin positions on each axis' plane
      //[n] operator gives x,y,z axis if [0...2], and positon if [3]
      NewtonUserJointAddLinearRow (joint, (float*)&matrix0[3], (float*)&matrix1[3], (float*)&matrix0[0]);
      NewtonUserJointAddLinearRow (joint, (float*)&matrix0[3], (float*)&matrix1[3], (float*)&matrix0[1]);
      NewtonUserJointAddLinearRow (joint, (float*)&matrix0[3], (float*)&matrix1[3], (float*)&matrix0[2]);
   }
}

// utility to let newton call the class method
void CustomCallback (const NewtonJoint* joint, float timestep, int threadIndex)
{
   CustomJointP2P* custom = (CustomJointP2P*) NewtonJointGetUserData (joint);
   custom->SubmitConstraints ();
}

EDIT: Reverse matrix multiplication order if using Newtons dMatrix.

[lovatwest]

The current new slider code is an exact copy of the CustomSlider code, I did not post it all, so my apologies there. I have trying to debug the code and in both cases I do not see any differences in how the joint is made or configured. Once the simulation starts, the new joint flies apart when touched. The CustomSlider does not, (obviously).

I had not thought about including the code from the NewtonCustomJoint. I will give that a try to see how it works. My suspicion is that the new code is not inheriting enough of something, but I can't tell why. Yet.