Physics APIs, such as raycast, checkbox, overlapsphere, capsulecast or their command Unity’s jobs alternatives support parameters to include or exclude colliders of type trigger from their queries. However, there is no way to ONLY include them and EXCLUDE all non-trigger colliders.
This could be solved by adding a new variant to the enum QueryTriggerInteraction.
I don’t know the case where this is actually useful, that’s why it’s not added I guess. If you really need something like that, query specific layers which are expected to be on triggers only or set other non-trigger geometry to some layer you exclude.
Ok, what is your specific case that you need to query triggers only?
I personally don’t mind that feature, but I’ve never encountered a need for this in any game I ever made.
Btw engine already has built-in “Ignore Raycast” layer, which you can apply to all non-trigger geometry and excluded it from your raycast mask, and which can’t be removed/renamed so it’s technically free and doesn’t occupy other available layer slots.
Specific examples aside, I’d like this myself. Whether or not something is a trigger is a separate concern to what layer it is on. But the implementation isn’t separate, which can complicate layer configurations.
It’d also make associated code and Inspector stuff more consistent. Right now you can ignore triggers from the raycast call, which is great for when you don’t want it to be a configuration parameter. But if you want to specifically cast against triggers only, it’s essentially forced up to the Inspector so you can expose the layer mask, which opens the potential for config errors later on. Plus, it’s just idiomatically inconsistent, making code less clear than it could be, and increasing what has to be documented elsewhere - “this must be trigger layers only”.
How often does that specific case of trigger only casts impact me? I’m not entirely sure, because I’m already in the habit of splitting triggers into their own layer(s) anyway, precisely because I do need to regularly filter on that. There’s a lot I want to operate with triggers only.
Certainly not the end of the world, but unless there’s a specific reason for the current design (e.g. performance impact could be perfectly valid) the suggestion here seems worth consideration.
My current problem from which I make this post is for performance. My enemies have multiple non-trigger colliders, and a single trigger collider. In certain operations I must do an overlap sphere to find all enemies in range, and I only need to check the trigger one, so querying the others consumes CPU that is not necessary.