Bullet physics, getting body from a ray hit

I’m working on some bullet physics stuff that was originally written under 1.8.0 or earlier. I have some weapon code that calls BulletWorld.rayTestClosest then BulletRayTestClosestResults.getNode to get the body, and if it’s a dynamic body then give it a little kick. I have started using a dev build and now this code is broken because the getNode method returns a const reference. What would be the preferable way (in python) to retrieve a modifiable BulletRigidBodyNode from a ray hit?

This is by intention.

Look at the definition original Bullet data structure:
bulletphysics.org/Bullet/BulletF … esult.html

You see that the collision object reported by a raycast hit is defined as a “const pointer”, i. e. a pointer to data which is not to be modified. Consequently the C++ pointer we expose (a PandaNode pointer) is const too.

On the C++ level you can simply cast away the const-ness of the pointer. But because you can does not mean you should. Developers usually have something in mind when using a const pointer. And it often is wise to trust the developers on such matters. So you should cast away const-ness only if you know what you do. Or if you don’t mind sudden random crashes…

On the Python level you can not cast (afaik). But when creating the nodes you can store a non-const reference in a python tag (node.setPythonTag(‘cheating’, node)). Then retrieve this python tag from the const-pointer returned by the raycast result.

Just to be clear: this is just how you CAN get around the const problem. I don’t know why the Bullet developers made it a const-pointer, and what evil things can happen if you get around the const.

Thanks! I found that BulletWorld.rayTestAll doesn’t have this issue. I can iterate over world.rayTestAll(startpos, endpos).getHits() and getNode() on the one nearest to startpos and it is not const. I’m not clear if that’s simply an oversight and I shouldn’t rely on it, or if there is a real difference under the hood.

Searching Bullet code on the web I am finding some people cast it, but it looks like most tend to use setUserPointer/getUserPointer which is a void* used to associate with a higher level game object where you can implement some kind of response. This is conceptually identical to the setPythonTag solution but I’m thinking I should probably store something higher level there that abstracts the underlying physics code. Thanks again for your help.

Hmmm, missed this one. The collision objects are const too in this case. Don’t rely on this - it might change soon.