So I'm frustrated.

I've been having quite a few difficulties getting btPoint2PointConstraint() to behave. I'm fairly certain that I'm implementing it correctly, as I've compared it to example code provided with the library, but the point of contact is completely wrong, and I don't know why. I might be looking at the collision manifold incorrectly, in which case I'll have to research that more deeply.

The problem I've discussed in the past regarding joined objects jittering like windup toys has not been resolved. Fortunately, though, I've had an idea on how to fix it. But first, let me explain why I think it's happening.

When I'm adding an object to a scene, I move it around the world with mouse gestures. When the object comes into contact with another object, it actually penetrates the object to a small degree (a value that is set at Bullet initialization). When a collision such as this is detected, what I had presumed happened was that Bullet simply adjusted their positions so that they no longer intersected - this was false. Bullet will attempt to move the two objects apart by imparting momentum to each object in opposite directions.

Here's where I come in. When a collision is detected between the object being added and another object, I introduce a point-to-point constraint between the two, which means that there is a defined point on one object that must at all times share the same point in worldspace as a defined point on the other object. So if that is imposed on the two objects and Bullet tries to impart momentum to each in order to separate them, the two objects vibrate madly back and forth while trying to fight against both impositions (point-to-point constraint and penetration removal).

So I thought I had a solution to this, and that was to allow the simulation step to finish before adding the constraint. That is, allow Bullet to finish moving the objects apart, and only then impose the point-to-point constraint so that there are no opposing forces causing the objects to wiggle wiggle. This approach did not work, because of my aforementioned false presumption (paragraph #3 above). After the step simulation is complete, the objects are not necessarily parted. Instead, they will merely be in the process of moving apart so that they are not fully separate when the joint is imposed thus effectuating the same problem.

Having realized this, I've come up with two possible solutions.

The first is to adjust the scale of the added object's collision shape larger during general editing and then revert it once the constraint is added, but this is not fully effective. It is contingent upon the object's penetration depth and relative size, which are always changing. It also has great potential to produce a gap between the objects about the point of constraint.

The second is to allow the simulation to completely remove the two objects from each other before imposing the constraint. This will involve invoking a tad more collision tracking capability as well as a couple static variables. I can live with that. I think this will be the best route.

Unfortunately, there is still the issue of the point of impact described by the collision, used to determine the point-to-point constraint. This will still require more research.

And if any of this grows too tiresome or frustrating, I can always begin work on another to-do list item.