For detecting nearby objects: Geoms or LineSegments? Or something else?

Topics: Developer Forum, User Forum
Aug 14, 2009 at 9:24 PM

I'm not sure in terms of performance, what is better. I need to detect the objects that are cose to my character, and until now I've been using geoms with collisionresponse disabled, so with its oncollision method I could check where and which geoms are within a certain distance from my character. But now... I've been checking linesegments, and the CollisionHelper's LineSegmentAllGeomsIntersect method seems pretty useful too, I like it because it gives me a geom list (I'm thinking on casting several lines from my character to check nearby geoms). So my question is, how these linesegments affect on the performance? I mean, instead of using one big geom for detecting nearby objects (or geoms), use several lines could be a bad idea? A good one?

Just asking if someone has implemented a good way to detect nearby geoms, or have had experience with LineSegments :)

Aug 14, 2009 at 11:48 PM

1. You can create a geometry and set IsSensor = true. This is the same as setting collision response to false and isstatic to true. It will skip all the physics related stuff and only be included in collision detection. Remember to make sure that the sensor does not collide with the player by using collision grups, categories or IgnoreCollisionWith();

2. You can even hook up to the OnBroadPhaseCollision instead if you don't need shape specific results (like the exact position of the collision).

3. You can create rays as much as you like. Like sensors they have next to no impact on performance.


I've created a sensor example here that also uses 4 rays:
As you can see from the performance panel, it all takes 0.02 ms to update - it also took 0.02 ms to update before I added the sensor and rays.

Aug 15, 2009 at 12:07 AM

Thanks Genbox! I think I'll go for the rays option, as I don't need to create additional bodies (for containing the geom sensors).


Aug 15, 2009 at 10:56 AM

Another small question. with the CollisionHelper.LineSegmentAllGeomsIntersect method, I have a list of intersecting geoms and intersecting points. Is there a way to know which geom belongs to each intersecting point?

Aug 15, 2009 at 3:03 PM
Edited Aug 15, 2009 at 3:03 PM

I've just changed the implementation to return a GeomPointPair. It contains the geometry and all the points where the ray intersects the geometry. You can grab the latest RayHelper.cs file from the source control. The changes are in changeset 58100.

Beware that I also renamed CollisionHelper to RayHelper.

Aug 15, 2009 at 8:55 PM

Genbox, as soon as I have the chance, I'll invite you a lot of beers (or whatever you drink). Thanks a lot.

Aug 15, 2009 at 11:36 PM

no problem pnikosis. You can donate me a beer if you like ;)

Aug 16, 2009 at 2:27 AM

I like the idea of a phantom geom being offset at a larger size than the in-play geom.  It seems that rays and broad phase collision might not always give the desired results...

Aug 16, 2009 at 7:28 PM

@genbox: Absolutely! :)


@fixitchris: The thing I like of the rays approach is that you get a list of the nearby geoms just by calling the ray. With a larger geom I have to handle this in the oncollision and onseparation methods to check which and how many geoms are inside the region I want to check (in the oncollision method I add the geoms to a list, in the onseparation I remove them). Looks simplier with the rays... I guess.

Aug 16, 2009 at 11:13 PM

What happens when an object moves in between two rays, past your "sensor" rays, toward the Geom object?

Aug 17, 2009 at 9:16 AM
Edited Aug 17, 2009 at 9:20 AM

@fixitchris Then I should make the distance between rays small enough to avoid that, but that means that probably I'll have more rays. I haven't decided if I'm going for the geom or the rays approach :P

So far I have implemented a mix between the geom approach (I started with that before I "discovered" the rays) and the rays approach (the geoms are for detecting nearby objects in the front and behind the character, and the rays for the floor detection and its angle). I'll see how it performs and if it performs well... probably I'll go for the "If it ain't broken, don't fix it".