How expensive is the near sensor?

So I seem to see a lot of statements stating that the ‘near’ sensor is expensive…I’m assuming it is only due to vertex count of the GameObject it is ‘looking’ for…is this correct?

so by searching for an ‘empty’ it should not be more expensive than using mathutils and checking the .length from a vector subtraction…

e.g.

(player.worldPosition - own.worldPosition).length

vs. a near sensor searching for an Empty object

to summarize…which is cheaper, based on experience? I hope this makes sense :).

I have run the near sensor on a few hundred crowd characters, all at the same time, and I noticed a fps drop of maybe 10 at most. I would say it is expensive. I think also it is more expensive the larger radii of the near.

own.getDistanceTo(obj) is better to an extent because python is slow compared to the logic bricks. Also, why would you do (player.worldPosition - own.worldPosition).length when you can just get distance?

I would use near if there are a lot of objects, and small radii of near sensor.

ok

are the items your searching for static or dynamic?

https://docs.blender.org/api/2.70/mathutils.kdtree.html#mathutils.kdtree.KDTree.find_range
method

  1. static items
    build kdtree using object world positions
    return is exceedingly fast and in order of distance

  2. dynamic objects
    build a grid at a regular interval and build a kdtree of this

w = object.worldPosition
objects then use ((roundIncriment(w.x,gridScale),(roundIncriment(w.y,gridScale),(roundIncriment(w.z,gridScale)) as a grid key
and add themselves to a ‘occupiedTable’ dictionary

own[‘occupiedTable’].update({ (key):
[listOfEntitiesOnGridKey]})

each frame they remove their own entry, and then move, and add themselves again.
(or a manager can do it for N options)

the kdtree returns keys and you do





for returned in kd.find_range(Agent.worldPosition,radius):
    key = keyDict[returned[1]] #to get the grid positions in a radius
    if key in occupiedTable:
       data = occupiedTable[key] #here be your entityList

now we can access spatial data blazingly fast :3

edit:With the KDtree grid thing the grid can be used for pathfinding and sensing gameitems and all sorts of things.

well I generally use it to look for the player…that is when I started…I was using it in lieu of an always sensor because I did not want my logic to always be running scripts or whatnot when the player is far away…

The player is an empty object using the character controller physics model…I have not had issues, I am just trying to keep things in mind while I am working on everything…

I found your post Monster and I will look at the blend, bunch of interesting info there, thanks.

The near sensor is bad because … it looks through every vertex of the object. As such, if you have a multi-thousand-poly object with triangle-mesh physics, the near sensor can be very expensive. If you only have simple physics primitives, then the near sensor can be very cheap.

There are enough alternatives to the near sensor, that I never find myself using it. As stated above, obj.getDistanceTo() works just as well. If I need to detect objects that aren’t specific, such as various enemy types around the player, I just use a ghost plane with a collision sensor attached to it. This also gives me the benefit of defining a custom shape of detection if I want to, such as a cone of vision around a guard.

The thing with sensors is, that they are always running. It does not matter if they result in sensing anything. They just do the measure every frame (regardless what config they have). Therefore a lot of heavy sensors are … more heavy ;). Luckily sensors are native code and pretty fast, but it adds up.

Typically you want this constant sensing as you need to sense any change to the situation. Sometimes it is not necessary. As JustinBarret wrote he need the measure just once at a defined point in time:

Keeping the sensor still alive is a waste of processing time.

What can you do?

  • You deactivate the sensor (via State Actuator by setting a state without that sensor)
  • You remove the sensor by removing the object it belongs to
  • You look for an alternative solution (such as ray measure [which is different] via Python), or you use a sensor object + collision, or you temporarily add an object with a near sensor.

I’m sure there are other options too.#

The important thing is, before you can deal with such situations, you need to know they exist. Now you know ;).

yes, I have played with this idea…it’s fine in a planar environment…but if you have multiple levels and uneven (sometimes drastically) terrain…it starts leading to secondary and tritiary checks.

well as I stated above, I use an empty as the player controller, and I have not noticed any significant performance issues with it…
for one, it has no verts…or is considered a single vert…
I also do not use any states…period :blush: this, along many other things I would like to change, but at this point I am so far along I am just going to move on…python has enough functionality that I really do not need the extra bricks…I just need to handle events and functions properly(which I also do not do :frowning:…lol, moving on…

Near sensor is useful if you put only actors on a certain physics layer
(so you filter for collision between player and health on a player but not level / door etc)

it would be handier if we could have the actor on one layer, and set the naar to another layer even*

I do make use of my masks…that’s a must :ok_hand: