koobas.hobune.stream
Correct and efficient player detection?
Hi, this is my first attempt at Unity and I ran into a problem. I need to detect whether the player character is visible from a point (think CCTV camera).
The first idea is, like many and many suggest, to simply raycast and check the collision. Quick, easy, but it seems wrong. Imagine a situation when the player is behind a wall with a small window that allows the camera to only see his knees (for example). In this situation raycasting to the center of the model, the feet, head or any other arbitrary point will fail. Yet the CCTV can see the player.
I thought about CapsuleCast, but that will not work either, as the sweep will stop once it hits the wall, it will not report any further collisions.
Raycasting to all the vertices of the character mesh sounds pretty expensive. Is there an efficient and correct way to check for visibility? Thanks!
Fake it with triggers. It'll get the job done and is easy.
If not, look for 3rd party solutions on the asset store etc.
If not, be prepared to write code that bakes view volumes from the camera. It could be done as part of your level loading or as part of your build process. The view volumes could be composite convex mesh collider triggers. As for correctness, that is a touchy subject. If there was a 1 mm gap somewhere in a wall, should the camera see it? I mean, to be correct, it should. But practically, should it matter? No, I don't think so at least.
As a final option you could consider rendering the scene to a texture, where everything that isn't detectable is black and everything that is detectable is white. Then you can have multiple shader passes which spits out the max value of texel of two comparisons. If so, the camera has detected something, but it can't identify which object. You could be clever and support identification of 4 different objects by linking them to red, green, blue and alpha channels respectively. If you just want to make a camera like those automatic doors at malls that open the door or raise the alarm, it would do just fine and should be pretty efficient and have decent resolution and correctness, and would work for cameras that move around. If you are confused about this approach I could invest some time in trying to make some pictures to explain the concept.
Could you elaborate on the first approach? At this point I have the CCTV which has a sphere collider attached, that's a trigger. When the player enters the area of effect of this CCTV and fires the trigger, then I do the (not-that-correct) raycasting to deter$$anonymous$$e FoV, visibility, etc.
Is there a better way to use triggers?
@melkamar: Imagine a situation when the player is behind a wall with a small window that allows the camera to only see his knees.
Let's back up and clear any preconceived ideas you have about how you want to do it, so you get to see it from my point of view. Ok? Clear your head.
Your game has some artwork for the building with the window. Your game also has some artwork for a CCTV camera. Finally, it has some artwork for your player. You place the CCTV camera outside the building, looking toward the window. You want something to happen, say, raise the alarm, if the CCTV camera spots the player.
Create a trigger zone outside the building to cover the area the CCTV camera can see. Create a trigger zone inside the building, just next to the window, to cover the area the CCTV camera can see inside the building.
One large trigger outside the building.
Two small triggers inside the building.
Create a script that hooks up to OnTriggerEnter on these triggers and forwards events to listeners when it wants to alert. That's it.
The CCTV camera may contain logic to do something if it has been alerted, like make a beep sound, but it does not have any OnTriggerEnter or other raycasting logic. It relies on that the triggers are positioned manually, carefully and purposefully in the scene. If you move the camera when you redesign the level, you have to move the triggers too.
With this approach, you create reusable building blocks so you have a trigger system that can be used with or without a camera, and any kind of action can happen. If you want I can elaborate with an example on this specific case, so you can see how I mean you can add events, listeners, and make it reusable.
