since Bullet V2.76, various FRAME_OFFSET defines..

[marcimatz]

Hello,

Since Bullet version 2.76, most constraints have a new define added, e.g.:

#define USE_OFFSET_FOR_CONSTANT_FRAME true // btSliderConstraint
#define D6_USE_FRAME_OFFSET true // btGeneric6DofConstraint
#define HINGE_USE_FRAME_OFFSET true // btHingeConstraint

I noticed strange behaviours of btSliderConstraint and btGeneric6DofConstraint in version 2.76 (compared to version 2.75). If relevant, I will describe those strange behaviours in a next reply, but the interesting thing is that if I set those defines to false, then all seems alright.

My first question now is, what is the meaning/purpose of those defines? If I set them to false, will I eventually get other problems? (also in a future version?)

Thanks

[Erwin Coumans]

Please describe the strange constraint behaviours in Bullet 2.76. If possible, also show it by modifying the Bullet/Demos/ConstraintDemo (or another Bullet demo) that compiles with Bullet 2.76.

Thanks a lot,
Erwin

(by the way, I just noticed #define USE_OFFSET_FOR_CONSTANT_FRAME true in btSliderConstraint.cpp seems unused and m_useOffsetForConstraintFrame is un-initialized in latest trunk,
I'll check with Roman. Also, you probably noticed that those settings can be tune using get/setUseFrameOffset)

[marcimatz]

Hello Erwin,

The btSliderConstraint's strange behaviour is resolved in the latest release (v2.76, r1963).
About the btGeneric6DoFConstraint:

I am using that constraint also as a force/torque sensor, and I noticed that the 6 constraint equations have changed from previous release (v2.75):

before, the first 3 equations were positional constraints, then the 3 last equations were orientational constraints.
In v2.76, the following define:

#define D6_USE_FRAME_OFFSET true

has the effect to swap the positional and orientational constraint equation order, which is no big deal and easy to adjust for, however the orientational constraints seem to be formulated in a different way if that define is kept to true.

So my question was what the purpose of that define really is? Because a similar define can also be found in btSliderConstraint, btHingeConstraint, etc. And obviously that "functionality" can be turned on/off through get/set functions.

Thanks

[Erwin Coumans]

The btSliderConstraint's strange behaviour is resolved in the latest release (v2.76, r1963).

We made more changes, can you try if r1971 still works for the btSliderConstraint?

About the btGeneric6DoFConstraint:

I am using that constraint also as a force/torque sensor, and I noticed that the 6 constraint equations have changed from previous release (v2.75):

before, the first 3 equations were positional constraints, then the 3 last equations were orientational constraints.

In v2.76, the following define:

#define D6_USE_FRAME_OFFSET true

has the effect to swap the positional and orientational constraint equation order

The main improvement is that for constraints that are far away, the constraint 'arm' is reduced so that constraint error is less. I leave it up to Roman for a better explanation, I asked him to keep the option to revert to the previous behaviour, for backwards compatibility and testing (such as your tests).

I'm not sure this change in constraint order was intentional, can you explain what adjustments you need to make exactly?

Thanks for the feedback,
Erwin

[marcimatz]

I tested the btSliderConstraint in r1971, everything seems alright.

>>can you explain what adjustments you need to make exactly?

Actually I added a few lines in btSequentialImpulseConstraintSolver so that I can extract applied impulses for the btGeneric6DofConstraint (which then allows me to use the btGeneric6DofConstraint as a force and torque sensor).

I check constraints from the m_tmpSolverNonContactConstraintPool (in solveGroupCacheFriendlyIterations), since each btGeneric6DofConstraint can generate a maximum of 6 constraints in that pool. Reading the applied impulse of a constraint in that pool eventually allows me to extract forces along x,y,z and torques about x,y,z (relative to the btGeneric6DofConstraint frame).

Now the new version builds the 6 constraint equations in a different order (i.e. different row, setAngularLimits function is called before or after setLinearLimits function) for "stability" as indicated by a comment in the code. But in addition to this, angular constraints are handled in a different way so that I cannot extract the torques as previously.

Well, I hope you can understand anything from what I tried to explain here above I am not saying that it doesn't work, just it is not compatible with my previous code anymore. Just wanted to know some more details before trying to adjust my code to the new version.