On the fly sticky constraint unstable.

[Mako_energy02]

I'm currently trying to set up sticky objects in my engine. So far I've opted for trying to use a generic6dof constraint that is locked on all axes to accomplish one object sticking to another. I have some callbacks setup (in my code, and not being used by any bullet code or callbacks) to generate the constraint on the fly when an object that is set to be sticky collides with another object.

For the most part this works well but there is one crippling issue. After the objects are constrained to each other the objects seem to generate energy and want to explode apart but are constrained, so they can't. I am passing in "true" to disable collisions between the two bodies when adding the constraint to the world, I triple checked that one. I even removed it as a test and let it stay false, and the behavior stayed the same. Not sure if that means they are colliding with each other and the setting to not collide didn't stick for some reason or if it's something else.

Any idea's on what this could be would be greatly appreciated.

[Dr.Shepherd]

I think you may want to look into CFM/ERP, as is explained by Yann in the following post:

http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=6792

The softness of the constraint is also possible for your problem.

[Mako_energy02]

Thanks for the tip. I tried to adjust the CFM based on what was said in that forum post to "0.15" and that has helped somewhat but it doesn't eliminate the behavior. They still seem to behaving as if the objects are colliding and pushing each other apart, just the thrown object can be forced out some distance and then gradually falls back in just to have it repeat a couple seconds later. Because the constraint is more flexible it's far less explosive...but the underlying issue of the objects exerting force on each other despite my disabling collisions between them is still there. Also after that test I attempted to set the ERP to "0.4" and that seemed to make them more explosive.

[Dr.Shepherd]

Thanks for the tip. I tried to adjust the CFM based on what was said in that forum post to "0.15" and that has helped somewhat but it doesn't eliminate the behavior. They still seem to behaving as if the objects are colliding and pushing each other apart, just the thrown object can be forced out some distance and then gradually falls back in just to have it repeat a couple seconds later. Because the constraint is more flexible it's far less explosive...but the underlying issue of the objects exerting force on each other despite my disabling collisions between them is still there. Also after that test I attempted to set the ERP to "0.4" and that seemed to make them more explosive.

Did you try setting the CFM=0 ?

[Mako_energy02]

That is the default value that is set in the contact solver info when it is constructed and set in the world, which is what all constraints use unless you specifically set otherwise as I understand it. Unless my understanding is wrong somehow.

[Dr.Shepherd]

Would you please post the reference here ? I didn't find the reference saying that its default is 0, perhaps I missed out something. In the post, Yann says the default ERP is 0.2, but he didn't mention the default value for CFM.

Cheers !

[Yann]

Default CFM is already 0, yep

[Mako_energy02]

Would you please post the reference here ? I didn't find the reference saying that its default is 0, perhaps I missed out something. In the post, Yann says the default ERP is 0.2, but he didn't mention the default value for CFM.

Cheers !

On line 65 of this source file it shows the constructor that assigns defaults to it's values which CFM is among.

I'm still beating my head against this with no idea why these objects seem to be colliding even though they shouldn't be. I'm starting to wonder if it's something to do with the objects being in motion when the constraint gets added somehow messes with the internals. Prior to this all examples and my personal attempts at using constraints involved adding them to bodies not in motion before the first call to stepsimulation(). I am using other constraints in the same simulation as this and they are working as intended. =\

[Dr.Shepherd]

Ok, it indeed seems quite werid. I am lost as well. How about attaching your code here if possible ? This seems to be the only way to know what's happening in your problem.

@Yann:
Come on, dude, any suggestion ?

[Yann]

On line 65 of this source file it shows the constructor that assigns defaults to it's values which CFM is among.

Well, as we are talking about the cfm and erp values of the constraint, I think better to look here(line 159/161) concerning the initialization values. I may be wrong (I didn't trace how this value is then used), but seeing my own results when changing these values, I think it's the right place.

I'm still beating my head against this with no idea why these objects seem to be colliding even though they shouldn't be. I'm starting to wonder if it's something to do with the objects being in motion when the constraint gets added somehow messes with the internals. Prior to this all examples and my personal attempts at using constraints involved adding them to bodies not in motion before the first call to stepsimulation(). I am using other constraints in the same simulation as this and they are working as intended. =\

As far as the parameter to disable collision between objects, I'm doing exactly the same as you, so I don't really understand why it doesn't work in your case.
Here are some of my clues, tell us what you think about it:
- maybe these objects are colliding with a third object ?
- maybe your update time is too slow: if the internal tick can't reach 60Hz, then you may see this kind of behavior. In my case, I added a log message to let met know if this ever happen;

If none of these clues are right, what I would do is to set up a cfm value of 1 (meaning the constraint will not be resolved), see if it's still exploding and making sure the constraint is the cause. Then I would reduce this value to see when it starts making the wrong thing
Then I would try with an erp of 0 (still to ensure the constraint is the cause), and I would then make it grow to 0.2 (a bigger value is usually not needed, and anyway, the bigger the value, the less stable the constraint is).

Tells us what happens with cfm at 1. and erp at 0. Will maybe think of something else then... Sorry I can't provide lots of help for now on.

[Mako_energy02]

Well...sharing code would be somewhat complicated since I have my own API wrapping other API's in my engine, part of which I am using in my code to setup the sticky constraint. Most of the wrappers are paper thin and I don't add much if any logic, but it may be a slight learning curve to the un-initiated. Although it is open source and if you want to look at it you can find it here.

Specifically the part where I am setting up the sticky constraint can be found in the function here. One quick thing to note is that my collision class used for collision reporting pretty much wraps the btManifoldPoint class, but accounds for all Manifold points in a given collision algorithm for the pair in the collision. So where I'm doing things like getting the distance there, I'm getting the distance on the corresponding Manifold point.

edit: Doh, Yann posted while I was typing this. I'll try that and post again.

[Yann]

Just thinking about another clue: are you completely sure you initialized the constraint with the correct frame values ? That may be a potential responsible for this behavior too.

[Mako_energy02]

Just thinking about another clue: are you completely sure you initialized the constraint with the correct frame values ? That may be a potential responsible for this behavior too.

I'm not done testing all the combinations of ERP and CFM, but so far they all seem to make the constraint equally unstable. As for the frames...no actually. I didn't think the frame values could cause explosive constraints. I'm pretty much taking the local location from the deepest contact point for the collision and using that as the local location on both objects, and also taking their current orientation and sticking that in as the rotation for the transform passed in. Planned on cleaning that up later.

So if the contact point data is flawed in any way, then I guess that could be an issue. Although in most cases the object lands where I expect it to when it hits. Sometimes it triggers off the second object it collides with but I haven't been able to rule out an issue in my code for that one. I do check the contact point to make sure it has a <=0 penetration distance and a >0 applied impulse, since I was having significant failures before those checks with the values in the contact point being absolute jibberish. I have another post on this forum recently where I was complaining about that. ><

[Dr.Shepherd]

Just thinking about another clue: are you completely sure you initialized the constraint with the correct frame values ? That may be a potential responsible for this behavior too.

Actually, I would agree to Yann that this might be a possible reason for your problem.

[Mako_energy02]

I finally got around to finishing all the CFM/ERP tests. Setting the normal CFM/ERP values did nothing to the simulation of the constraint. However setting the Stop_CFM/Stop_ERP did have a large impact on it. When either the CFM was set to 1, or ERP was set to zero individually the behavior was about the same, sometimes they drifted, but overall still seemed to exert some amount of force between the two objects although it wasn't all that explosive. Overall the constraints looked quite unnatural as would be expected.

When I had both CFM set to 1 and ERP set to zero in the same run, there was zero explosions, and the objects just seemed to drift around the screen after the constraint was created.

I've also been thinking more and more about the frames being wrong...and I am thinking less and less that to be the case as I don't really understand how that would cause the objects to exert force on each other if collisions are disabled, furthermore the objects in almost all cases end up where I would expect them to when they collide...so the frames are correct based on observation of the objects(but I haven't directly observed the data yet).

Any other ideas/clarifications/insights?