Raycasting ignore parts with tag

Adding the ability for rays to ignore parts with certain tags will make it so I don’t have to manually manage a list of every object I want to ignore

local RayOptions = RaycastParams.new()
RayOptions.IgnoreTags = {"Water", "Glass", "ModelHitbox"}
18 Likes

You can probably accomplish this using the CollisionGroup field of RaycastParams. If it must be automated and dynamic, you can probably route all tag changes through a module that adds or removes instances from a no-raycast collision group at the same time.

If this is insufficient for your use cases, you should explain in more detail.

2 Likes

You can only have 32 collision groups in a game iirc, supporting tags is more scalable

9 Likes

I recently ran into this issue as well, raycasting to whitelist a bunch of enemies so I can detect specifically what I should damage. I would greatly appreciate using tags to ignore or whitelist by providing a table of all the tag names. My current work around is looping all the parts and moving them to a proxy table which I then supply to the Raycast Params. I would love to have an optional parameter to RaycastParams for tags!

3 Likes

Necroposting on this because I think it would be helpful. The application I’ve found where this could be beneficial involves needing some casts to only look for physical “Prompts” (think a proximity prompt, but on a part), with other raycasts (such as bullets) to ignore these objects.

Being able to pass a tag to the AddToFilter() method would be greatly helpful.

I also understand that this could be manually implemented with relative ease, but this would be a great QoL engine feature and would encourage the use of the under-utilized CollectionService

1 Like

Even better would be adding a new field in RaycastParams that lets us specify a selector like the one that the QueryDescendants() method uses. That would enable a lot more flexibility than just tags.

1 Like

Definitely. Some build outs for raycasts would be greatly appreciated.

Couldn’t you use FilterDescendantsInstances and AddToFilter() while passing GetTagged() for this purpose?

Perhaps raising this value would be a quicker fix. The purpose Feature request is okay

One could reasonably assume that having it handled entirely on the engine’s side is going to be way more performant and memory efficient than doing this though, would it not? With the method you propose we’d also have to keep track of when these tagged instances are destroyed or untagged and remove them from the filter otherwise a memory leak is risked.

1 Like

There are multiple ways to achieve this. It’s not hard to use InstanceAdded and InstanceRemoved or use GetTagged() for every time you need to Raycast.

Sure with C++ it could be a lot faster but I don’t think it matters that much.

Generally I don’t care for performance and premature optimizations. The current Raycast performance is pretty good and has been improved a lot.

I haven’t seen or heard of a case where Raycast isn’t performant enough for a typical Roblox game.

While performance improvements are welcomed I don’t think a performance gain so negligible would be worth the time invested.