Hi all,
A quick question- when objects are detected via a near sensor, is the near sensor just detecting the target objects centre /origin, and not the surrounding polygons?
Cheers
Paul
It detects the faces of the collision bounds.
This is what it makes so heavy
all faces (that is totally useless since not return even the normal of the face)
i guess it use the same code of box collision. the difference is that a box bounce and go far to the collision(in fact i’m impressed from the fast of bullet), while the near sensor is as a cube ghost and go inside all faces
strange but true , one obj ghost can due the same problem of extra-calculation and is usually more slow than a normal cube not ghost.
we say,to make near senso super fast(as can be) ,lack one line that say to return when there the first collision
While it would be nice if it returned the ‘hit normal’ of the face, I don’t think it’s useless. If I’m correct, with the near sensor, you could have oddly shaped objects, like a long spaceship, and tell when it enters a certain field, right when a face intersects with it precisely. With just Python and comparing the object centers, or the near sensor and box bounds, it would be evenly distributed (i.e. the ship would have to get very far into the field before it triggers, or could not be in the field at all visually and have the field trigger).
of course, but I mean that, the first face that comes into collision should stop the loop.
it is useless to check if there are any other collisions with the same obj, as after the first collision the object is already in the list of near sensor
control all other collisions is useful to give a more just bounce for obj dynamic(that anyway never get a lot of collision)
but this is not the task of near sensor.
Certainly, getDistanceTo () is another matter entirely
you can see very well the wron behaviour in this blend ,press down arrow until the ground in fully inside the box .
and see the physics ms
is absolutely without sense , also i can make a script much more fast :yes: because the first face to check is positive.
so, no need to check any other 
Attachments
nearSensorUnoptimized.blend (239 KB)
I see what you mean, but that’s naturally going to be slow, just like if you were to turn that high-poly landscape into a rigid body physics object with triangle-mesh collision bounds (the default). As high-poly as it is, it is going to take a toll on Bullet, no matter what. If you replace the physics calculations with a lower-poly ‘hull’, as usually is done, then the Near sensor wouldn’t run slowly.
Also, you can’t ‘only check the first face, because the first face to check is positive’, because it has to loop through possibly all of the faces until it gets to the one that triggers the sensor. The first face that is positive may be the 1000th one it checks, or the 2nd, or the 49th. There’s no way for the game engine to know which face is the one that intersects with the near sensor (though it could probably prioritize closer faces to the near sensor rather than further ones).
I do not know the details of the nearSensor Evaluation.
Marco you are right, the algorithm can return “True” with the first face inside the sensors range. But I can’t tell if that is the case or not.
Worst case is a nearly collision. This means the shape is near the sensors range but does not hit it. It means bounding box tests fail (because it is to close) but it has to check all faces of the bounding type.
Btw. this will always be done if an object is dynamic as this is required for collision detection and to create the resulting physical reactions.
I think instead that Bullet make a list of “potential face collision” , not all faces.(as instead should be my code 
)