Physics Simulation Forum

I would doubt whether this is the root for this problem. If you initialize the GenericConstraint, you need to specify two rigid objects, how did you do that ?

I get all the information for the constraint from the btPersistentManifold for the two objects. I have a somewhat complicated collision reporting system built around the construction and destruction of collision algorithms and their manifolds. Totally unrelated but that was harder to pull off then it should have been and I kinda wish that system would be improved. =\

Anyway, when one of my collision report classes is constructed, it gets the data of the two objects from the collision algorithm/contact manifold.

If this help: this issue also happen to me, and only customized things I have are:
- world scaled by 64, so sphere with radius 64 corresponds to the sphere with radius 1 while normal usage of bullet
- simulation locked to pure 2d setLinearFactor(1,1,0) and setAnguarFactor(0,0,1)

have you done any of those things?

Actually, I am not asking how you retrieve the collision information, but how you initialize the constraint ?

I can understand that the second step may help avoid unnecessary collisions. But how the first one helps ?

no,no, these things are not how to avoid the problem but I think that they may cause it. So I am asking if Mako_energy02 has set any of these

Well the information in the collision is 90% of everything the constraint needs. Unless you are asking what other functions I call on to configure it...which all I call on is locking all linear and angular axes.

Exact code:


"this" is the actual object set to stick to other things. Both are rigid bodies internally. As I said the transforms are from the btPersistentManifold of the collision, as are the rigid bodies. Vector3's automatically set themselves to (0,0,0) when initialized without parameters.



I actually do both. I have my world scaled by 100 though, trying to simulate down to centimeters. And all the objects that move are locked out of moving on the Z axis(setLinearFactor(1,1,0)), but are free to rotate on all axes.

Edit: following this vein of thought I disabled the locking of the Z axis movement to see if that had an impact and it did not. Constraint is still extremely erratic and unstable with completely free movement.

Yeah, actually, this is what I asked for. I suppose "ActorA" is the green stone, and "this" is the tray ? Or the other way around ?

The question is that your tray is a compound shape, and it is composed of several rigidbodies (Ra, Rb, Rc). Assuming that you initialize your constraint with (Ra, Stone), even though you disable the collision detection between Ra and Stone, the collision between Rb, Rc and Stone will result in this erratic rotation.

Other way around.



This is very incorrect. A compound collision shape does not need or use multiple rigid bodies. It just has child collision shapes. There are only two collision objects involved in this collision whatsoever.

Oh, yeah, Sorry, I messed up with the notion of Collisionshapes and collisionobjects.

Emmm, then I am lost right now....

Regarding the setup and initialization? Or regarding the cause of the issue?

If the latter then I am right there with you. Honestly this seems to be some obscure low level thing that only Erwin can probably comment on. But he hardly checks the forums anymore.

I mean the latter one...

We lack help from the people who wrote these codes at the earliest. It makes some problems difficult to deal with.

I've encountered what appears to be the exact same behavior in a slightly different context. In the process of experimenting with the various types of constraints, I created two identical cubes with a constraint between them as seen in figs 3, 4, and 5 of the Bullet User Manual. All the other constraints seemed to work fine, but when I tried the btGeneric6DofConstraint I ended up with a crazily colliding system like Mako described.

For example, this slider constraint behaved exactly as I expected:



While this generic6dof constraint caused the two-cube system to cartwheel wildly all over the place, constantly gaining energy:



Mako, it sounds like you could get away with a btSliderConstraint constraint with a locked linear limit; based on my observations, you might want to try that. I'd still love to know what's going wrong though.

This was a really good idea, and I updated my code to test this...but it doesn't appear to have changed the behavior. I triple checked the modified code and even built clean because it seems unlikely that the behavior would be completely unchanged, but none of that seems to have worked. =\

Hi, in your code, I noticed that the upper limit for angular is less than the lower limit. Would you please edit these values and try again to see if that works ?

Cheers !