On the meaning of CollisionFlags

[MaxDZ8]

I thought I had a grip of game dynamics, but looks like I have not. Can someone review my understanding of what CollisionFlags are supposed to do?

CF_STATIC_OBJECT: object has 0 mass (or infinite mass in a certain sense). It can take arbitrary abuse and stand still. Management is easier as it is guaranteed to not move. This is set automatically by btRigidBody::setMassProps, so (Q1) being this a function of mass, what's the point in using it?
Considering soft bodies don't appear to have a mass (or perhaps I just overlooked at them) (Q2a) is this geared towards saving a few bits? Or perhaps (Q2b) avoiding a virtual call (see below)?
(Q3) How does a static soft body work like?

btCollisionObject::activate will be nop for static or kinematic objects. All CollisionObjects are born static. (Q4) Am I correct in saying I can change this with no trouble?
Because those objects do not move nor need to be tracked, I'd personally not use a MotionState when creating them. I understand the manual suggests to use them "because they're easier" but I don't understand what's the benefit for static objects. (Q5a) Is this considered bad habit? (Q5b) What's the problem with interpolation for static objects? (Q5c) Isn't providing unnecessary MotionStates for static objects just cruft? I thought it was just for easiness of explanation in the demos.

CF_KINEMATIC_OBJECT: this has 0 mass as well but it might move because of user control. The user moves it by providing a MotionState and messing with it. In line of concept I'm tempted to say that if mass is 0 and there's a MotionState then the objects is kinematic. But btCollisionObject cannot figure out this as only btRigidBody seems to keep track of the MotionState. Kinematic objects will push dynamic objects around to avoid visible intersection. Static and kinematic objects have no collision response but have detection only (btCollisionDispatcher::needsResponse).
So I'd say I see the point of having this flag.
But I still wonder why to not just give btCollisionObject a way to understand if a MotionState is there and simply work by inference. Like:

Code: Select all

if(mass) { /* dynamic */ }
else if(motionState) { /* kinematic */ }
else { /* static */ }

I understand that being btCollisionObject base class, figuring out this information would involve virtual function calls. (Q2ab-revival) Perhaps all this is just for optimization?

CF_NO_CONTACT_RESPONSE: pretty self-explanatory. I guess that's useful to make an object temporarily non-solid. Ok.

CF_CUSTOM_MATERIAL_CALLBACK: used in many demos in a way I don't quite understand. This seems to be "experimental", per-triangle friction/restitution. I think I don't need it for the time being.

CF_CHARACTER_OBJECT: this matches only twice in the demos. I wonder what's good for. I mean, if it's not used, (Q6) why is it there in the first place? Perhaps it is legacy?

CF_DISABLE_VISUALIZE_OBJECT and CF_DISABLE_SPU_COLLISION_PROCESSING are just ok.

I ask clarifications as I am trying to figure out when to modify what flags, and why (designing the interfaces to interact with the physics system).
Thank you.

[Mako_energy02]

1) Which function are you referring to? SetMassProps()? Or SetCollisionFlags(btCollisionObject::CF_STATIC_OBJECT)? In the case of the former, that should be obvious. I don't recall seeing it automatically setting the mass when I snooped through the source, but I wasn't paying too close attention to that function. It probably sets it just as a convenience so you don't have to call SetCollisionFlags() afterwards tediously. In the case of the latter, it's when you want to change how it behaves without changing other details such as the mass. Unless I misunderstood your question entirely.

2) Soft bodies do have a mass, actually. See this struct. The value "m_im" pretty much means "Member_Inverse Mass". I can't blame you for missing it, soft bodies are easily the least intuitive and worst documented thing in bullet in my opinion.

3) I've never made a static soft body, so I'm not sure. But if I had to guess based on what I know of bullet I'd assume the nodes simply wouldn't move. It would be stuck in it's initial shape, or whatever shape it had when it was made a static object. And would behave like a very expensive solid/rigid body.

4) Sadly this is one question I can't effectively answer. I haven't had to tinker with activation at all yet.

5) The suggestion in the manual is geared towards generic rigid bodies, and it's just a guideline. In the specific case of static objects, there is no reason to use them. Only dynamic objects get any benefit of using motionstates...and even then it's not required.

About Kinematic objects, your understanding here is wrong, or at least different from my understanding. Motionstates are not what control kinematic bodies. Character controllers are what usually do the controlling. The common case for a kinematic object is with characters. You could use motionstates here in some cases to synchronize your graphics object, but from my understanding you need a more complicated and custom solution based on how you make and configure your character. There is no one good way to accomplish this, it's entirely based on the application.

Just a note about disabling contact response, it's not limited to being temporary. In fact the most common case for using this flag is with ghost object when creating triggers.

6) I'm not entirely sure about this one. It seems to overlap with the Kinematic flag. Maybe someone else can shed some light here.

[majestik666]

CF_CUSTOM_MATERIAL_CALLBACK is designed so that you can change the collision response
per face on an object. you will get a callback from bullet when a contact happens with this
object.
You can also use the contact information to derive other stuff, like glue/facturing/particle emission etc
Check the glue/fracture demo for an example of that

[MaxDZ8]

1) Which function are you referring to? SetMassProps()? Or SetCollisionFlags(btCollisionObject::CF_STATIC_OBJECT)? In the case of the former, that should be obvious. I don't recall seeing it automatically setting the mass when I snooped through the source, but I wasn't paying too close attention to that function. It probably sets it just as a convenience so you don't have to call SetCollisionFlags() afterwards tediously. In the case of the latter, it's when you want to change how it behaves without changing other details such as the mass. Unless I misunderstood your question entirely.

I had something different in mind but I have thought at this a bit and I now see it definitely makes sense to have explicit setting rather than inference. But since I'm not sure how much I'll use this feature, I suppose I will just do if(mass != .0) { /* dynamic */ }. I had the impression it was some kind of requirement. Just convenience. Ok.

2) Soft bodies do have a mass, actually. See this struct. The value "m_im" pretty much means "Member_Inverse Mass". I can't blame you for missing it, soft bodies are easily the least intuitive and worst documented thing in bullet in my opinion.

Thank you very much. I suppose I will just sign for commit and add a few doxygen //!< tags because the documentation is already in the file.

About Kinematic objects, your understanding here is wrong, or at least different from my understanding. Motionstates are not what control kinematic bodies. Character controllers are what usually do the controlling. The common case for a kinematic object is with characters. You could use motionstates here in some cases to synchronize your graphics object, but from my understanding you need a more complicated and custom solution based on how you make and configure your character. There is no one good way to accomplish this, it's entirely based on the application.

Yes, I understand but... shouldn't I fetch the world transform resulting from the controller logic using a MotionState?
I checked CharacterDemo and it seems to use no motion states. It also works pretty differently from what I expected. But it makes sense. After all, if I have to move this object using its own ad-hoc logic, I'll probably have to do it manually in discrete steps so the benefits of MotionStates are not there but the manual uses MotionState for kinematic objects (page 26). I am confused.

Thank you majestic, will look at it ... hopefully in the near future.

[Mako_energy02]

Yes, I understand but... shouldn't I fetch the world transform resulting from the controller logic using a MotionState?
I checked CharacterDemo and it seems to use no motion states. It also works pretty differently from what I expected. But it makes sense. After all, if I have to move this object using its own ad-hoc logic, I'll probably have to do it manually in discrete steps so the benefits of MotionStates are not there but the manual uses MotionState for kinematic objects (page 26). I am confused.

This depends on how you set up your character. Common case is for you to use a capsule shape on a kinematic body and have it's transform be copied to the graphics mesh. In that case, then yes...it's an ideal character setup for a motionstate. As for the demo...my understanding of those is that there is no graphics mesh, but instead they are making direct calls to OpenGL based on the physics data. So there is nothing to synchronize with. So the demo's are just an odd and unique case where it's not necessary.

There are more ways to setup characters then the tried and true capsule shape. Primarily if you are setting up a ragdoll/powered ragdoll. I'm not entirely sure how to go about that, but it's fairly complex and I'm guessing outside the scope of a motionstate. You may also want to setup your character so the synchronization isn't during the simulation step...but rather later in the loop...so you wouldn't want it in a motionstate. It's just a very open ended thing, with no one single good solution.

[MaxDZ8]

Ok, thanks. I suppose I will just try out something.