Checking if an entity is within a players view

[Mexicouger]

Im having troubles on how I would code it to check if a certain entity is within the current viewing angles of the player. anyone mind pointing me in the right direction? And if Im a little unclear, let me explain.

Your the player. Say theres a rocket launcher on the ground. How could you check and see if that rocket launchers within the players camera? And lets just say you turn around and you can no longer see the rocket launcher. How could I calculate that?

[Baker]

[Mexicouger]

That's not what I'm trying to do haha. That checks around the player. With that code, the rocket could be behind the player and still detect it. I'm thinking something more like fisible from frikbots but from the perspective of the players v_angle detecting what the player can actually see.

[Baker]

[frag.machine]

[Mexicouger]

[Spike]

This post is basically an explaination of the infront function.

in qc terms:
cos(anglebetweenvectors) == normalisedvector1 * normaliseedvector2

so vector*vector will be 1 if they are identical, -1 if they point in opposite directions, and 0 if they point 90 degrees to each other.
Considering the greatest angle difference you can have is 0 to 180 and fields of view are measured in both directions instead of just one, ((fwd*normalilze(targetpos - sourcepos)) > cos(fovvalue/2)) can be used to check whether the direction is within the given field-of-view angle.
cos, however, is an extension, but you can replace the result of that function with a constant (for example, quake's collision code reguarly uses 0.7 for surfaces that are considered pointing upwards for 'onground' checks).
Note that this is NOT the same as 'onscreen', as this would require a circular screen. The virtual circular screen will generally have the same width as the screen, thus this may fail for the corners of the screen. Also, you may also need to pay attention to bounding boxes.
Additionally, makevectors(self.angles) is generally only valid when angles_x=0 (which is true for monsters). If used for a player, you should be using makevectors(self.v_angle) instead. This will scale correctly with pitch (instead of being 1/3rd), and will also work around an old (unfixable) sw quake bug where .angles_x on alias models is inverted.

(qc's vector*vector operation/instruction is actually a 3-componant dotproduct)
(dotproduct is useful for all sorts of things!)

[Nahuel]

I made this in the past days to get some effects, if the entity is infront and visible with the precise angles CSQC add some bloom effect ... maybee seems crapy in this early release

[toneddu2000]

Very very nice effect Nahuel! I loved it! Sun light is lightmapped or dynamic (achieving dynamic sun lights in DP is my only motivation of life in these days! )?

[Nahuel]

hello tunedude, the map is darker, so is just a dynamic light place un a specific place !

@Spike it is posible to get something like (infront) function but instead of using a speciffic point like "self.origin" to use an area? i speak about an entire area of the brush, a something like func_wall, I wanna to get the bloom oriented effect with a brush, not with the specific origin of the entity . Thanks in advance

[Seven]

This is a very interesting topic.
Thank you Mexicouger for starting this thread and Nahuel for your demonstration.
It brings so many new ideas into the mind.

I am working on a zombie modification at the moment, in which the Axe weapon plays a special role.
Implementing a QC "zombiecheck" to find out if a zombie is in range and then starting an Axe animation,
where it starts to glow. Because zombies are killable with the Axe.
It is like a "holy-zombie-killing" weapon in this mod...

So this thread-knowledge is very helpful to achive this task.
Thank you again.
Seven

[Spike]

Nahuel, can you not just define a direction in the map, and use that against the player's v_forward? then its no specific point at all, though would be purely based upon the player's view direction.

[Alex]

[andrewj]