How to use filters with ray casting?

Physics
#1

Hi,

My game mainly uses collision filters and I have a case where ray casting has enabled another type of weapon (think sniper where it is instant) but I cannot use the collision detection filters to confirm what is allowed and what isn’t ??

I think I may end up having to see what object the ray cast hit, and then do a bunch of if, then, else etc which essentially duplicates what is in the collision filters… so it would either be great to read these out (which you can’t) or have ray casting use them too.

Any tips on what to do here?

G

#2

I’m currently thinking I could probably create my own CollisionFilterManager (like the SSK tools) that also has a isCollisionFiltered(TypeA, TypeB) method that I can use with the ray casting code… kinda like a manual method of what the physics engine would be doing for the other collision methods. Because the CollisionFilterManager manages all the collision data, I can centrally perform a manual check for collision filters.

This seems like the best/only approach, but wanted to check first. If so, this seems like an improvement opportunity for Corona to complete the physics API for ray casting.

G

#3

Actually this approach isn’t too efficient as it requires the testing of bitwise AND against the mask and category bits… so it performs really poorly due to the clumsy way I have to implement AND bit operators due to a lack of lua support for them.

So I might be better to just have another if, then, else… man that is ugly and I’m surprised Corona haven’t considered how you are to be using the Raycasting with collisions and the need for the filter code to be apart of that approach - as you can only use Raycasting against a physic body anyway??

G

#4

Hang on… is it the intention that collision filters are not really needed as much for non physic based collisions - ie when you are using them purely for a non-physic reacting world where most objects are isSensor=true and therefore just an enhanced collision detection system, of which normal lua code to sort through if, then, else for which objects should propagate a game event to kill the player etc isn’t seen as a big task for the code to manage.

This would then negate the need for ray casting to have collision filters (as it doesn’t react with the world physic objects) and as it isn’t seen as a performance hit (being that it doesn’t interact with the physics world) it isn’t an issue then !???

It sure would be nice to allow you to use ray casting with collision filters - if only to make it consistent with the rest of the physic API, or maybe even some advice as to when it is needed and when it isn’t

G

#5

So it looks like I’m having this conversation with my self then… ? Corona community hello… snif…  :(

#6

Hi @gslender,

As you surmised, collision filters don’t yet work with raycasts. This may be something we add in the future, but at this time, it’s not a highly requested feature. I know that’s not what you want to hear, but it’s sort of the reality of it. :slight_smile:

To answer your other questions (somewhat), raycasting is definitely for physics interaction only, and it will have no effect on non-physics objects. At the same time, rays are not really physics bodies themselves, merely a sensory line-path to check against other bodies. That being said, collision filters could theoretically apply to them… let me ask the engineers what this would take because, despite the various “filters” of how many hits you detect along the path of a raycast, if you gather multiple hits, you still can’t filter those without using some kind of naming scheme and a few “or” operators.

Best regards,

Brent

#7

Thanks Brent.

I’m actually in the process of how to best implement this in a game - I don’t really want to duplicate what the filters are doing with a bunch of “or” operators - if Lua had native bitwise operators that would help, but I fear that the overhead of the lua library or code to simulate an AND or OR would be greater than just a clumsy if object.id==“monster” to detect if the ray hit a valid object.

As such, I’m thinking of pulling out the physic collision filters and just relying on a global Collision class to perform manual if, then, else detection on all local collisions. All my objects are isSensor and I’m only using physics for the collision detection.

This would give me the benefit of having a single code base and central point for all collision filtering and allow both ray cast and non-ray cast collisions to use the same method - plus I don’t think it would be too much of a penalty considering it would be a well optimised section within my game.

Thoughts?

G

#8

Hi G,

I suppose if you want to use collision filters “as is”, you could just drop a long, slender rectangular body from the start point to the end point, which is like casting a ray, but it’s a normal sensor physics body instead and would naturally obey filters instead of requiring a bunch of conditional checks. If you do this, just note that the collision event would likely occur on the next game cycle (which may not be an issue at all, but I’m mentioning it anyway).

That being said, you would probably still get better performance using a raycast and some conditional logic. Creating physics bodies are not the fastest operation, which is why I normally suggest developers create them during non-time-critical periods.

Brent

#9

I’m currently thinking I could probably create my own CollisionFilterManager (like the SSK tools) that also has a isCollisionFiltered(TypeA, TypeB) method that I can use with the ray casting code… kinda like a manual method of what the physics engine would be doing for the other collision methods. Because the CollisionFilterManager manages all the collision data, I can centrally perform a manual check for collision filters.

This seems like the best/only approach, but wanted to check first. If so, this seems like an improvement opportunity for Corona to complete the physics API for ray casting.

G

#10

Actually this approach isn’t too efficient as it requires the testing of bitwise AND against the mask and category bits… so it performs really poorly due to the clumsy way I have to implement AND bit operators due to a lack of lua support for them.

So I might be better to just have another if, then, else… man that is ugly and I’m surprised Corona haven’t considered how you are to be using the Raycasting with collisions and the need for the filter code to be apart of that approach - as you can only use Raycasting against a physic body anyway??

G

#11

Hang on… is it the intention that collision filters are not really needed as much for non physic based collisions - ie when you are using them purely for a non-physic reacting world where most objects are isSensor=true and therefore just an enhanced collision detection system, of which normal lua code to sort through if, then, else for which objects should propagate a game event to kill the player etc isn’t seen as a big task for the code to manage.

This would then negate the need for ray casting to have collision filters (as it doesn’t react with the world physic objects) and as it isn’t seen as a performance hit (being that it doesn’t interact with the physics world) it isn’t an issue then !???

It sure would be nice to allow you to use ray casting with collision filters - if only to make it consistent with the rest of the physic API, or maybe even some advice as to when it is needed and when it isn’t

G

#12

So it looks like I’m having this conversation with my self then… ? Corona community hello… snif…  :(

#13

Hi @gslender,

As you surmised, collision filters don’t yet work with raycasts. This may be something we add in the future, but at this time, it’s not a highly requested feature. I know that’s not what you want to hear, but it’s sort of the reality of it. :slight_smile:

To answer your other questions (somewhat), raycasting is definitely for physics interaction only, and it will have no effect on non-physics objects. At the same time, rays are not really physics bodies themselves, merely a sensory line-path to check against other bodies. That being said, collision filters could theoretically apply to them… let me ask the engineers what this would take because, despite the various “filters” of how many hits you detect along the path of a raycast, if you gather multiple hits, you still can’t filter those without using some kind of naming scheme and a few “or” operators.

Best regards,

Brent

#14

Thanks Brent.

I’m actually in the process of how to best implement this in a game - I don’t really want to duplicate what the filters are doing with a bunch of “or” operators - if Lua had native bitwise operators that would help, but I fear that the overhead of the lua library or code to simulate an AND or OR would be greater than just a clumsy if object.id==“monster” to detect if the ray hit a valid object.

As such, I’m thinking of pulling out the physic collision filters and just relying on a global Collision class to perform manual if, then, else detection on all local collisions. All my objects are isSensor and I’m only using physics for the collision detection.

This would give me the benefit of having a single code base and central point for all collision filtering and allow both ray cast and non-ray cast collisions to use the same method - plus I don’t think it would be too much of a penalty considering it would be a well optimised section within my game.

Thoughts?

G

#15

Hi G,

I suppose if you want to use collision filters “as is”, you could just drop a long, slender rectangular body from the start point to the end point, which is like casting a ray, but it’s a normal sensor physics body instead and would naturally obey filters instead of requiring a bunch of conditional checks. If you do this, just note that the collision event would likely occur on the next game cycle (which may not be an issue at all, but I’m mentioning it anyway).

That being said, you would probably still get better performance using a raycast and some conditional logic. Creating physics bodies are not the fastest operation, which is why I normally suggest developers create them during non-time-critical periods.

Brent