On the fly sticky constraint unstable.

[Yann]

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).

Well, if frames are wrong when you create the constraint, then there is a big error to correct for the constraint at the very first step, so even without colliding, these two objects would have a huge force applied to bring them back to the (only one) correct relative position/orientation.
Changing the erp to a very little value should help minimizing the force used at the very first step, but the counter step is that the constraint will take more time to resolve. But it would finally show you the relative positions/orientation (frames) you actually set (and therefore show you if there is an error on it).

Just to make sure we understand each other: changing the erp value to a very little value is not the solution, it's just a clue to help us understand where the problem stand.

[Dr.Shepherd]

Post your following code here, and let's see the parameters in this function:

Code: Select all

    m_dynamicsWorld->stepSimulation(..., ...,  ....);

[Mako_energy02]

Well, if frames are wrong when you create the constraint, then there is a big error to correct for the constraint at the very first step, so even without colliding, these two objects would have a huge force applied to bring them back to the (only one) correct relative position/orientation.
Changing the erp to a very little value should help minimizing the force used at the very first step, but the counter step is that the constraint will take more time to resolve. But it would finally show you the relative positions/orientation (frames) you actually set (and therefore show you if there is an error on it).

Just to make sure we understand each other: changing the erp value to a very little value is not the solution, it's just a clue to help us understand where the problem stand.

I decided to upload a video to better show what is going on and you can see what I mean by most of the time it seems to put the object where it needs to be.

A couple things to note:
1) On my second run you can see one of the rare cases where it doesn't pick the obvious location for the offset, and snaps to a different tray entirely. I have no idea what that is about but solidifies my opinion that ManifoldPoints have a questionable reliability. Sadly I don't know where else to get my offsets from, or what else to filter to disregard faulty data.
2) On my fourth attempt it bounces off the tray without sticking entirely. I'm not sure what that is about but I haven't yet ruled out it being an issue in my code.
3) This simulation is being run with the green objects able to only stick to one object. They don't stick to anything they come in contact with, just the first thing. Also the ERP/CFM values in this simulation are the defaults, and not the extra values you asked me to test.

Post your following code here, and let's see the parameters in this function:

Code: Select all

Real FloatTime = TimeElapsed * 0.001; //Convert from MilliSeconds to Seconds
Real IdealStep = this->GameWorld->GetTargetFrameTime() * 0.001;
IdealStep /= SubstepModifier;
int MaxSteps = (FloatTime<IdealStep) ? 1 : int(FloatTime/IdealStep)+1;
this->BulletDynamicsWorld->stepSimulation( FloatTime, MaxSteps, IdealStep);

Substep modifier is something to quickly change the resolution of the simulation. And the target frame time is currently set to 16.6 (for 60 FPS). To deal with tunneling I had to set that to 2, so currently the simulation is running at 120hz (two steps per frame at 60 FPS).

[Mako_energy02]

I've tried tinkering with the velocities of the objects when the constraints are created (by zero'ing them out) some and that hasn't changed the behavior at all. I'm still not sure exactly how I would go about fixing the issue with the frames if that is the cause, either.

Yann, you said you had something similar (adding constraints mid-simulation, possibly for sticky objects) in an earlier post. Would you mind sharing some code or concepts so I can compare with what I am doing? Maybe find out what I am missing then.

[Dr.Shepherd]

Sorry for the delay, but it takes me some time to absorb the information.

Still, I don't quite understand what's wrong in your video. Your game is already there, and I don't know what's happening inside the game. Should you point exactly out the point in the video when the problem occurs?

[Mako_energy02]

First, thanks for sticking with this and helping me out.

The issue is that if you look carefully after the collision and the object sticks...the tray will spin excessively, with more energy then the collision really had and it will keep on spinning aggressively often with such force to move the entire ferris wheel with it. Essentially the constraint is trying to explode the objects outward as if they are colliding, but they are locked to each other so this is the result.

Normally this is a no brainer, I set true when passing the constraint into the world to disable collisions between bodies. The issue is that I'm already doing that, and have been the entire time...but collisions seem to still be occuring despite that.

[Yann]

Yann, you said you had something similar (adding constraints mid-simulation, possibly for sticky objects) in an earlier post. Would you mind sharing some code or concepts so I can compare with what I am doing? Maybe find out what I am missing then.

Well, there is really nothing particular in it:

Code: Select all

btTransform bodyTransform, parentBodyTransform;
bodyTransform.setRotation(convert(parentBoneCenterOrientation * returnedBoneCenterOrientation.inverse(), true));
bodyTransform.setOrigin(convert(constraintPositionInBoneCoordinateSystem, true));

parentBodyTransform.setRotation(convert(Quaternionf(0,0,0,1), true));
parentBodyTransform.setOrigin(convert(parentBoneCenterOrientation.inverse()*(constraintPosition-parentBoneCenterPosition), true));

btGeneric6DofConstraint* coneC = new btGeneric6DofConstraint(*_dynamicRigidBodies[boneIndex], *_dynamicRigidBodies[parentBoneIndex], bodyTransform, parentBodyTransform, false);
_joints[constraintIndex] = coneC;

_thePhysicContext->getPhysicWorld()->addConstraint(_joints[constraintIndex], true);	//true: disable collisions between linked rigid bodies

But in my case, the rigid bodies are always created just before the constraint is created, even when this happens during the simulation.

[Dr.Shepherd]

First, thanks for sticking with this and helping me out.

The issue is that if you look carefully after the collision and the object sticks...the tray will spin excessively, with more energy then the collision really had and it will keep on spinning aggressively often with such force to move the entire ferris wheel with it. Essentially the constraint is trying to explode the objects outward as if they are colliding, but they are locked to each other so this is the result.

Normally this is a no brainer, I set true when passing the constraint into the world to disable collisions between bodies. The issue is that I'm already doing that, and have been the entire time...but collisions seem to still be occuring despite that.

Ok, it makes much sense now.

First, Just to double check, you are not rotating the wheels using the keyboard input, aren't you? The excessive rotation is totally due to the dynamics world itself ?

Second, since you got loads of objects here, even though you disable the collisions between the constrained bodies, it is possible that your constrained objects will likely overlap with other objects, therefore the abnormal collision happens ?

[Mako_energy02]

First, Just to double check, you are not rotating the wheels using the keyboard input, aren't you? The excessive rotation is totally due to the dynamics world itself ?

This is correct. The only input of any kind going into the simulation is with the mouse throwing the objects. Even then, the mouse is only able to manipulate objects inside the green area. The rotation is purely from bullet.

Second, since you got loads of objects here, even though you disable the collisions between the constrained bodies, it is possible that your constrained objects will likely overlap with other objects, therefore the abnormal collision happens ?

The objects have been placed very carefully to avoid exactly that. The objects are also locked on the Z axis so they are always in the middle between the two outer bars of the ferris wheel. The only other object that overlaps is with the blue area, which is a ghost object. But it has it's collision response disabled and isn't causing any issues elsewhere in that level, or any other level I have.

The only thing however remote that I can think of that makes the "on-the-fly" constraints different from the premade constraints in that level (the constraints between the wheel and the trays, which are hinges) is that I order the construction of the ghost object such that it's after the constraints are made and added to the world. So unless there is a bug where two constrained dynamic objects will collide despite disabling collisions if they are overlapping a ghost object when made...it's not connected. But that seems like an interesting test to conduct. I'll add an edit to this post in ~10 minutes with my results.

Edit: As promised, my results were negative. Even when I remove the ghost object the behavior is unchanged.

[Dr.Shepherd]

OK, after reviewing the video, I found something, and let's see if you agree to them.

1. When the system is not behaving wildly, the objects rotate seemingly normal. So I suppose it would not be problem for simulation steps.

2. Only the trays with the "Green stones" rotate incorrectly, the other trays rotate more or less correctly. So the problem lies in the "green stones" with other objects

3. At about 1:20, you restart a new round. This time, two objects are hanging outside the trays and the system quickly returns to normal. I wonder if it is common or not ?

Cheers !

It is not easy to identify problems from such a big system. I would suggest if you can remove other trays, and only keep one tray instead, then put one stone onto it, see how the wheel behaves.

[Mako_energy02]

1. When the system is not behaving wildly, the objects rotate seemingly normal. So I suppose it would not be problem for simulation steps.

As far as I can tell, this is correct. I have 5 other levels also in the game, and they do not demonstrate any issues regarding the simulation steps.

2. Only the trays with the "Green stones" rotate incorrectly, the other trays rotate more or less correctly. So the problem lies in the "green stones" with other objects

Yes, they are the "sticky" objects of the level. The other objects in the green area have gravity disabled for themselves but aren't constrained to anything. The Generic6DofConstraint being used to make the "sticky" behavior is only between the green stones and the trays they collide with, which is also as you observed the only place of the erratic behavior.

3. At about 1:20, you restart a new round. This time, two objects are hanging outside the trays and the system quickly returns to normal. I wonder if it is common or not ?

Very, very rare. Less then 1 in 20 attempts.
Edit: Based on your observation here I wondered if maybe it was making more then one constraint when there was more then one contact point in the collision. I do have code to prevent that but I hadn't scrutinized it as much as other portions of the code. I have now done that ruled that out as a possibility, and my log confirms it's only making one per green stone.

It is not easy to identify problems from such a big system. I would suggest if you can remove other trays, and only keep one tray instead, then put one stone onto it, see how the wheel behaves.

I'll add an edit after I have run this test and post the results.
Edit: I attempted this and it still behaves the same, it doesn't seem to be related to the other constraints in the world.

[Dr.Shepherd]

gosh, you went through a lot of tests...This is really not easy, =)

This afternoon, I just solved a bug in my program, and before that, loads of tests are carried out as well. and that turned out to be a verrrrrrry silly reason.

So dude, keep up !

[Mako_energy02]

I noticed that you posted before I could get my edit in, so I'm making this info a post as well as an edit in my previous post to ensure you didn't miss it.

Based on your observation with the simulation working when objects stuck to the outside of the tray's...I wondered if maybe it was making more then one constraint when there was more then one contact point in the collision. I do have code to prevent that but I hadn't scrutinized it as much as other portions of the code. I have now done that ruled that out as a possibility, and my log confirms it's only making one per green stone.

As for your suggested test of removing all but one tray, I did that and the result was the same, it's still quite erratic and unstable.

[Dr.Shepherd]

As for your suggested test of removing all but one tray, I did that and the result was the same, it's still quite erratic and unstable.

Is your tray composed of several objects ?

[Mako_energy02]

The tray is a single rigid body, but it does have a compound shape composed of a few boxes.