Getting the rid of Kinematic objects

[MaxDZ8]

I've come to a point I just have to realize I'm out of ideas.
I've built my system trying to make it as orthogonal as possible. Sometimes even more than reasonable. Nonetheless, I still like this approach.

The problem: I need simulated kinematic objects. That is, objects which can be moved yet - specifically - fall down compatibly with dynamics. As Bullet does not deal with kinematic objects, an updated form of the old integrator was used to provide them with basic falling behavior. Unfortunately, {1} it has proven to diverge from Bullet's solver in visible ways. I have considered rolling back to previous integrator but that would need some work.
Even worse: {2} the interactions between the integrator and Bullet causes the latter to work inefficiently.
It seems reasonable at this point I seriously need to get this in The Right Way.

I was thinking about having only dynamic objects. When an object is marked as kinematic (in my system) it would really be created as dynamic (in Bullet). When a movement is applied a (cached) constraint would be connected to the dynamic object. The movement is applied to the constraint. The constraint is disconnected as soon as no movement is provided.
This is basically the suggested way to move objects according to user interaction so nothing new here.

Unfortunately, to keep the simulation coherent I need this relationship to be bidirectional.
That is, when the constraint is connected, I'll need to poll object's position for safe connect. That's not a problem. Yet momentum interactions appear problematic to me. I'd like some elaborations on that.
In general, manipulation using this constraint must be energy conserving. By an extreme example, the manipulated object should be able to wrap around blindly yet keep its falling velocity compatible with an equal object which has not been teleported around.

I also have the problem of allowing some objects to rotate while not allowing others. I think I have no problem in this specific issue but again, I am not sure this is compatible with my "dynamic compatibility" requirement.

I also considered Bullet's dynamic object controller but it was my understanding this is still under development.

Please drop everything you can think about this here, including suggestions on using constraints, limiting rotation, moving kinematic objects, whatever.

[Yann]

The problem: I need simulated kinematic objects. That is, objects which can be moved yet - specifically - fall down compatibly with dynamics. As Bullet does not deal with kinematic objects

Well, it does, actually. You just have to set the kinematic flag on your rigid body, and use the motion state to set positions at each frame.

Code: Select all

_myRigiDbody->setCollisionFlags( _dynamicRigidBodies[i]->getCollisionFlags()
							| btCollisionObject::CF_KINEMATIC_OBJECT )	//add kinematic flag

Unfortunately, to keep the simulation coherent I need this relationship to be bidirectional.
That is, when the constraint is connected, I'll need to poll object's position for safe connect. That's not a problem. Yet momentum interactions appear problematic to me. I'd like some elaborations on that.
In general, manipulation using this constraint must be energy conserving. By an extreme example, the manipulated object should be able to wrap around blindly yet keep its falling velocity compatible with an equal object which has not been teleported around.

I also have the problem of allowing some objects to rotate while not allowing others. I think I have no problem in this specific issue but again, I am not sure this is compatible with my "dynamic compatibility" requirement.

Well, I'm afraid you lost me there What is your requirement explicitly ? Maybe with some sample to help us understand ?

[MaxDZ8]

The problem: I need simulated kinematic objects. That is, objects which can be moved yet - specifically - fall down compatibly with dynamics. As Bullet does not deal with kinematic objects

Well, it does, actually. You just have to set the kinematic flag on your rigid body, and use the motion state to set positions at each frame.

Of course it does. But this implies you have to implement your movement logic completely yourself (which is the point of using "an updated form of the old integrator").
Kinematic objects, by default, won't move as far as I understand. I even checked btKinematicCharacterController and it contains code dealing with exactly that problem... Whatever that code could be used to do what I need is an open question.
When it comes to Bullet, kinematic objects are mangled similarly to static objects.

Well, I'm afraid you lost me there What is your requirement explicitly ? Maybe with some sample to help us understand ?

Here's the simplified sample.
Let's drop two spheres DYN and KIN. Let's apply an orthogonal "movement intent" vector to KIN. As this force is orthogonal, the two spheres are expected to hit the ground at (more or less) the same time.
This is not currently the case for KIN, as it would have to be marked as Kinematic, which would imply dynamics is disabled.
Requirement: compatible behavior across dynamic and kinematic objects.
Requirement: implementation independence.

[Yann]

Kinematic objects, by default, won't move as far as I understand. I even checked btKinematicCharacterController and it contains code dealing with exactly that problem... Whatever that code could be used to do what I need is an open question.
When it comes to Bullet, kinematic objects are mangled similarly to static objects.

Well, I guess we misunderstood. Kinematics objects don't move according to physics law, but when you give them their positions, that's their difference with static objects.

Here's the simplified sample.
Let's drop two spheres DYN and KIN. Let's apply an orthogonal "movement intent" vector to KIN. As this force is orthogonal, the two spheres are expected to hit the ground at (more or less) the same time.
This is not currently the case for KIN, as it would have to be marked as Kinematic, which would imply dynamics is disabled.
Requirement: compatible behavior across dynamic and kinematic objects.
Requirement: implementation independence.

Ok, I'm starting to understand I'm having the same needs for another part of my project. I thought this would be made by using a PID controller, maybe it's already what you've done ? The problem is tuning the parameters well...
The other problem is: what do you do when both controllers wants to apply a movement on the object ? How do you choose what part of each you should use ?
I'm interested in your thoughts and previous experiences on the subject too.

As for your sample, you just have to apply some force on the second sphere (applyCentralForce), and it will react to both the gravity and the extra force you applied, but it won't react the same way for kinematic objects...

[MaxDZ8]

I thought this would be made by using a PID controller, maybe it's already what you've done ?

I don't know. I've fired some google previously but didn't quite understand what this is supposed to do. The wikipedia page seems to be quite informative but I cannot quite understand how to map that to my system.

In my first implementation (before Bullet) there was a plain ballistic integrator. Besides the fact the collisions were a bit fuzzy at best, it worked perfectly. To be completely honest, I sort of miss it.
Then I started experimenting with Bullet. There were various implementations. Program requirements were also changed and I couldn't go forward with the ballistic integrator. I switched to RK4. Unfortunately, it appears this integrator does not quite match with Bullet's. It's also much more CPU intensive than originally predicted.
At this point, it seems reasonable the physics subsystem needs some serious redesign and since it has gone through a few up to know, I guess it's probably better to try reusing what I've got in the library.

The other problem is: what do you do when both controllers wants to apply a movement on the object ?
How do you choose what part of each you should use ?

I was planning to apply those in sequence currently, movement intent vectors are always applied after physics integration. As long as the framerate is high enough, I don't see any problem there.

As for your sample, you just have to apply some force on the second sphere (applyCentralForce), and it will react to both the gravity and the extra force you applied, but it won't react the same way for kinematic objects...

This takes us again to the first post. The only reasonable way to do that is to use some sort of constraint but this would take some care. As a side note, my current system mandates mass != 0 for dynamic objects only. Therefore, force calculations are not guaranteed to be possible.

[Yann]

I was planning to apply those in sequence currently, movement intent vectors are always applied after physics integration. As long as the framerate is high enough, I don't see any problem there.

Sure enough, but if you want bullet to take the new position into account for its next update, you have to somehow inject this new position into bullet, that was my point.
That also the purpose of the PID controller I was mentioning.

As a side note, my current system mandates mass != 0 for dynamic objects only. Therefore, force calculations are not guaranteed to be possible.

Well, this damn complicate the system :p

Then I think I misunderstand your sample : if your objects have no mass, what is the purpose of trying to simulate them in Bullet ? If they have no mass, they won't be affected by gravity anyway. If you just want them to be collided by other object, then the kinematic mode is what you need, isn't it ?

[MaxDZ8]

Sure enough, but if you want bullet to take the new position into account for its next update, you have to somehow inject this new position into bullet, that was my point.
That also the purpose of the PID controller I was mentioning.

1. I'm afraid I don't understand the whole point. I'll just fetch it to the corresponding MotionState. If force is used, I'll have and handle to the object.
2. I'll write it again. If I google for "PID controller" or "PID controller for physics simulation" all I get is math and stuff related to electronics. Mapping those concepts to what I need appears nontrivial. Elaborations are welcome.

Then I think I misunderstand your sample : if your objects have no mass, what is the purpose of trying to simulate them in Bullet ? If they have no mass, they won't be affected by gravity anyway. If you just want them to be collided by other object, then the kinematic mode is what you need, isn't it ?

Not exactly because 0 mass is effectively infinite mass as far as I've understood.
Nonetheless, Thinking at this better, I think it is reasonable to mandate positive nonzero mass for everything that needs simulation.
Therefore, the movement vector can be transformed into an appropriate force vector.
I am still not sure this matches intended behavior. The current movement vector is supposed to be independent from acceleration. It appears I would need to zero out the acceleration next tick by providing an opposite value through applyCentralForce. Because of architecture, this is indeed very viable. At this point, I guess I should just try hacking something with collision masks and such.

Thank you very much.

[Yann]

[*]I'm afraid I don't understand the whole point. I'll just fetch it to the corresponding MotionState. If force is used, I'll have and handle to the object.

You're right, I was not very clear
Well in my mind, it's two different things:

1. either you use kinematic mode and set the position in the MotionState, but in this case the object is not simulated by bullet physics (which is not what you want, as far as I understood)
2. or you use your object as a dynamic object, but you have to re-inject extra-forces in the bullet engine whenever you want to control the position/orientation more precisely, which is what is doing the PID controller

[*]I'll write it again. If I google for "PID controller" or "PID controller for physics simulation" all I get is math and stuff related to electronics. Mapping those concepts to what I need appears nontrivial. Elaborations are welcome.

Well, the wikipedia indeed speak about signals, and this method indeed is most used in electronics.
The equivalent physic for a Proportional Derivative controller is the mass spring damper controller. The proportional gain is equivalent to the spring gain (it send back the body to the desired position), the derivative gain will try to give the rigid body the same speed as the desired one (which means that when the speed is null, it will act in the same way than a damper).
The computation for the force you should apply to obtain the desired position and speed gives something that looks like this:

Code: Select all

F = mass/dt² * (desiredPosition-realPosition) + mass/dt * (desiredSpeed-realPosition)

But physics never really goes the way you want as there are other force that may be applied to our system, so usually you simplify it to

Code: Select all

F = K * (desiredPosition-realPosition) + B * (desiredSpeed-realPosition)

and you have to fine tune your K and B parameters, but you will usually have B almost equal to K*dt...
Using higher value for K will tend to make the desired position reached faster, but with more oscillations.
Higher values of B should 'damp' this, but will also increase the time before the desired position is reached.
The wikipedia article shows good graphics of what you may obtain with different values of K and B : http://en.wikipedia.org/wiki/Damping

Not exactly because 0 mass is effectively infinite mass as far as I've understood.
Nonetheless, Thinking at this better, I think it is reasonable to mandate positive nonzero mass for everything that needs simulation.
Therefore, the movement vector can be transformed into an appropriate force vector.

Looks more and more like the PID controller I was speaking about, isn't it ?

I am still not sure this matches intended behavior. The current movement vector is supposed to be independent from acceleration. It appears I would need to zero out the acceleration next tick by providing an opposite value through applyCentralForce.

Why would you need to zero out the acceleration next tick ? The applyCentralForce method apply a force only for the tick you call it, nothing else after that. Only the gravity is applied at each tick.

[Yann]

Now that I wrote it, I realize that my PID controller will act the same way as a 6DOF constraint, so I guess it doesn't suits your needs better.

[MaxDZ8]

Hello Yann, I apologize for the late reply. You are being very helpful.
It seems you have understood precisely the point. What I need is to provide part of dynamic-object behaviour to a kinematic object. I must be able to guarantee two dropped objects will (at the very least) hit the floor at the same time. It is highly desirable the velocity will also be roughly the same for each tick. Those two objects are called DYN and KIN. KIN must be player controlled somehow, yet its behavior must be coherent with Bullet.

Ideally, KIN would be a dynamic object (by Bullet's point of view) connected to a constraints as with mouse interaction or "gravity guns" which would instead be kinematic by Bullet's standards. I am talking about a higher-level of "kinematicness". As the interaction would be limited it seems more appropriate to just produce the correct forces and forget about constraints at all.

So yes, the point is to track a proxy dynamic object, KPROXY.
Yes, it could be considered a PID controller and the tracked KPROXY object would be its setpoint. However, there's no room at all to let the two objects deviate. That is, if the proxy object needs to move at speed v_kp, then the kinematic object must move in the same way. There is no time to work over (B, K) as this is an intra-tick operation.

In practice, there won't be a kinematic object: bullet will deal only with KPROXY.
The DYN object is not really part of the problem. It's just our reference point "without player interactions".

Then, to make the KPROXY object work as intended, taking in account for "kinematic forces" as well, it is necessary to inject extra accelerations by using applyCentralForce. This will result in modifying KPROXY speed (my point here was speed, movement vectors are supposed to be 0-speed vectors, they are just like warp but with sweeping). This implies the object will keep moving in the kinematically supplied direction. This is not supposed to happen. Therefore the need to apply opposite acceleration in next tick.

The problem is that both desiredPosition and realPosition are unknown. Similarly, desiredSpeed is fuzzy at best. It would certainly be possible to tick, pull it out of the object and fetch it to the function, it does not seem to make sense to me.

I know, in KPROXY's own object-space (where its position is always at origin) it needs to move according to movement intention vector - if possible - to do that, I have to call applyCentralForce. On top of that, KPROXY's position needs to change according to physics simulation (which yes, might include arbitrary forces). So we can indeed consider this some kind of PID controller, there is however an extra complication.
In KPROXY's object space, desiredPosition would be equal to the intention movement vector while realPositionwould be 0. desiredSpeed is supposed to be irrelevant (and would be a property of the vector space somehow).
Instead, I model it first as moving the object in its own space, and then moving its space according to intended movement.
How does damping fit in the picture?
Is this a real PID?
I cannot tell.
So, no, I cannot see a direct, trivial, clean connection to PID. Honestly, I still have difficulty in considering it a PID without some flexibility of mind. At that point, I might as well call it in another way.

Let's try to visualize what a PID is in the real world. It is the strange valve mixing cold and hot water down in my basement to keep the house warm. Its setpoint is known (computed in a previous stage) and its convergence to target is a function of calibration. The system I need to model is different as the system includes certain amounts of feedback and the set point moves according to its own actions.

The only way to compute the setpoint I need is to let Bullet tick. If I compute a setpoint myself, there's no guarantee the simulation will converge.
So, does it look like a PID? Yes... like all equations more or less look similar or like all languages are similar being touring-complete.
I don't know Yann. I'm not on it.

EDIT: typo

[MaxDZ8]

Ok, so far I searched for theorical solutions. Sometimes one fails at using the obvious keywords for a google search so I just tried "bullet library coherence for kinematic objects" today. 1st hit is this thread. I then found this thread on gamedev.net. It's about PhysX but appears to be applicable with minor adjustments to Bullet as well. Let me quote.

smjones: Should I be thinking about moving my physics shapes around the world by setting torques and forces, rather than manually touching the objects positional matrices at all?

grhodes_at_work: The basic answer is yes, for objects that are physically simulated, you move them with forces and torques, and not assign their transformation matrices directly. After all, the physics system is simulating the motion, and computing the transforms. If you set them, you are throwing away the physics! ... Kinematic objects might be used to simulate infinitely strong machines that move----you set the transforms directly----and when you move them they can push dynamic objects around.

Tom: As a general rule, kinematic actors should be used as static (non-moving) objects, or as moving objects that follow a specific path that is not affected by anything in the way (i.e., "movers").

grhodes_at_work: As you discovered, kinematic objects have absolutely zero built-in response to collision detection. It is a one-way interaction, essentially, with them affecting dynamic objects but them not reacting to anything automatically. And, since they cannot respond automatically, the default behavior of a physics engine is to assume you don't care about collisions between two kinematic objects...the engine filters them out to save CPU or PPU cycles.

Let me recap my situation. I have never been able to figure out kinematic objects. They never completely bought me since day 0. We can see there why. The Bullet documentation does indeed put a lot of emphasis over kinematic objects for player management while "dynamic" object approach seems to be out of vogue: "DynamicCharacterController is obsolete/unsupported at the moment".
It appears to me I was correct in my initial bluntness. Kinematic objects, in this case, must go away.
I think I'm going to elaborate this in the wiki, it was not quite clear to me.
The difference is mainly in design. Kinematic objects are really only good for stuff which will move on predefined paths out of DCC tools. The idea of "hybridizing" them is flat out broken.
By contrast, I can see in my memos quite a few references to "pure kinematic" objects. It seems now this concept does indeed exist and my difficulty was caused by not properly recognizing the needs and correct use-cases of each object classification.

I'm going for the "force cancelling" approach.

With this new content-oriented bigger picture, I can tell I'm not going to need the old integrator anymore - it caused serious discomfort , such as the sub-optimal performance I initially wrote about.
Hopefully that's now going to get fixed.



EDIT: ok, looks like the wiki does not contain much references to kinematic bodies in the first place. I guess I should edit user's manual but I don't know how to do that. I suppose I should sign as a contributor to CVS and edit the original document? Maybe I'll do that after I've proven this stuff to work.

[MaxDZ8]

Replying to my own messages for future reference.
The dynamic-based system has been in use for a while right now. I'm still not 100% sure it's working as intended but it appears to deliver.
Kinematic objects appear to be a bit overrated.

[jduran]

Dear all,

I'm thinking to use the PID to interpolate a rotation only movement. Could PID be used to rotate an object from a quaternion to another one?
Even for irregular objects, it is possible to set the center of the masses to a desired point?

Thanks and Best Regards,
Joaquim Duran