I have a dilemma where I've set up a bunch of "checkpoints" in my racing game using neAnimatedBody, and set up the material such that the rigid body will not collide, but will instead trigger a callback.
The problem now is that the neSensors attached to my car's rigid body bounce off the checkpoint. Is there a way I can tell the neSensor to "ignore" collision with this particular animated body? Do I need to set up a special entry in the material collision table?
Thanks in advance
A couple of gotchas I've noticed with sensors...
If you have 2 pieces of static triangle geometry layered on top of each other, you will receive collisions for one or the other in the order in which they are encountered in the triangle data.
The sensors only grab the first collision and then return.
I encountered this when I had a water layer with a sand layer a couple inches underneath, my car suspension sensors would semi arbitrarily pick one or the other, and my car would pop up and down depending on which collision was returned.
Pretty sure this applies to animated bodies as well, in that they dont report the nearest body collided, only the first body with any collision.
This sets some limits on how you can use and abuse sensors, and makes sense for a performance standpoint, since the engine can stop doing collision detection immediately rather than processing ALL possible collisions on every frame, however intuitively it does not "feel" correct since the "correct" solution would be to always process ALL collisions, and then only return the nearest one.
In the case you describe, I would implement the checkpoint collision manually, by taking the distance between the position of your vehicle, and the center of a "checkpoint sphere" and do your entered/exit logic based on that.
As long as the spheres are big enough, you can probably get away with doing these checks in a lazy fashion in your main loop.
This will have the benefit of not cluttering up the scene that tokamak has to process since the ray/animated body collision stuff is waaaay more expensive than simple sphere/sphere check. You can then use the freed up processing to do more interesting physical effects later :).
Let me know if you need more detail on how to implement this, or have any other questions!
Yeah, I also hit the animated bodies limit so I ended up implementing this stuff by hand. Does Tokamak expose a collision library which can be used for faster collision (i.e. that uses spatial data structures or something like that?) Right now I'm just doing naive AABB checks, which are not terribly expensive.
Thanks for your help!
Yeah afaik there is no way to hook into the collision detection.
I've agonized over this before, but eventually decided that really these deserve to be 2 different problem domains.
What I've done in some of my apps that need raycasting for camera placement and the like, is have a 2d array of 2 lists. one of triangle nodes (static geometry), and one of dynamic objects.
I then subdivide my ray along the grid boundaries and test each ray segment against its corresponding grid cel of data.. this way, you can traverse your ray in the direction that you want, thereby achieving early exit without searching the entire length of the ray, for instance in the camera example, you would walk your ray segments from the camera target, back to the camera, and exit when the first occluding collision is found. If you keep the grid cel sizes to roughly encompass the size of the main objects in your app, then it does a decent job of broad phase culling. Another trick to that implementation is to redundantly add your triangles to any grid cel that they occupy, then keep a visited bit somewhere on the triangle/object data structure or in the user field of the triangle/object data... then for every triangle/object you want to raytest/collision detect, you first check wethere its already been visited and skip it if so. If not, you check it, set the visited bit, and add it to another list. When you have finished finding your collisions, you clear all the visited bits for the triangles/objects you've accumulated, and flush the list. This scheme keeps the complexity of the casting/collision problems from exploding with scene size. There are "better" schemes using quadtrees or occtrees, and depending on how much it matters for your app, those bear investigating.
This data structure also roughly maps to the custom collision detection callbacks used by tokamak, so once you have the scheme implemented, you can experiment with letting tokamak use your scheme for broad phase collision detection, and possibly improve its performance as well.
Hope this helps!
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.