bind ghostObject to rigid body

Post Reply
aash29
Posts: 8
Joined: Wed May 09, 2007 9:06 am

bind ghostObject to rigid body

Post by aash29 »

greetings!
is there a way to attach a ghost object to a rigid body? I'd like my game object to have a trigger zone around it. Should I simply change ghostobject's transform every tick?
Antonz
Posts: 16
Joined: Wed Nov 17, 2010 10:57 am

Re: bind ghostObject to rigid body

Post by Antonz »

aash29 wrote:greetings!
is there a way to attach a ghost object to a rigid body? I'd like my game object to have a trigger zone around it. Should I simply change ghostobject's transform every tick?
I have decided to abandon Ghost objects usage in our game, because I think that their design is all wrong - it's separate class on the same level as static and dynamic objects, with very limited functionality and made in a way where you must "poll" for collided objects instead of having callbacks called. I think Bullet engine should be extended to have a trigger response via callbacks on any objects, and handle also touches with unpenetrable objects, not only overlaps with "ghost" trigger zones.

Until this I decided to hook on gContactProcessedCallback and gContactDestroyedCallback, handle manifolds and contact points creation and deletion, use user pointer on collision objects (btCollisionObject::getUserPointer()/setUserPointer() ) to keep additional per object data and dispatch callbacks through it, when needed. I'm also using btManifoldPoint::m_userPersistentData to compactly pack a pair of 16 bit indices: 1. index to struct ContactPair within single vector that stores all of them, and 2). index of ContactPoint within this ContactPair (just a fixed array in struct). ContactPair's store state information for each trigger manifold (info about two colliding bodies). I need this userPersistentData because this is the same user data that gets passed to gContactDestroyedCallback. Because gContactProcessedCallback and gContactDestroyedCallback are called for every pair of contacting objects, even uninteresting ones (like most of static objects) I do this custom processing only for objects that wants trigger callbacks. Other manifold points have their m_userPersistentData set to default NULL and filtered early.
Post Reply