Is this true @tnavarts, or does the collision group behavior take precedence over the whitelist/blacklist?
1 Like
In that case this is a net positive in my opinion! I see this as an absolute win!
1 Like
Collision groups are an additional filter on top of the whitelist/blacklist. The whitelist/blacklist specifies which objects are candidates for collision, and then the collision group further filters more objects out of that set of candidates.
So, you can set a collision group to filter out additional objects for a raycast which already has a whitelist/blacklist.
1 Like
That sounds really bad then, and the API should be updated to have a way to ignore this filter (ideally this should have been the case by default, but 
)
I’m already seeing ways in which this is going wrong when I try to select a part inside of a filter group non-collidable with default. It turns out all of my plugins, and the built-in plugins won’t let me select these parts by clicking on them because there’s no method that lets you raycast with it without explicitly searching in that collision group.
Would collision groups be faster than using tags? Currently I use the collection service for tagging items which I want to be ignored, so would it make sense to switch over to collision groups? It would be cool if the RaycastParams worked with tags as well and not only collision groups.
1 Like
This is really an issue with collision groups, not an issue with raycasting. Either it should not have been possible to disable collision with the default collision group, or there should have been an explicit “actually everything” collision group that’s always available in every place.
We’re aware of this issue.
3 Likes
The real issue seems to be that collision groups are leaking into the raycast API. IIRC, raycasting came out long before collision groups, so it seems like there have been backwards compatibility issues in the first place, and I personally was completely unaware of the interaction between collision groups and raycasting.
1 Like
The RaycastParams api has not been updated on devhub with the new property.
although using CollectionService is a good idea, I would use collision groups if they are already existing. For example, I’m currently making NPCs that sees and catches other players, and since the NPCs can go through the other NPCs, I would just use that collision group for the rays to go through also. But that’s just where it helps me in my scenario, it would probably be easier in some other cases to use collection service.
Yea like @tnavarts said, we are aware this is still an issue, and that it’s always been there. This new CollisionGroup property provides some ways to work around part of it, but we understand there can still be a need to bypass collision groups entirely, and we are working on solutions for this. The great thing is that the new Raycast API makes it easier to address these kinds of things.
1 Like
Yes, since the collision group is just a single parameter which you can set on each raycast it will be much more efficient than having to do repeated raycasts or pass a huge list of all the tagged stuff to ignore tagged items.
Adding a FilterTags or similar parameter on RaycastParams is actually another thing that we may do in the future to natively support a tag based workflow. Though, I can’t make any promises about that API at this time, so you will want to switch to collision groups if you want the performance gains now.
3 Likes
Alright I will thank you very much for the reply.
Happy to see these changes! I was having raycast issues with different collision groups so im super happy to see this change. Now i just gotta go through and change all my raycasts over to the new method.
I do have one question though, im hoping i didnt miss it in the post. Does FilterType Whitelist/Blacklist work with collision group? Are we able to whitelist a collisiongroup or blacklist one because it sounded like we were only able to blacklist groups from the post.
Awesome!
Will we eventually see this sort of thing for pathfinding possibly? Collision filtering is an absolute must for pathfinding I think, and the only way to do this is to copy the map. Additionally, I wish there was a fully 3D
pathfinder for agents which don’t necessarily walk flat.I can see both being difficult to implement, however, so, I might be making a stretch.
(P.s. I believe a way that the above can be done is by pathfinding to the X and Z of a target, rotating the map, pathfinding from there, rotating, etc, etc and building up a path for all six rotations until a full path is made)
5 Likes
What about the actual Ray type itself? Or is it just these methods?
The new Raycast method doesn’t use the Ray class, so I think it would also be deprecated.
I am asking because of methods like Camera:ViewportPointToRay which return a ray object. And it feels kinda weird using one of those with the new api. But maybe that is just me.
That function didn’t work nicely with the old API either, since you had to decompose the ray it returned to scale up the length. Things haven’t changed in that regard.
Alright, and will new variants be made that return RaycastResults instead perhaps? Because I thought the purpose of the new api was to make ray casting easier? And to not use actual ray objects?
1 Like
So… now that we’re making new raycasting functions, can we also get boxcasting and spherecasting? lol
11 Likes