Page **2** of **2**

### Re: Inside FOV checking functions

Posted:

**Sun Sep 30, 2018 11:57 pm**
by **Rachael**

There's also the whole thing where some people may have 5:4 displays, some people may have 21:9 displays. Both render quite differently both horizontally and vertically. In my opinion, even for more innocent uses of the function, such a function is simply untenable for exposing to modders.

In my opinion, whatever problems this is meant to solve should be solved with assumptions, and generous ones at that. If you want an enemy to only aggro when the player sees it, then only allow the player's view to be +/- 45 degrees for that check. If you want to stop rendering a certain object because it is resource intensive, either lower your resource consumption, or use a more generous +/- 75 degrees.

I have reservations about including functions like these in ZScript and would much prefer to see them not be used.

### Re: Inside FOV checking functions

Posted:

**Mon Oct 01, 2018 12:24 am**
by **Graf Zahl**

Good point. I never thought about the hardware dependency issue here.

Yes, such functions should never be exposed to mods, it's simply not how stuff is supposed to work.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 6:46 am**
by **Apeirogon**

Soooo....even if I provide math for this, it still get [No] anyway?!

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 10:32 am**
by **Graf Zahl**

If it depends on the current screen dimensions, yes.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 11:11 am**
by **Apeirogon**

It depends on vectors. As I said before, one vector represent camera and it angle/pitch, or any other vector, and are unit vector, another position of actor/point in world relative to "camera" actor.

With the assumption that both vector placed in one plane, which placed in 3d space, find scalar product, divide it on product of a length of both vectors and the find arccosine of result number. Final result return angle, between 0-180, between vectors.

If require, it can return how much, and in what axes, you need to turn second vector to make it parallel to first.

But this is actually more hack than actual check_if_in_fov(something). For default cuboid doom actors it required 8 calls to distance_3d, to check all 8 angles. But distance check CAN be reduced from sqrt(number) to arcsin(another number).

I try to understand how c++ find square root, but looks like it not something what I learned in...school I think.

- Screenshot_2018-10-13-20-20-15.png (26.46 KiB) Viewed 585 times

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:00 pm**
by **Rachael**

You're never going to need square root in such a function. For instance, arctan((a1.x-a2.x)/(a1.y-a2.y)) is a fairly straightforward way of getting an angle of two actors, provided their y position never matches (and if it does, you can just use static values depending on whether the x calculation is negative to prevent a /0 abort).

What you guys are asking for here is literally a "is this inside the camera?" check, and that's never going to happen. The game sim does not know how widescreen your monitor is - and it never should. That is terrible game design if it does. The ONLY proper way to do such a check is, for instance, using the formula I listed above, and making broad assumptions about the player's camera. I'd say the average 16:9 monitor probably has about 112 degrees of field of view, and if you base that on the player's angle, that's about 56 degrees on each side. I'm fairly sure you can figure out the rest from there.

But on that note, isn't there already some sort of AngleTo(a1, a2) function already available anyhow?

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:15 pm**
by **Apeirogon**

You formula dont use Z component of a vectors. Actor can be much higher/lower that camera position, but function still return "actor in camera fov".

Or camera can be point straight up.

Or camera can use "home made" functions to freely turn around its x/y/z axis.

Or actor can be hidden from direct observation by map geometry.

Or...

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:24 pm**
by **Rachael**

Or I can ask what do you need all these checks so badly for? This reeks of throwing everything but the kitchen sink at a simple problem.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:32 pm**
by **Rachael**

By the way, the formula for calculating pitch would indeed use square roots. It's basically arctan(sqrt((a1.x - a2.x)^2 + (a1.y - a2.y)^2) / (a1.z - a2.z)). You might have to invert the division, but otherwise it should work. It's basically using the flat 2D XY distance from an actor as the first component.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:35 pm**
by **Apeirogon**

Emulate camera as cone with some angle in vertex, which represent camera fov, and than check angle between cone axis and line from cone vertex to actor with cone vertex angle.

Again, I dont say "use actual player screen to check something", I say "check angle between several vectors to check something".

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 12:38 pm**
by **Apeirogon**

And you can find distance without root, using a bunch of sin and cos.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 1:15 pm**
by **KeksDose**

Step back for a moment. What do we want?

I voiced my concerns last page. The idea in the OP cannot be reconciled with the usage cases MC suggested (screen check and things you'd never look through, like missiles spotting you). The best we are willing to add to the engine is a fov-check not caring about the monitor, the latter. Let's stop calling it fov-check. It's an angular location test. There are more than just one way to do this:

One is what Apeirogon is getting at, a cone-shaped check, that takes just one angle.

A way with two angles is with with what I posted last page. It properly accounts for 90° pitch, but it is wedge-shaped. Actors way above the centre line of the check have an easier time avoiding this check.

You can make it length preserving at the locally vertical edges, so for bigger vertical angles, the space covered remains the same. That's another option addressing the previous.

First agree on the exact nature of the check, not just "no monitor." Any of these can cover "screen check with assumptions about what the player may see."

edit: I'd say the cone and wedge checks are the most commonly used, since they got mostly thrown around here. IMO, anything more sophisticated should be left up to mods.

### Re: Inside FOV checking functions

Posted:

**Sat Oct 13, 2018 4:38 pm**
by **Pixel Eater**

Would a visual calibration for the player reduce much of the predictive math needed?

### Re: Inside FOV checking functions

Posted:

**Sun Oct 14, 2018 4:10 am**
by **KeksDose**

There are no visuals. It's a location test. Mathematics are not the problem here. We had everything we needed to do this on the previous page.

What I posted is not necessarily a screen test, but it is roughly viable as one. At no point are there any assumptions about the screen or renderer, as the angles are freely chosen. It covers "limited screen test" pretty great. In fact, if you pass the screen fovs, it's an open-gl screen test without pixel stretching. That doesn't mean it's screen-based.

What Apeirogon suggests is a useful alternative, too. Choose your destiny.